TEXT字段慢因InnoDB采用溢出页存储，超768字节时主记录仅存20字节指针，查询需额外随机I/O读取溢出页；若参与ORDER BY/GROUP BY，更会全量加载至内存引发OOM或超时。
TEXT 字段为什么慢？先看 InnoDB 的存储结构
InnoDB 对 TEXT 和 BLOB 类型默认采用「溢出页（off-page）」存储：当单个值超过约 768 字节时，主记录只保留 20 字节指针，真实数据被挪到独立的溢出页中。这意味着一次普通 SELECT * 可能触发额外的随机 I/O —— 主页读完还得跳去读溢出页，尤其在机械盘或高并发场景下延迟明显。
更麻烦的是，如果查询里有 ORDER BY、GROUP BY 或临时表涉及该字段，MySQL 很可能把整段 TEXT 拉进内存做排序/聚合，直接撑爆 sort_buffer_size 或填满 tmp_table_size，报错 MySQL server has gone away 或严重拖慢响应。
什么时候该拆分 TEXT 字段？判断依据很实际
不是所有大文本都得动结构。先问三个问题：
- 这个字段是否几乎从不参与
WHERE、JOIN、ORDER BY？—— 如果只是展示用，且平均长度 >4KB，就适合分离 - 应用层是否允许「按需加载」？比如详情页才 GET /api/article/{id}/content
- 有没有现成的外部存储方案（如对象存储、本地文件系统）？
满足以上三点，建议把 content 这类字段从主表移出，主表只留 content_url 或 content_hash，查正文时单独请求。
不改表结构也能提速：关键参数与查询写法
如果暂时无法重构，可通过配置和 SQL 写法缓解：
- 设
innodb_large_prefix = ON（5.7+ 默认开启），配合ROW_FORMAT=DYNAMIC或COMPRESSED，让更长的前缀保留在聚簇索引页内，减少溢出概率 - 避免
SELECT *，明确列出需要的字段，把TEXT字段放到最后，或完全不查（用SELECT id, title FROM article） - 加覆盖索引时别包含
TEXT字段 ——INDEX idx_cover (status, created_at)可行，但INDEX idx_bad (status, content)会失败或被忽略 - 用
SUBSTRING(content, 1, 500)替代全量读取做摘要展示，注意 MySQL 8.0+ 对SUBSTRING在溢出列上优化更好
溢出页本身能优化吗？答案是：基本不能，但可监控
InnoDB 不提供手动整理溢出页的命令，OPTIMIZE TABLE 对已溢出的 TEXT 数据效果有限 —— 它只会重建主索引页，溢出页仍散落各处。真正有用的是监控：
- 查
information_schema.INNODB_SYS_TABLES看FILE_FORMAT和ROW_FORMAT - 用
SHOW ENGINE INNODB STATUS\G观察Buffer pool hit rate是否因频繁读溢出页而下降 - 慢日志里留意含
TEXT字段的查询是否常带Using temporary; Using filesort
溢出页就像老房子的阁楼：你没法重排它，但至少要知道哪些查询总往那儿跑，再决定是搬东西下来，还是干脆另盖仓库存。
