mysql的text字段易拖慢查询，因其默认存于溢出页，主记录仅存20字节指针，读取时触发额外随机i/o；即使未显式查询该列，优化器也可能因统计不准或mvcc跨页访问而加载整行。
MySQL的TEXT字段为什么容易拖慢查询
因为InnoDB默认把TEXT、MEDIUMTEXT、LONGTEXT这类大字段存到“溢出页（overflow page）”里，主记录只保留20字节的指针。一旦查询中需要读取这些字段（比如SELECT *、ORDER BY、GROUP BY或WHERE条件涉及该列），就会触发额外的随机I/O——从聚簇索引页跳转到独立的溢出页，严重放大延迟。
更隐蔽的问题是：即使你只SELECT id, name，只要表里有未被EXCLUDE的大字段，优化器仍可能因统计信息不准或执行计划缓存而加载整行（尤其在READ-COMMITTED隔离级别下，MVCC版本链可能跨页访问）。
如何判断是否真被TEXT拖累
别猜，用EXPLAIN FORMAT=JSON看执行计划里的used_columns和access_type；再结合SHOW PROFILE FOR QUERY N确认Handler_read_next和Handler_read_rnd_next是否异常高。但最直接的是打开innodb_monitor_output观察OS file reads与innodb_pages_read的比值——如果远大于1，说明大量单页随机读，大概率是溢出页访问导致。
- 查表结构时运行
SHOW CREATE TABLE t\G，留意ROW_FORMAT：若为COMPACT或REDUNDANT，且字段长度超768字节，必然溢出 -
SELECT LENGTH(content) FROM t ORDER BY LENGTH(content) DESC LIMIT 5，确认真实数据分布——很多业务里90%的TEXT其实 - 用
INFORMATION_SCHEMA.INNODB_TABLES查AVG_ROW_LENGTH，如果远高于你预估的平均行宽，说明溢出页占比高
绕过溢出页的三种实操路径
核心思路是让大字段不参与主记录加载，或干脆不走InnoDB存储引擎。
- 拆表：把
TEXT字段单独建一张t_content，用id做主键+外键，查询时按需LEFT JOIN。这是最干净的解法，但要注意应用层事务一致性（不能只更新主表就返回成功） - 改用
ROW_FORMAT=DYNAMIC+innodb_file_per_table=ON（MySQL 5.7+默认），并确保建表时显式指定ROW_FORMAT=DYNAMIC——这样只要字段长度≤½页（约8KB），就优先存入本地页，避免指针跳转；但超过后仍会溢出 - 冷热分离：对历史归档数据，把
TEXT导出到对象存储（如S3/MinIO），数据库只留URL和content_hash，应用层按需拉取；适合日志、附件类场景
为什么不要轻易用SUBSTRING或FULLTEXT缓解
SUBSTRING(content, 1, 200)看似省流量，但InnoDB仍要先定位并读取整个溢出页才能截取——开销没少，只是网络传输少了。而FULLTEXT索引虽能加速关键词搜索，但它强制重建倒排索引，写入放大严重，且对短文本或模糊前缀（如LIKE '%abc'）无效。
真正有效的轻量级替代是：把高频检索的元信息（如首段摘要、关键词标签、内容长度、MD5哈希）冗余到主表的VARCHAR列中，用触发器或应用层维护一致性。这样WHERE summary LIKE '%error%'就能走普通索引，完全避开TEXT字段。
溢出页不是bug，是InnoDB为平衡短字段访问效率和长字段存储弹性做的权衡。问题往往不出在TEXT本身，而出在“所有字段无差别SELECT”和“所有场景都用同一张表”的设计惯性上。
