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，已经晚了。 
