mysql1118（mysql1118错误）

本篇文章给大家谈谈mysql1118，以及mysql1118错误对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、mysql VARCHAR的最大长度到底是多少
• 2、mysql 排序难题
• 3、使用Navicat for Mysql导入向导的时候出现1118 - Row size too large错误，如何解决

mysql VARCHAR的最大长度到底是多少

以前一直都认为有两个字节来记录长度（长度小也可以用一个字节记录），所以这个问题当时觉得就挺无聊的不过后来群里有人给了解释，突然才发现原来事情不是这么简单MYSQL COMPACT格式，每条记录有一个字节来表示NULL字段分布，如果表中有字段允许为空，则最大只能定到65532，如果没有字段允许为空，则那个字节可以节省，最大可以定义到65533，不知道是不是这个原因于是上网看了些资料，又在闹磨本地做了些实验，原来vachar的最大长度真的是不定的（根据是否有非空字段来决定）在本地做了下实验，innodb+latin的环境

复制代码 代码如下:

-- success

drop table if exists test;

create table test(name varchar(65533) not null)engine=innodb DEFAULT CHARSET=latin1-- too large

drop table if exists test;

create table test(name varchar(65533))engine=innodb DEFAULT CHARSET=latin1对于第二种情况，允许空字段的时候是不能加到65533的长度的，最大只能到65532，到底应该是引文的那种说法。

网上也有人做了类似的实验，参考复制代码 代码如下:

name varchar(100) not null will be 1 byte (length) + up to 100 chars (latin1)name varchar(500) not null will be 2 bytes (length) + up to 500 chars (latin1)name varchar(65533) not null will be 2 bytes (length) + up to 65533 chars (latin1)name varchar(65532) will be 2 bytes (length) + up to 65532 chars (latin1) + 1 null byte总结一下，原来mysql的vachar字段的类型虽然最大长度是65535，但是并不是能存这么多数据，最大可以到65533（不允许非空字段的时候），当允许非空字段的时候只能到65532。

以下是其它网友的补充说明：

这不是一个固定的数字。本文简要说明一下限制规则。

strlen 计算字符串长度，一个中文当2字符

mb_strlen根据它的字符编码模式，统计字符quotcount计算数组中的元素数目或对象中的属性个数复制代码 代码如下:

?php

header('Content-Type:text/html;charset=UTF-8');$string1="谢春业";//定义中文字符变量

$string2="xcy";//定义英文字符变量

//直接输出看看他们的长度

echo strlen($string1);

echo "/br";

echo strlen($string2);

echo "/br";

//用 php 多字节扩展函数 mb_strlen试试看

echo mb_strlen($string1,'utf8');

echo "/br";

echo mb_strlen($string2,'utf8');

echo "/br";

?

输出结果是：

9

3

3

　御察　3

1、限制规则

字段的限制在字段定义的时候有以下规则：

a) 存储限制

varchar 字段是将实际内容单独存储在聚簇索引之外，内容开头用1到2个字节表示实际长度（长度超过255时需要2个字节），因此最大长度不能超过65535。

b) 编码长度限制

字符类型若为gbk，每个字符最多占2个字节，最大长度不能超过32766;字符类型若为utf8，每个字符最多占3个字节，最大长度不能超过21845。

对于英文比较多的论坛 ，使用GBK则每个字符占液拆斗用2个字节，而使用UTF－8英文却只占一个字节。

若定义的时候超过上述限制，则varchar字段会被强行转为text类型，并产生warning。

c) 行长度限制

导致实际应用中varchar长度限制的是一个行定义的长度。 MySQL要求一个行的定义长度不能超过65535。若定义的表长度超过这个值，则提示ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to 　change some columns to TEXT or BLOBs。

2、计算例子

举两个例说明一下实际长度的计算。

a) 若一个表只有一个varchar类型，如定义为

create table t4(c varchar(N)) charset=gbk;则此处N的最大值为(65535-1-2)/2= 32766。

减1的原因是实际行存储从第二个字节开始';

减2的原因是varchar头部的2个字节表示长度;

除2的原因是字符编码是gbk。

b) 若一个表定义为

create table t4(c int, c2 char(30), c3 varchar(N)) charset=utf8;则此处N的最大值为 (65535-1-2-4-30*3)/3=21812减1和减2与上例相同;

减4的原因是int类型的c占4个字节;

减30*3的原因是char(30)占用90个字节，编码是utf8。

如果被varchar超过上述的b规则，被强转成text类型，则每个字段占用定义长度为11字节，当然这已经不是“varchar”了。

[img]

mysql 排序难题

