row_format=dynamic能解决大字段溢出，因其对>40字节字段直接外存溢出页、主记录仅留20字节指针，不存前缀，显著降低主记录体积。
为什么 row_format=dynamic 能解决大字段溢出？
MySQL 的 InnoDB 引擎在 row_format=compact（默认）下，对长度超过 768 字节的 VARCHAR、TEXT、BLOB 字段，会把前 768 字节存到主记录页，剩余部分存到独立的溢出页，并用 20 字节指针指向它。但当一行总长度（含所有字段+指针）超 8KB，就可能触发 Row size too large 错误——哪怕单个字段没超限。
row_format=dynamic 改变了这个策略：只要字段长度 > 40 字节，就**直接外存溢出页**，主记录只留 20 字节指针；不保留前缀拷贝。这大幅降低主记录体积，让宽表、多大字段场景更扛得住。
- 适用于含多个
TEXT/VARCHAR(2000)/JSON字段的表 - 不是万能解药：如果单行元数据（列数 + NULL 标志位 + 长度信息等）本身已接近 8KB 上限，改格式也救不了
- 5.7.9+ 默认建表格式已是
DYNAMIC，但老表迁移需手动调整
怎么安全地把老表改成 row_format=dynamic？
不能只改 ROW_FORMAT，必须配合 KEY_BLOCK_SIZE=0（禁用压缩）和完整重建，否则 ALTER TABLE ... ROW_FORMAT=DYNAMIC 可能静默失败或不生效。
- 先确认当前格式：
SHOW CREATE TABLE `your_table`;查看输出里是否有ROW_FORMAT=COMPACT - 执行重建：
ALTER TABLE `your_table` ROW_FORMAT=DYNAMIC, KEY_BLOCK_SIZE=0; - 注意：该操作会锁表（5.6/5.7 中为全表拷贝），生产环境务必选低峰期，或用
pt-online-schema-change - 改完检查：
SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME = 'your_db/your_table';（注意库名转小写+斜杠）
row_format=dynamic 带来的性能与兼容性代价
外存溢出页虽缓解了行大小问题，但引入了额外 I/O 和内存开销：每次读取大字段都要多一次页查找；缓冲池里要同时缓存主记录页和溢出页。
- 查询只涉及小字段时几乎无影响；但
SELECT *或WHERE条件命中大字段值（如WHERE content LIKE '%abc%'），性能下降明显 - 备份恢复时，溢出页分散存储，
mysqldump没问题，但物理备份（xtrabackup）需确保完整拷贝所有关联页 - MySQL 5.5 不支持
DYNAMIC，5.6 需显式开启innodb_file_per_table=ON才生效 - 和
innodb_large_prefix强相关：若要用 >767 字节的索引前缀，必须同时设innodb_large_prefix=ON+ROW_FORMAT=DYNAMIC
比改 row_format 更治本的三个动作
很多“大字段溢出”本质是设计问题。光调格式像给漏水的桶换桶底，不如先堵漏。
- 把高频查询字段和冷数据拆到不同表，比如
article主表只留id/title/summary，正文放article_content表 - 用
MEDIUMTEXT替代LONGTEXT，除非真需要 4GB；JSON字段尽量避免嵌套过深，查时用JSON_EXTRACT()精确取值，别SELECT json_col全拉 - 确认是否真需要存原始富文本或二进制：图片存路径、PDF 存对象存储 URL、日志类内容考虑归档到 Elasticsearch 或 ClickHouse
真正卡住的往往不是格式参数，而是没想清楚“这字段到底谁在什么时候以什么方式访问”。改 ROW_FORMAT 是快招，但容易让人忽略数据分层和访问路径本身是否合理。
