DYNAMIC行格式通过将大字段移出主记录页仅保留20字节指针，提升INSERT/UPDATE效率、降低页分裂概率；COMPRESSED虽省空间但显著拖慢写入，CPU成为瓶颈，仅适用于读多写少归档表。
DYNAMIC 行格式能减少页分裂，但 COMPRESSED 会拖慢写入
MySQL 的行格式不是“设了就完事”的元数据，它直接决定每条记录在磁盘页（16KB）里怎么排布、溢出字段怎么处理、甚至是否启用压缩。DML 操作（INSERT、UPDATE、DELETE）频繁触碰页结构和缓冲池，行格式选错，性能损耗立刻可见。
为什么 DYNAMIC 能提升 INSERT/UPDATE 效率？
DYNAMIC 是 InnoDB 5.7+ 默认行格式，核心改进是把大字段（如 VARCHAR、TEXT、BLOB）的完整值移出主记录页，只在原位置保留 20 字节指针。这带来三个实际好处：
- 单页能塞进更多主记录，降低 B+ 树层级，
SELECT和UPDATE定位更快 - 更新非溢出列时，不用移动大字段内容，避免页内大量数据搬移
- 插入新行时，页剩余空间更容易满足“紧凑插入”条件，减少页分裂概率
对比 COMPACT：它把溢出字段前 768 字节存入主记录页，剩余部分外链。一旦字段值略超阈值，就会触发额外 I/O 和指针维护开销，UPDATE 大文本字段时尤其明显。
COMPRESSED 行格式对 DML 的真实代价
ROW_FORMAT=COMPRESSED 看似省空间，但 DML 性能代价常被低估。它要求每个页在读写时都做实时压缩/解压，CPU 成为瓶颈：
-
INSERT吞吐量下降约 50%（实测 write_only 场景 TPS 从 2688 降至 1166） -
UPDATE需先解压整页、修改、再压缩回写，延迟翻倍（95% 延迟从 19ms 升至 45ms） - CPU 占用飙升，在高并发写入下容易成为系统瓶颈，尤其小规格云数据库实例
- 不支持在线 DDL 修改为 COMPRESSED，必须
ALTER TABLE ... FORCE全表重建
它只适合读多写少、磁盘 I/O 确实受限且 CPU 有富余的归档类表，而非业务主表。
REDUNDANT 和 COMPACT 在现代 MySQL 中基本该淘汰
REDUNDANT 是 MySQL 5.0 以前的遗留格式，存储冗余度高，单页记录数少，已完全无使用价值。COMPACT 虽曾是 5.6 默认，但它对长字段的处理方式（768 字节内联 + 外链）导致：
- 相同数据量下，页利用率比 DYNAMIC 低 15–20% UPDATE 某个刚好跨 768 字节边界的字段，可能触发“内联转外链”，引发隐式页分裂
- 没有针对二级索引中大字段的优化，索引页也易膨胀
除非要兼容极老版本备份恢复，否则新建表不要选这两个。
真正要注意的是：行格式变更必须配合 ALTER TABLE ... ROW_FORMAT=DYNAMIC 并指定 ALGORITHM=INPLACE（5.6+ 支持），否则默认会锁表重建。而压缩表的 KEY_BLOCK_SIZE 设置错误（比如设成 0 或不匹配 page size）会导致 ALTER 失败或后续 DML 报 ERROR 1812 —— 这个细节，很多人在上线前才踩到。