FIND_IN_SET里的斗衫id应该使用反引号(`)而不是单引号(') , 举个栗子:

SELECT `ID`

  FROM (SELECT '1116' AS ID 

         UNION ALL 

        SELECT '1118' 

         UNION ALL 

        SELECT '1119' 

         UNION ALL 

   历销睁     SELECT '1358'

         肢岁ORDER BY `ID`) T

 WHERE `ID` IN ('1119','1118')

 ORDER BY FIND_IN_SET(`ID`,'1119,1118')

结果:

使用Navicat for Mysql导入向导的时候出现1118 - Row size too large错误，如何解决

这种情况偶尔出现,没什么关系,不用管他。点击‘取消’就可以了。 经常出现就危险了，弄不好就得重装系统了。 该内存不能read written常见原因 使用Windows操作系统的人有时会遇到这样的错误信息：“0X????指令引用的0x00000000内存，该内存不能written”、read，然后应用程序被关闭。如果去请教一些“高手”，得到的回答往往是“Windows就是这样不稳定”之类的义愤和不屑。其实，这个错误并不一定是Windows不稳定造成的。本文就来简单分析这种错误的常见原因。 一、应用程序没有检查内存分配失败 程序需要一块内存用以保存数据时，就需要调用操作系统提供的“功能函数”来申请，如果内存分配成功，函数就会将所新开辟的内存区地址返回给应用程序，应用程序就可以通过这个地址使用这块内存。这就是“动态内存分配”，内存地址也就是编程中的“指针”。 内存不是永远都招之即来、用之不尽的，有时候内存分配也会失败。当分配失败时系统函数会返回一个0值，这时返回值“0”已不表示新启用的指针，而是系统向应用程序发出的一个通知，告知出现了错误。作为应用程序，在每一次申请内存后都应该检查返回值欠裎?，如果是，则意味着出现了故障，应该采取一些措施挽救，这就增强了程序的“健壮性”。 若应用程序没有检查这个错误，它就会按照“思维惯性”认为这个值是给它分配的可用指针，继续在之后的运行中使用这块内存。真正的0地址内存区保存的是计算机系统中最重要的“中断描述符表”，绝对不允许应用程序使用。在没有保护机制的操作系统下帆冲(如DOS)，写数据到这个地址会导致立即死机，而在健壮的操作系统中，如Windows等，这个操作会马上被系统的保护机制捕获，其结果就是由操作系统强行关闭出错的应用程序，以防止其错误扩大。这时候，就会出现上述的“写内存”错误，并指出被引用的内存地址为“0x00000000”。 内存分配失败故障的原因很多，内存不够、系统函数的版本不匹配等都可能有影响。因此，这种分配失败多见于操作系统使用很长时间后，安装了多种应用程序(包括无意中“安装”的病毒程序)，更改了大量的系统参数和系统文件之后。 二、应用程序由于自身BUG引用了不正常的内存指针 在使用动态分配的应用程序中，有时会有这样的情况出现：程序试图读写一块“应该可用”的内存，但不知为什么，这个预料中可用的指针已经失效了。有可能是“忘记了”向操作系统要求分配，也可能是程序自己在某个时候已经注销了这块内存而“没有留意”等等。注销了的内存被系统回收，其访问权已经不属于该应用程序，因此读写操作也同样会触发系统的保护机制，企图“违法”的程序唯一的下场就是被操作终止运行，回收全部资源。计算机世界的法律还是要比人类有效和严厉得多啊！ 像这样的情况都属于程序自身的BUG，你往往可在特定的操作顺序下重现错误。无效指针不一定总是0，因此错误提示中的内存地址也不一定为“0x00000000”，而是其他随机数字。 如果系统经常有所提到的错误提示，下面的建议可能会有帮助： 1.查看系统中是否有木马或病毒。这类程序为了控制系统往往不负责任地修改系统，从而导致操作系统异常。平常应加强信息安全意识，对来源不明的可执行程序绝不好奇。 2.更新操作系统，让操作系统的安装程序重新拷贝正确版本的系统文件、修正系统参数。有时候操作系统本身也会有BUG，要注意安装官方发行的升级程序。 3.试用新版本的应用程序。 IE浏览器出现“0x0a8ba9ef”指令引用的“0x03713644” 内存，或者“0x70dcf39f”指令引用的“0x00000000”内存。该内存不能为“read”。要终止程序，请单击“确定”的信息框，单击“确定”后，又出现“发生内部错误，您正在使用的其中一个窗口即将关闭”的信息框，关闭该提示信息后，李李IE浏览器也被关闭。解决方法： 1、 开始-运行窗口，输态扰歼入“regsvr32 actxprxy.dll”回车，接着会出现一个信息对话 框“DllRegisterServer in actxprxy.dll succeeded”，确定。再依次运行以下命令。（这个方法有人说没必要，但重新注册一下那些.dll对系统也没有坏处，反正多方下手，能解决问题就行。） regsvr32 shdocvw.dll regsvr32 oleaut32.dll regsvr32 actxprxy.dll regsvr32 mshtml.dll regsvr32 msjava.dll regsvr32 browseui.dll regsvr32 urlmon.dll 确实是浏览器损被破坏，里面却东西，我建议最好重装IE。（最简单，最实用办法) 你也可以用360卫士修复IE

关于mysql1118和mysql1118错误的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。