myisam单表大小由文件系统单文件上限和内部指针长度共同决定：默认6字节指针支持约256tb，通过max_rows可扩展至7字节、理论64pb；实际受限于os文件系统（如ext4限16tb、xfs限500tb）及inode、磁盘空间等运行环境因素。

MyISAM单表大小由文件系统和指针长度共同决定

MyISAM表物理上拆成.frm、.MYD、.MYI三个独立文件，因此它的上限取决于操作系统对单个文件的支持能力（比如ext4支持16TB，xfs支持500TB），以及MyISAM内部用的文件指针长度。默认指针是6字节（2⁴⁸ ≈ 256TB），但可通过编译或CREATE TABLE时指定MAX_ROWS和AVG_ROW_LENGTH来扩展——例如ALTER TABLE t MAX_ROWS=1000000000 AVG_ROW_LENGTH=100会把指针逻辑升级到7字节，理论顶到64PB。

常见错误现象：ERROR 1114 (HY000): The table 't' is full，往往不是磁盘满了，而是指针溢出或文件系统单文件限制触发（如FAT32的4GB上限）。

• 查当前表指针容量：运行myisamchk -dv t，看输出里的Record format:行，若显示fixed或dynamic后跟pointer: 6，说明当前是6字节指针
• 新建大表前必须显式设MAX_ROWS，否则即使OS支持PB级，MyISAM仍按默认4GB或256TB保守处理
• information_schema.TABLES.DATA_LENGTH对MyISAM基本可信，因为它直接映射.MYD文件长度；但du -sh更准，尤其涉及文件系统块对齐时

InnoDB单表大小受限于表空间类型和页管理机制

InnoDB不依赖单个文件大小，而取决于它用的是共享表空间（ibdata1）还是独享表空间（.ibd）。前者所有表挤在一起，上限是InnoDB自己定义的64TB；后者每个表一个.ibd文件，就退化为文件系统限制——但关键在于，InnoDB以16KB页为最小单位分配空间，哪怕只插一行也占满一页，且页内碎片不会自动合并释放。

容易踩的坑：OPTIMIZE TABLE在innodb_file_per_table=OFF时完全无效；DELETE后du -sh t.ibd不变不是bug，是设计使然——它只标记记录可复用，不归还页给文件系统。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 确认是否启用独享表空间：查SHOW VARIABLES LIKE 'innodb_file_per_table'，值为ON才可对单表收缩
• 真实物理大小必须用du -sh /var/lib/mysql/db_name/t.ibd，information_schema.TABLES返回的是逻辑数据量，不含页头、空闲链表、未purge的undo等开销
• 重建表收缩空间只能用ALTER TABLE t ENGINE=InnoDB或OPTIMIZE TABLE t，但会加MDL锁，写入期间阻塞

自增主键才是你最先撞上的“容量墙”

无论MyISAM还是InnoDB，实际业务中最先卡住你的几乎从来不是文件大小，而是AUTO_INCREMENT列的数据类型上限。比如INT UNSIGNED最大值是4294967295，一到这个数再插入就会报ERROR 1062 (23000): duplicate entry '4294967295' for key 'primary'——引擎根本没机会走到文件写满那步。

这问题在InnoDB里更隐蔽：因为事务ID（trx_id）也是32位（部分版本）或64位，长事务不提交会导致innodb_max_trx_id逼近上限，触发ERROR 1712，表面看像容量问题，实则是事务系统枯竭。

• 建表时优先用BIGINT UNSIGNED作主键，避免过早触达42亿瓶颈
• 监控SELECT @@innodb_max_trx_id，持续接近4294967295说明有长事务阻塞回收
• MyISAM没有事务ID概念，但MAX_ROWS设太小也会导致ERROR 1114，需同步检查

别信文档写的“64TB”，先看你的du和df

官方说MyISAM支持64PB、InnoDB支持64TB，这些数字只在理想条件下成立：文件系统支持、内核配置允许、磁盘足够、没有其他进程争抢inode或空间。现实中，df -h显示可用空间还有200GB，但INSERT突然失败，大概率是inode耗尽（df -i）、tmpdir空间不足，或者ib_logfile占满磁盘——InnoDB的redo log和undo表空间会持续增长，尤其在大批量导入或长事务场景下。

真正影响单表能否继续写入的，往往不是“理论最大值”，而是当前磁盘剩余、innodb_undo_tablespaces配置、innodb_log_file_size设置，以及是否开了log_bin导致binlog文件暴涨。

• 定期用df -h和df -i双查，特别是/var/lib/mysql所在分区
• 查undo空间占用：SELECT * FROM information_schema.INNODB_METRICS WHERE NAME LIKE '%undo%';
• 大表导入前确保tmpdir挂载点有足够空间，否则ALTER TABLE重建会失败