大字段拖慢查询的主因是“不该读的也读了”，应通过字段裁剪、索引覆盖和物理拆表优化：只查必要列、建联合索引实现覆盖、将大字段移至扩展表。
大字段（如 TEXT、BLOB、长 VARCHAR）拖慢查询，核心原因不是“数据大”，而是“不该读的也读了”——尤其在 SELECT * 或未显式排除大字段时，MySQL 会把整行（含大字段）从磁盘加载到内存，即使你最终只用其中几个小字段。
字段裁剪：只查真正需要的列
这是最直接有效的优化。避免 SELECT *，明确列出业务所需的字段，把大字段从查询中剔除。
- 例如：用户列表页只需
id、name、status、created_at，就绝不要带content（TEXT）或avatar（BLOB） - 如果某些场景确实需要大字段（如详情页），单独写一条针对性 SQL，和列表页 SQL 物理隔离
- ORM 中注意检查生成的 SQL，有些框架默认查全部字段，需手动指定
select()或fields
索引隔离：让二级索引覆盖查询，避开聚簇索引回表
InnoDB 的聚簇索引把主键和所有字段存在一起。一旦查询涉及非主键字段，又没走覆盖索引，就会先查二级索引定位主键，再回聚簇索引捞整行——此时大字段也被一并读出。
- 确保高频查询条件字段上有合适索引（比如
WHERE status = ?，就在status建索引） - 若查询只涉及少量字段（如
SELECT id, name, updated_at FROM users WHERE status = 1），可建联合索引INDEX idx_status_id_name_updated (status, id, name, updated_at)，实现“索引覆盖”，完全不访问主表数据页 - 注意：大字段不能作为索引列（MySQL 不允许对 TEXT/BLOB 做前缀以外的索引），但可以放在联合索引末尾——只要前面的列能完成过滤+排序，后续列仅用于覆盖，不影响效率
物理拆表：把大字段移到独立扩展表
当业务上大字段使用频次明显低于主信息时，可将大字段剥离到关联表，主表保持轻量。
- 例如：原
articles表含title、content、summary；拆为articles（id, title, author_id, created_at…） +article_contents（article_id, content, summary） - 列表页只查
articles，详情页再JOIN或单独查article_contents - 拆表后主表体积大幅下降，缓存命中率提升，排序分页、全表扫描都更快
其他实用细节
一些容易被忽略但见效快的操作：
- 关闭查询缓存（Query Cache）：MySQL 5.7+ 已默认禁用，但老版本开启时，大字段会让缓存块巨大且极易失效，得不偿失
- 确认
innodb_log_file_size和innodb_buffer_pool_size配置合理，避免因大字段频繁刷脏页或 Buffer Pool 拥堵 - 用
EXPLAIN看执行计划，重点观察type（是否用到索引）、key（用了哪个索引）、Extra（是否出现Using filesort/Using temporary/Using where; Using index）
