TEXT字段触发行溢出是因为InnoDB对单行预估长度超约8000字节时，自动将TEXT等大字段内容移至溢出页，仅留20字节指针；虽非错误，但引发额外I/O、SELECT *性能下降等问题。
为什么 TEXT 字段会触发行溢出（Row Overflow）
InnoDB 对单行数据有约 8000 字节的隐式限制（实际受页大小、其他字段长度共同影响），一旦某行所有列的**预估长度总和超过这个阈值**，就会把大字段（如 TEXT、BLOB、长 VARCHAR）的内容从聚簇索引页中剥离，只在原位置保留 20 字节的指针，真实数据存到单独的溢出页（overflow page）中。
这不是错误，而是 InnoDB 的默认行为。但会导致：查询时多一次或多次随机 I/O（需回表读溢出页）、SELECT * 性能骤降、备份/复制延迟升高。
-
TEXT和MEDIUMTEXT默认走溢出；TINYTEXT（≤255 字节）可能不溢出，取决于整行剩余空间 - 即使
TEXT当前为空或只存几个字，只要定义了该列，InnoDB 就按最大可能长度（65535 字节）参与行长度估算 -
ROW_FORMAT=COMPACT（MySQL 5.6+ 默认）和REDUNDANT明确启用溢出；DYNAMIC同样溢出但更激进地外存长字段；COMPRESSED也遵循溢出逻辑
如何判断某行是否已发生溢出
直接查 information_schema.INNODB_SYS_TABLES 和 INNODB_SYS_INDEXES 不够直观。更实用的方法是结合 SHOW TABLE STATUS 和 INFORMATION_SCHEMA.INNODB_BUFFER_PAGE（需开启 innodb_buffer_page 监控）观察页面类型：
- 执行
SHOW TABLE STATUS LIKE 'your_table'，关注Avg_row_length—— 若远大于你所有非大字段的总宽（比如算出来应是 200 字节，却显示 5000+），大概率已有溢出 - 对某条记录执行
SELECT LENGTH(your_text_col) FROM your_table WHERE id = X，再对比该行其他字段总长度；若总和明显超 8K，基本可确认溢出已发生 - 启用
innodb_monitor_enable = 'innodb_buffer_page'后查INFORMATION_SCHEMA.INNODB_BUFFER_PAGE，过滤PAGE_TYPE = 'BLOB'或'SYS_UNDO_LOG'可间接定位溢出页（但生产慎用，开销大）
ROW_FORMAT=DYNAMIC 能不能避免溢出
不能避免，但能优化溢出策略：它让 InnoDB 更倾向于把整个长字段外存（而非只存前 768 字节），从而释放主索引页空间，降低因溢出导致的二级索引膨胀问题。
-
COMPACT：对TEXT/BLOB仅在主键页存前 768 字节 + 20 字节指针，其余外存 → 容易撑满页、触发页分裂 -
DYNAMIC：主键页只存 20 字节指针，全部内容外存 → 主索引页更“干净”，二级索引更小，适合高频更新 + 大文本场景 - 修改方式：
ALTER TABLE your_table ROW_FORMAT=DYNAMIC;，但需确保innodb_file_format=Barracuda（MySQL 5.7+ 已废弃此参数，自动支持）且innodb_file_per_table=ON - 注意：切换
ROW_FORMAT会锁表并重建整表，大数据量务必在低峰期操作
真正减少溢出影响的实操建议
与其纠结是否溢出，不如控制溢出带来的副作用。以下措施见效快、风险低：
- 查询时明确排除
TEXT字段：SELECT id, title, created_at FROM article，避免无意义的溢出页读取 - 为高频检索字段建覆盖索引：
CREATE INDEX idx_cover ON article (status, created_at) INCLUDE (id, title)（MySQL 8.0.13+ 支持INCLUDE，否则用联合索引+冗余字段） - 业务层做文本截断存储：如日志类内容，只存前 2000 字到
TEXT，完整内容另存对象存储（OSS/S3），数据库里留个url字段 - 评估是否真需要
TEXT：纯 JSON 配置？考虑JSON类型（MySQL 5.7+），它支持部分下推查询且 InnoDB 对其做了专门优化，溢出行为与TEXT不同
溢出本身不可怕，可怕的是默认全选、缺乏索引、以及把数据库当对象存储用。很多性能问题，其实卡在没想清楚「这字段到底谁读、怎么读、读多深」。
