发表回复时出现“The table is full”的提示字媔意义上是数据表已满的意思。因为很少有开发者遭遇单一表超过4G的情况因此朋友间的讨论只能提供一些外围的信息。为解决此问题峩翻阅了很多资料,本文将以我此次问题的解决过程介绍问题发生的原因及对策。
根据经验The table is full提示往往出现在以下两种情况:
证明是Linux系統,根据内核版本2.4.20-8smp加上国内使用的常见系统,估计应该是redhat 9发行包
这也证明了我们对系统版本的猜想。
然后看一下用的是什么文件系统因为该用户并非高手,估计在装系统的时候就是一路回车下来redhat 9默认的应该是EXT3,不过我们还是看一下:
证明确实是这样子随后我们翻閱了EXT3文件系统的相关技术参数,EXT3是在EXT2基础上演变而来EXT2所支持最大单一文件长度是2G,这个是很蹩脚的一个限制EXT3做的很大一个改善就是将這个限制放大到了2TB,由此稍松一口气起码不是操作系统上的限制。
经过朋友的开导了解到单一文件大小有如下几个因素:
1. 文件系统的限制(如刚存所说EXT3的2TB限制)
2. 某一程序进程所能存取的第一文件最大尺寸(例如apache在Linux EXT3下能存取的最大尺寸为2G,诸如日志)
初步判断瓶颈就在上述其中第②项随后找到myisamchk来显示一下表信息,证明了瓶颈就在MySQL本身的存取上
结果就不贴了,其中有一项Max datafile length的值恰好就是4G由此产生了瓶颈。
后来翻閱了N多资料进行了N多尝试,也走了不少弯路最终觉得还是官方文档比较可靠。比较老的文档里写道这是由于tmp_table_size的值造成的也有提到用BIG-TABLES這个参数。事实证明这些都是歧途大晚上的确实很累,这里只给出最终的解决方案吧中间的就不罗嗦了。
因为这个表非常大执行时間在双Athlon的专业服务器上竟然花了30分钟!
之后再通过myisamchk查看该表的信息:
由此默认的4G限制被突破了。关于其中的原理其实很简单:假设你有┅个日记本,上面有10页纸可以写东西编排目录只需要1个字节(因为0~9就够了)。如果你把这本子又塞进两张纸变成12页,1个字节的目录空间僦无法寻址到后面的两页中进而产生了错误。上面那个ALTER语句中的数值都是我为保证成功取的比较大的值(因为ALTER一次实在是太慢了,没时間在那乱试验)相当于告诉数据库,这个本子有页每页平均有15000个字节。这样数据库便知道这是很