TEXT/BLOB字段在DYNAMIC/COMPRESSED行格式下，内容超约8000字节时会自动存入溢出页，仅留20字节指针在主记录中，导致额外I/O、缓存效率下降和查询变慢；确认需结合行格式与实际长度判断，而非仅看字段类型。
MySQL 中 TEXT/BLOB 字段触发行溢出页，不是 bug，而是 InnoDB 在 ROW_FORMAT=DYNAMIC 或 COMPRESSED 下的正常行为。它本身不报错，但会悄悄把字段主体挪到独立溢出页，导致查询变慢、缓存效率下降——关键在于你是否意识到这个 I/O 开销正在发生。
怎么确认某条记录真的用了溢出页
不能只看字段类型是 TEXT 就断定用了溢出页；得看实际内容长度和当前行格式。最直接的办法是查 INFORMATION_SCHEMA.INNODB_SYS_TABLES 和 INFORMATION_SCHEMA.INNODB_SYS_COLUMNS，但更实用的是用 SHOW CREATE TABLE 确认行格式，并结合内容长度做判断：
-
SHOW VARIABLES LIKE 'innodb_default_row_format';—— 多数 MySQL 5.7+ 返回DYNAMIC -
SELECT LENGTH(content) FROM article WHERE id = 1;—— 如果结果 > 8000 字节，且表是DYNAMIC格式，基本就进了溢出页 - 执行
SELECT * FROM article时用EXPLAIN FORMAT=JSON查看是否出现"using_temporary_table": true或明显延迟，是间接信号
为什么 SELECT * 会突然变慢，而只查几个字段就快
因为 SELECT * 强制读取所有列，包括被移到溢出页的 content 字段，InnoDB 必须额外发起一次（或多次）随机磁盘 I/O 去加载那些溢出页；而 SELECT id, title, summary 这类不含大字段的查询，整行数据能塞进主数据页，一次读完。
- 溢出页地址只存 20 字节指针在主记录里，不读就不触发加载
- Buffer Pool 缓存的是页，不是字段；溢出页分散，缓存命中率天然低
- 全表扫描时，每行都可能触发一次额外 I/O，QPS 直接腰斩很常见
TEXT 改成 VARCHAR 能避免溢出页吗
不能，反而可能让问题更隐蔽甚至失败。VARCHAR 的最大理论长度受整行限制（65535 字节），还要扣除其他字段、长度头、NULL 标识等开销。一旦定义 VARCHAR(60000)，建表时大概率被 MySQL 自动转成 TEXT，并伴随 warning：
Warning | 1246 | Converting column `content` from VARCHAR to TEXT
-
VARCHAR只有在内容短（比如 - 想靠加长
VARCHAR避免溢出页，等于在撞 InnoDB 行大小硬限制，大概率失败或被静默转换 - 真要控制溢出，优先考虑业务层截断、压缩、或拆分存储（如正文 + 摘要 + 标签三张表）
哪些操作会意外放大溢出页影响
不是所有读都会触发溢出页加载，但这些操作会：
-
ORDER BY或GROUP BY涉及 TEXT/BLOB 字段 —— InnoDB 可能需要完整值排序，强制加载溢出页 -
WHERE content LIKE '%xxx%'—— 即使没索引，优化器也可能决定全扫+逐行加载溢出内容 - 使用
mysqldump导出整表 —— 默认SELECT *，每行都拉溢出页，导出速度骤降 - 开启
innodb_file_per_table=OFF时，溢出页混在系统表空间，碎片更难清理
最容易被忽略的是：溢出页一旦生成，不会因后续更新变短而自动回收回主记录——哪怕你把 content UPDATE 成空字符串，那 20 字节指针还在，溢出页仍占磁盘空间，直到执行 OPTIMIZE TABLE 或重建表。
