SELECT * 在含TEXT/JSON等长文本字段的表中会强制加载整行数据，导致IO和内存压力剧增，应显式指定所需字段以避免性能灾难。

为什么 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%' —— 实际会报错或静默降级为前缀索引，效果极差。

参数差异：innodb_large_prefix 开启后，单列索引前缀最大可到 3072 字节（默认 767），但这是指前缀长度，不是全文索引。

• 想按开头匹配？建前缀索引：ALTER TABLE t ADD INDEX idx_content_prefix (content(100))，但只能用于 WHERE content LIKE 'abc%'，%abc 无效
• 想全文检索？必须用 FULLTEXT 索引 + MATCH() AGAINST()，注意 MyISAM 和 InnoDB 的分词行为不同，中文需配合 ngram 插件
• 别给 TEXT 字段设 DEFAULT 值或 NOT NULL 约束——多数 MySQL 版本不支持，会报错 ERROR 1167: The used storage engine can't index column 'xxx'

大字段分离到独立表的判断标准

不是所有长文本都要拆，但一旦满足任一条件，就该考虑垂直拆分：UPDATE 频率远低于 SELECT、大字段更新导致 row size too large 报错、主表 QPS 高且字段访问呈现强冷热分离。

性能影响：拆表后主表变窄，buffer pool 利用率提升，JOIN 成本可控；但多一次关联查询，网络和解析开销略增——权衡点在于“大字段是否经常和主键一起被读”。

• 拆分后主表留 id、title、created_at 等高频字段；大字段单独建 t_content 表，用 post_id 关联
• 外键约束慎用：高并发写入下，INSERT INTO t_content 可能成为瓶颈，异步写入或延迟关联更稳
• 迁移时别直接 ALTER TABLE DROP COLUMN content，先加新表、双写、校验、切流量，否则 ALTER 过程中 DML 会被阻塞数分钟甚至更久

事情说清了就结束。最常被忽略的是：开发阶段查数据习惯性 SELECT *，测试环境看不出问题，一上生产，buffer pool 里全是大字段的脏页，缓存命中率断崖下跌——这时候再改 SQL，已经晚了。