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

核心提示： 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 WITH

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文件系统的相关技术参数，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这个参数。事实证明这些都是歧途。大晚上的确实很累，这里只给出最终的解决方案吧，中间的就不罗嗦了。