MyISAM表默认最大容量4GB：并非硬性限制，而是配置陷阱
之前有读者询问，为什么MyISAM表增长到4GB左右就“卡住”了？实际上，这并非存储引擎本身设定的绝对上限，而是默认配置与常见文件系统限制共同作用下的“感知阈值”。
起初，MySQL创建MyISAM表时，默认使用4字节的行指针（myisam_data_pointer_size=4），这意味着理论最大行数约为2³²，即42.9亿行。如果按平均行长度估算，单表容量恰好落在4GB附近。这不是MyISAM的终极容量，只是默认配置下的“出厂设定”。
扩容三要素：操作系统、大文件支持与显式指定MAX_ROWS
要突破这个4GB界限，需要同时满足三个条件：操作系统支持大文件、MySQL版本启用了LFS（大文件支持）、建表时显式指定足够大的MAX_ROWS。这三个条件缺一不可。
核心操作是：建表时不仅要写MAX_ROWS，还要设置一个足够大的具体数值，比如10⁹。该数值会反向推导出所需的指针长度，从而覆盖原本的myisam_data_pointer_size配置。例如：
CREATE TABLE t (id INT, data TEXT) ENGINE=MyISAM MAX_ROWS=1000000000 A VG_ROW_LENGTH=200;
这个语句会让MySQL自动选用6字节指针（支持2⁴⁸行），从而将单表理论上限提升到256TB。注意：MAX_ROWS必须设为具体整数，设为0或留空则等于没设。
- 已存在的表可用
ALTER TABLE t MAX_ROWS=1000000000 A VG_ROW_LENGTH=200;在线修改（不锁表，但会触发REPAIR TABLE式重建） - 修改后务必运行
SHOW TABLE STATUS LIKE 't';，检查Max_data_length字段是否已更新 - 若
Max_data_length仍是4294967295（即2³²−1），说明MAX_ROWS未生效——常见原因是数值太小，未触发指针升级
操作系统与文件系统：最终的天花板
即使MySQL允许256TB，最终还得看底层的操作系统和文件系统是否“买账”。如果ext4分区挂载时使用了-O ^large_file，或者运行在32位内核加老版glibc上，open()系统调用仍可能返回EFBIG错误。
必须检查的几项：
- 运行
getconf FILESIZEBITS /，输出≥64才表示内核支持大文件 - 确认文件系统类型：
df -T .，ext4/xfs/btrfs通常支持≥16TB，fat32/ntfs需额外验证 - MySQL错误日志中若出现
Got error 24 from storage engine或write failed on MyISAM file，大概率是OS层拒绝写入超限文件
Linux 2.4+、x86_64、ext4默认支持单文件≥16TB；Windows下必须使用NTFS，且要禁用“压缩”和“加密”属性——这两项会让MySQL写入失败。
别混淆了：key_buffer_size与表大小无关
还有一个常见误区：有人以为把key_buffer_size设大就能撑住大MyISAM表。实际上，key_buffer_size只缓存.MYI索引块，不影响.MYD数据文件的物理尺寸。哪怕把key_buffer_size设到32G，一个200GB的MyISAM表照样能建出来——只是查询慢、缓存命中率低而已。真正制约表大小的，永远是MAX_ROWS推导出的指针长度，以及OS对单个文件的写入权限。
容易被忽略的是：MyISAM表一旦含大量TEXT/BLOB字段，其INDEX_LENGTH在information_schema里统计准确，但Data_length可能严重低估真实磁盘占用——因为外部存储的BLOB不计入该字段。查真实大小请用du -sh *.MYD。
