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

?

根据经验，The table is full提示往往出现在以下两种情况：

1. 表中设置了MAX_ROWSvalue，简单的说，若MAX_ROWS设置为100，而程式试图写入第101条记录，会出现此错误。

?

2. 表满。这种情况是本文讨论的重点

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

本例中，用户的Systam环境为双Athlon处理器、SCSI硬盘72G、2G内存，用户的帖子表Data尺寸为4294963640，接近4G(4G的实际字节数为4294967296)。

?

首先SSH登录后，查看用户的Systam信息：

# uname -a

Linux ziChen.Com 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 2003 i686 athlon i386 GNU/Linux

证明是LinuxSystam，根据内核版本2.4.20-8smp，加上国内使用的常见Systam，估计应该是redhat 9发行包。

# Cat /etC/*release*

Red Hat Linux release 9 (Shrike)

这也证明了我们对Systam版本的猜想。

然后看一下用的是什么文档Systam。因为该用户并非高手，估计在装Systam的时候就是一路回车下来，redhat 9默认的应该是EXT3，不过我们还是看一下：

# parted

GNU Parted 1.6.3

Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, InC.

This program is free software, Covered by the GNU General PubliC LiCense.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General PubliC LiCense for more details.

Using /dev/sda

Information: The operating system thinks the geometry on /dev/sda is 8942/255/63. Therefore, Cylinder 1024 ends at 8032.499M.

(parted) print

Disk geometry for /dev/sda: 0.000-70149.507 megabytes

Disk label type: msdos

Minor Start End Type Filesystem Flags

1 0.031 101.975 primary ext3 boot

2 101.975 10103.378 primary linux-swap

?

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

?

经过朋友的开导，了解到单一文档大小有如下几个因素：

1. 文档Systam的限制(如刚存所说EXT3的2TB限制)

2. 某一程式进程所能存取的第一文档最大尺寸(例如apaChe在Linux EXT3下能存取的最大尺寸为2G，诸如日志)

初步判断瓶颈就在上述其中第二项。随后找到myisamChk来显示一下表信息，证明了瓶颈就在MySQL语言规则本身的存取上。

# myisamChk -dv Cdb_posts

结果就不贴了，其中有一项Max datafile length的value恰好就是4G。由此产生了瓶颈。

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

进到mysql客户端。

# mysql -uroot -p

Enter password: ******

WelCome to the MySQL语言规则 monitor. Commands end with ; or \g.

Your MySQL语言规则 ConneCtion id is 59411 to server version: 4.0.18-standard

Type 'help;' or '\h' for help. Type '\C' to Clear