ROW_FORMAT选型关键在于避免长字段干扰主记录布局和随机IO。COMPACT因768字节溢出易致抖动；DYNAMIC用20字节指针分离存储，但需配合innodb_file_per_table=ON；根治宽表应字段分层、显式拆分并结合对象存储。
ROW_FORMAT 选型不是“选快的”，而是“选不拖慢的”。超宽表（比如单行字段数超 50、平均行长超 2KB）下，ROW_FORMAT=COMPACT 或 DYNAMIC 都可能因隐式溢出和页分裂导致查询抖动、写入放大。真正关键的是：**让长字段不干扰主记录布局，且避免频繁的 off-page 存储触发随机 IO**。
为什么 COMPACT 在超宽表里容易翻车
COMPACT 是 InnoDB 默认行格式，但它把变长字段（VARCHAR、TEXT、BLOB）的前 768 字节存进主数据页，剩余部分单独存到溢出页（off-page）。问题在于：
- 只要某一行任意一个
VARCHAR超过 768 字节，就大概率触发溢出——哪怕其他 49 个字段都很短； - 查询时若需读取该字段完整值，就得额外一次随机 IO 去找溢出页；
- UPDATE 该字段时，如果新值长度变化大，InnoDB 可能要重分配溢出页，甚至引发整行迁移；
-
ANALYZE TABLE统计信息里avg_row_length严重失真，优化器容易误判扫描成本。
DYNAMIC 行格式怎么缓解这个问题
ROW_FORMAT=DYNAMIC 把所有变长字段的完整内容都移出主数据页，主记录只留 20 字节指针。这听起来更“干净”，但要注意：
- 它不会减少总存储量，只是把 IO 模式从“混合”变成“确定的两次跳转”；
- 如果业务经常
SELECT *或查多个大字段，DYNAMIC实际延迟更高（每次都要 fetch 溢出页）； - 必须配合
innodb_file_per_table=ON，否则溢出页会混在系统表空间里，无法回收空间； - 建表时显式指定：
CREATE TABLE t (...) ROW_FORMAT=DYNAMIC;，ALTER TABLE 切换需要重建全表（锁表时间长）。
真正有效的宽表存储策略：字段分层 + 显式拆分
靠改 ROW_FORMAT 只是止痛，根治得从表结构入手。我们在线上千万级日志宽表上验证过这套做法：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 把字段按访问频次和长度分三类：高频核心字段（如
id、user_id、status）、中频可延迟字段（如extra_info JSON、trace_id）、低频大字段（如raw_payload TEXT、dump BLOB）； - 核心字段保留在主表，用
ROW_FORMAT=DYNAMIC； - 中频字段单独抽成
_ext扩展表，用user_id + created_at联合主键，避免自增 ID 带来的写热点； - 低频大字段直接剥离到对象存储（如 S3/MinIO），主表只存 URL 和校验码，彻底消除 IO 压力；
- 所有 JOIN 查询改用应用层双查（先查主表 ID，再并发查扩展表或对象存储），比单条 SQL JOIN 多张宽表稳定得多。
别忽略的细节：页大小与填充因子
即使用了 DYNAMIC，超宽表仍可能因单页存不下几行而浪费大量空间。InnoDB 默认 innodb_page_size=16K，但如果你的平均行长 > 4KB，一页最多存 3–4 行，页利用率常低于 30%。这时：
- 不要盲目调大
innodb_page_size（需初始化时设定，不可运行时改）； - 改用
innodb_fill_factor=70（默认 100），预留空间给后续 UPDATE 不触发页分裂； - 对纯追加写场景（如日志表），可考虑关闭
innodb_doublewrite=OFF（仅限有 RAID 或文件系统级保护的环境）； - 务必定期跑
OPTIMIZE TABLE或ALTER TABLE ... FORCE，因为宽表的碎片率上升极快，DATA_FREE值很容易突破总大小的 20%。
实际效果取决于字段分布是否真的“宽”——如果只是列数多但每列都很短（比如 100 个 TINYINT），COMPACT 反而更省空间、更少跳转。别被“宽”字带偏，先用 SELECT AVG(LENGTH(CONCAT(...))) FROM t LIMIT 10000 算真实行长，再决定动不动行格式。
