MySQL数据库单一表突破4G限制的实现方法

源代码网整理以下问题：在论坛发表回复时出现“The table is full”的提示，字面意义上是数据表已满的意思。因为很少有开发者遭遇单一表超过4G的情况，因此朋友间的讨论只能提供一些外围的信息。为解决此问题，我翻阅了很多资料，本文将以我此次问题的解决过程，介绍问题发生的原因及对策。

源代码网整理以下根据经验，The table is full提示往往出现在以下两种情况：

源代码网整理以下1. 表中设置了MAX_ROWS值，简单的说，若MAX_ROWS设置为100，而程序试图写入第101条记录，会出现此错误。

源代码网整理以下2. 表满。这种情况是本文讨论的重点

源代码网整理以下我们认为MySQL在存取表的时候，存在一种定位分配规律。这个规律在默认的情况下，可以寻址4G以内的数据。超过这个大小，数据库将不能对数据定位，因而也无法进行读写。经过实验，这个限制是完全可以被突破的。

源代码网整理以下本例中，用户的系统环境为双Athlon处理器、SCSI硬盘72G、2G内存，用户的帖子表数据尺寸为4294963640，接近4G(4G的实际字节数为4294967296)。

源代码网整理以下首先SSH登录后，查看用户的系统信息：

源代码网整理以下

源代码网整理以下证明是Linux系统，根据内核版本2.4.20-8smp，加上国内使用的常见系统，估计应该是redhat 9发行包。

源代码网整理以下# cat /etc/*release*

源代码网整理以下Red Hat Linux release 9 (Shrike)

源代码网整理以下这也证明了我们对系统版本的猜想。

源代码网整理以下然后看一下用的是什么文件系统。因为该用户并非高手，估计在装系统的时候就是一路回车下来，redhat 9默认的应该是EXT3，不过我们还是看一下：

源代码网整理以下

源代码网整理以下证明确实是这样子。随后我们翻阅了EXT3文件系统的相关技术参数，EXT3是在EXT2基础上演变而来。EXT2所支持最大单一文件长度是2G，这个是很蹩脚的一个限制。EXT3做的很大一个改善就是将这个限制放大到了2TB，由此稍松一口气，起码不是操作系统上的限制。

源代码网整理以下经过朋友的开导，了解到单一文件大小有如下几个因素：

源代码网整理以下1. 文件系统的限制(如刚存所说EXT3的2TB限制)

源代码网整理以下2. 某一程序进程所能存取的第一文件最大尺寸(例如apache在Linux EXT3下能存取的最大尺寸为2G，诸如日志)

源代码网整理以下初步判断瓶颈就在上述其中第二项。随后找到myisamchk来显示一下表信息，证明了瓶颈就在MySQL本身的存取上。

源代码网整理以下# myisamchk -dv cdb_posts

源代码网整理以下结果就不贴了，其中有一项Max datafile length的值恰好就是4G。由此产生了瓶颈。

源代码网整理以下后来翻阅了N多资料，进行了N多尝试，也走了不少弯路，最终觉得还是官方文档比较可靠。比较老的文档里写道这是由于tmp_table_size的值造成的，也有提到用BIG-TABLES这个参数。事实证明这些都是歧途。大晚上的确实很累，这里只给出最终的解决方案吧，中间的就不罗嗦了。

源代码网整理以下 源代码网供稿.