innodb空表即占16kb而myisam可从几kb起步，是因innodb以16kb页为最小单元并需初始化聚簇索引结构（含页头、infimum/supremum等），myisam则按需分配；delete不释放空间是因仅逻辑标记删除供复用，非物理截断，须optimize table或alter table engine=innodb重建表才能真正收缩文件。
InnoDB表一建就比MyISAM大，不是配置错，是设计使然——空表也占16KB，DELETE不缩文件，空间增长主因是聚簇索引结构和页内碎片，不是日志。
为什么新建InnoDB空表就比MyISAM大得多
MyISAM的.MYD和.MYI文件按需分配，空表可能只有几KB；InnoDB最小存储单元是16KB页，哪怕CREATE TABLE t(id INT) ENGINE=InnoDB也会立即生成一个16KB的t.ibd文件。这不是bug，是InnoDB必须初始化聚簇索引页头、infimum/supremum记录、空闲空间链表等结构导致的。
前提条件是innodb_file_per_table=ON（强烈建议开启）；若为OFF，所有表都挤在ibdata1里，初始就几百MB且永不收缩。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
DELETE后磁盘空间不释放是正常行为
InnoDB的DELETE只是标记记录为“已删除”，供后续INSERT复用页内空闲空间，但不会合并释放回文件系统。执行DELETE FROM t WHERE id > 1000后，ls -lh t.ibd和du -sh完全不变。
- 真正释放磁盘空间要靠
OPTIMIZE TABLE t或ALTER TABLE t ENGINE=InnoDB（重建表，丢弃空洞） -
OPTIMIZE TABLE在innodb_file_per_table=OFF下无效 - 重建操作会锁表，MySQL 5.7+可用
ALGORITHM=INPLACE减少影响，但非所有场景都支持
评估真实增长不能只看当前表大小
静态计算（如行数 × 平均长度）会严重失真。必须分层估算：
-
主业务表：日均新增行数 ×
AVG_ROW_LENGTH× 1.3（补页内碎片）× 天数 -
binlog：日均DML量 × 单条事件体积（简单更新约200–500B，含TEXT/BLOB翻倍）×
binlog_expire_logs_seconds（或expire_logs_days） -
undo log：若长事务多或
innodb_undo_log_truncate=OFF，需查INFORMATION_SCHEMA.INNODB_METRICS中undo_log_written指标 -
临时文件：
GROUP BY/ORDER BY高峰期写tmpdir，可能占几十GB（但通常不持久）
容易被忽略的关键点
很多人把空间增长归因于redo/undo日志，其实核心在于聚簇索引机制：数据与主键强制耦合在同一B+树页中，页填充因子、二级索引冗余（尤其含TEXT字段时）、索引列重复存储都会推高实际占用；MyISAM数据和索引分离，压缩率更高、复用更灵活。实测中CHAR(120)在InnoDB+ROW_FORMAT=DYNAMIC下可能省空间，但这属于特例——一旦字段改VARCHAR或填满内容，MyISAM立刻反超。
