大字段性能问题源于InnoDB的off-page存储机制，导致多次随机I/O和缓存污染；必须通过垂直拆表、物化排序列、禁用SELECT *等方式从结构层面解决。
大字段不是“加个索引就能快”，而是从建表那一刻起就决定了后续所有查询的上限。TEXT/BLOB 字段一旦和主表耦合，SELECT *、ORDER BY、备份、缓存都会陆续出问题——这不是配置能救的，是结构级缺陷。
为什么 TEXT/BLOB 一查就慢，且 EXPLAIN 看不出明显异常
因为 InnoDB 对超过 768 字节的内容默认启用 off-page 存储：主记录只留 20 字节指针，真实数据散落在独立溢出页。一次 SELECT * 表面读 1 行，实际要触发多次随机 I/O（主页 + 若干溢出页），SSD 上也容易打爆 buffer pool。
更隐蔽的问题是：哪怕你没显式引用该字段，只要语句带 ORDER BY created_at 且表里存在 TEXT 字段，MySQL 优化器也可能放弃内存临时表，强制走磁盘临时表——EXPLAIN 显示 Using temporary; Using filesort，但 type 和 key 看不出 TEXT 的存在。
- 确认是否真用了溢出页：先查
SHOW CREATE TABLE t\G看ROW_FORMAT是DYNAMIC还是COMPACT；再执行SELECT LENGTH(content) FROM t WHERE id = 123，若 > 8000 且格式为 DYNAMIC，基本已进溢出页 -
SHOW ENGINE INNODB STATUS中观察Buffer pool hit rate是否骤降，这是大字段污染缓存的直接信号 - 慢查询日志里
Rows_examined远大于Rows_sent，大概率是溢出页反复跳读导致
TEXT 和 BLOB 必须严格区分用途，不能混用
存纯文本却用 BLOB 是常见错误：BLOB 不走字符集校验，ORDER BY、LIKE 'xxx%'、前缀索引全部失效；而 TEXT 支持完整字符集、可建 FULLTEXT、能参与排序比较。
- 文本类内容一律用
MEDIUMTEXT（16MB），显式指定字符集：ALTER TABLE t MODIFY content MEDIUMTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci - 二进制流（图片、PDF、加密数据）才用
MEDIUMBLOB；别为了“以后可能变大”直接上LONGBLOB，InnoDB 对超大字段会强制 off-page，哪怕只存 1KB 也可能多一次 I/O - 已有非法字节数据（如原始 dump）时，不要依赖 MySQL 自动转换，先在应用层清洗
查询必须绕开大字段本体，而不是压缩或截断
压缩、SUBSTRING、虚拟列哈希这些操作本身不解决根本问题——它们只是让“不得不读大字段”的场景变得更轻量。真正有效的做法是让排序、分组、JOIN 完全脱离该字段。
- 把排序依据物化成独立列：
ALTER TABLE t ADD content_updated_at DATETIME NOT NULL DEFAULT '1970-01-01'，应用层同步更新，然后ORDER BY content_updated_at - 用虚拟列做摘要：
ALTER TABLE t ADD content_md5 CHAR(32) AS (MD5(content)) STORED，再建索引：CREATE INDEX idx_content_md5 ON t(content_md5)；查询写法必须带防碰撞校验：WHERE content_md5 = MD5('xxx') AND content = 'xxx' - 绝对避免
ORDER BY UPPER(content)或GROUP BY JSON_EXTRACT(content, '$.title')，这类表达式会让优化器直接放弃内存临时表
垂直拆表或外存才是多数场景的终点
当单条记录中大字段平均超 100KB，或访问频次明显低于主键字段时，继续留在主表已无性价比。拆表不是“过度设计”，而是把 I/O 压力从高频路径上移除。
- 拆表示例：
CREATE TABLE article_bodies (article_id INT PRIMARY KEY, body MEDIUMTEXT)，主表article只保留元数据；关联查询用LEFT JOIN按需加载 - 对 >1MB 的文件，数据库只存路径：
/uploads/2026/article_456.html，文件本身交由 OSS、S3 或本地文件服务托管 - 如果业务允许，把大字段表单独挂到机械盘（HDD）上——大块顺序读比 SSD 更适合这种负载
最容易被忽略的一点：即使你做了所有优化，只要还在用 SELECT *，前面所有努力就白费。大字段的代价不在存储，而在每次不经意的全字段读取中悄悄兑现。
