如何优化SQL长文本字段查询_通过选择性返回减少IO消耗

<p>SELECT * 在含TEXT/JSON等长文本字段的表中会强制加载整行数据，导致IO和内存压力剧增，应显式指定所需字段以避免性能灾难。</p>为什么 SELECT * 在长文本字段上特别伤性能数据库读取行时，哪怕你只用其中一两个字段，只要表里有 TEXT 或 JSON 这类大字段，InnoDB 就得把整行（包括大字段）从磁盘或 buffer pool 里加载出来。尤其当这些字段平均几十 KB、又没被索引覆盖时，IO 和内存压力会指数级上升。常见错误现象：EXPLAIN 显示 type=ALL 或 Extra=Using where，但实际执行慢得离谱；监控看到 Innodb_buffer_pool_reads 暴涨；应用日志里反复出现超时却查不到明显锁等待。别在业务查询里写 SELECT *，尤其是表含 content、description、payload 等命名的大字段即使用了覆盖索引，如果索引没包含所有 SELECT 字段，MySQL 仍要回表------而回表会拉出整行，大字段照读不误TEXT 字段默认不参与索引，WHERE 条件里对它做 LIKE '%xxx%' 会强制全表扫描，顺便把所有大字段都拖一遍用 SELECT 显式指定字段替代 * 的实操要点这不是"建议"，而是上线前必须卡住的红线。重点不是少写几个字，是让优化器能精确估算成本，并绕开大字段的物理读取。使用场景：分页列表、后台导出、API 接口响应组装------只要不需要展示全文内容，就该砍掉大字段。接口返回用户列表？只要 id、name、status，就明确写这三列，绝不要带 bio 或 resume导出报表需统计数量？用 SELECT COUNT(*) FROM t WHERE ...，别写 SELECT COUNT(id) 加大字段------COUNT(*) 走索引更快，且不触发回表真需要预览长文本？用 SUBSTRING(content, 1, 200) 或 LEFT(content, 200)，避免传输和解析完整内容TEXT 字段建索引的坑：不是不能建，而是不能乱建TEXT 类型本身不支持全文索引以外的普通 B+Tree 索引，但很多人误以为加个 INDEX(content) 就能加速 WHERE content LIKE 'xxx%' ------ 实际会报错或静默降级为前缀索引，效果极差。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能