InnoDB新建空表即占16KB，因其以页为最小I/O单元，默认页大小16KB，建表时即分配并初始化完整页结构；MyISAM则按需增长，.MYD可为0字节。
为什么新建空表就占16KB：InnoDB的页初始化机制
InnoDB新建空表时，.ibd 文件立刻就是16KB，不是bug，是设计使然。它的最小I/O单元是页（page），默认16KB，建表即分配一个完整页，并填入页头、infimum/supremum记录、空闲空间链表等元数据结构。MyISAM则不同：.MYD 可为0字节，.MYI 仅存根节点索引，通常几百字节起步。
这个差异直接影响小表场景下的磁盘感知：你执行 CREATE TABLE t (id INT) ENGINE=InnoDB 后立刻 ls -lh t.ibd，看到的就是 -rw-r----- 1 mysql mysql 16K；而同结构 MyISAM 表的 .MYD 很可能显示 0。
-
innodb_file_per_table=OFF时，所有表挤在ibdata1，初始就几百MB，且删库也不释放 - 即使只插入一行，InnoDB仍占用整页；MyISAM按行实际长度+行头开销动态增长
- 页内空闲空间不自动归还文件系统，DELETE后
du -sh不变是正常现象
DELETE不缩文件：标记删除 vs 物理截断
InnoDB 的 DELETE FROM t WHERE ... 只是把记录打上删除标记，加入 purge 队列，对应页内的空闲空间保留在原页中供后续 INSERT 复用——它不合并页、不收缩文件、不归还磁盘给操作系统。MyISAM 则相反：执行 DELETE 后若触发重建（如 OPTIMIZE TABLE 或自动整理），会真正丢弃空洞、重写 .MYD 文件并截断尾部。
所以你执行完大范围 DELETE，观察 ls -lh t.ibd 和 du -sh t.ibd 均无变化，这不是空间泄漏，而是 InnoDB 的空间复用策略。要真正释放磁盘，必须显式重建：
-
OPTIMIZE TABLE t（仅当innodb_file_per_table=ON时有效） -
ALTER TABLE t ENGINE=InnoDB（本质也是重建） - MyISAM 下同操作会直接重写
.MYD，效果立竿见影
聚簇索引导致数据无法“碎片化压缩”
InnoDB 强制主键索引与数据行物理共存于同一B+树，即“聚簇索引”。这意味着：主键值决定数据存放位置，非主键索引（二级索引）叶子节点存的是主键值而非行地址。这种结构带来I/O优势，但也锁死了空间复用逻辑——页内空洞只能被相同主键范围的新数据填充，无法像 MyISAM 那样把零散空洞拼成大片再分配。
MyISAM 是堆表（heap table），数据按插入顺序追加，.MYD 中的空洞可被任意新行复用，配合 myisamchk --recover 还能主动整理。而 InnoDB 的页内空闲链表只服务本页，跨页合并需重建整个索引树。
- 大量随机 DELETE + INSERT 后，InnoDB 表更容易出现“逻辑空洞多但物理文件不缩”的情况
- MyISAM 的
.MYI索引支持压缩（myisampack），InnoDB 的索引压缩（KEY_BLOCK_SIZE）作用有限，因聚簇结构限制了压缩粒度 - 别指望
ROW_FORMAT=COMPRESSED能大幅减小已存在空洞的.ibd，它只影响新写入页
CHAR字段在InnoDB里真更省空间？别轻信
确实存在 InnoDB 表比 MyISAM 小的特例：比如全 CHAR(120) 字段、高比例 NULL 或尾部空格，且使用 ROW_FORMAT=DYNAMIC。这时 InnoDB 对 CHAR 尾部空格不存储，而 MyISAM 在 FIXED 行格式下会为每个 CHAR(120) 固定分配 120 字节。
但这只是边界案例，不可泛化：
- 一旦字段含非空内容、或改用
VARCHAR，MyISAM 立刻反超（因索引分离+压缩） - MyISAM 的
.MYI支持前缀压缩，InnoDB 二级索引无法享受同等压缩率 - 真实业务中，这种“InnoDB更小”的表极少，且依赖具体填充模式，不具备可迁移性
真正影响磁盘体积的关键，从来不是字段类型微调，而是 innodb_file_per_table 是否开启、是否长期未重建、以及是否混用了大对象（如 TEXT 存储在溢出页）。这些比纠结 CHAR 尾部空格重要得多。
