怎么看 EXPLAIN
输出里真正关键的几列
MySQL 优化不是看
EXPLAIN能不能跑出结果，而是盯住
type、
key、
rows、
Extra这四列。它们直接暴露查询是否走索引、扫描了多少行、有没有临时表或文件排序。
常见错误是只扫一眼
type是不是
ref或
range就放心，其实
rows高到几万，说明索引没选对或者条件过滤性差；
Extra出现
Using filesort或
Using temporary基本等于性能红灯。
type优先级：
const≈
eq_ref>
ref>
range>
index>
ALL（全表扫描）
key为空？说明没用上索引，哪怕表上有索引，也可能因隐式类型转换、函数包裹字段（如
WHERE YEAR(created_at) = 2023）导致失效
rows不是精确值，是预估，但数量级错得离谱（比如查 10 行却显示 10000）往往意味着统计信息过期，可运行
ANALYZE TABLE
Extra中
Using index是好信号（覆盖索引），但
Using index condition才是 MySQL 5.6+ 的真正优化点，表示下推了部分 WHERE 条件到存储引擎层
联合索引顺序为什么不能随便调换
联合索引
(a, b, c)不等于
(b, a, c)，更不等于三个单列索引之和。MySQL 的 B+ 树索引按定义顺序排序，只能高效支持“最左前缀匹配”。
典型误用场景：给
WHERE b = ? AND c = ?建了
(a, b, c)索引，结果还是全表扫描——因为没用上最左列
a，整个索引就废了。 等值查询 + 范围查询混用时，范围列之后的字段无法走索引：
WHERE a = 1 AND b > 10 AND c = 5只能用上
a和
b，
c不会参与索引查找 排序需求要和索引顺序严格一致：
ORDER BY a, b能用
(a, b)，但
ORDER BY b, a就不行 区分度高的列建议放左边，但别为了“高区分度”牺牲查询模式：比如经常查
status = 'paid'再加时间范围，
status区分度低，但放左边反而能让更多查询命中索引
FORCE INDEX
什么时候该用、什么时候是掩耳盗铃
强制指定索引不是银弹，它只是绕过优化器的“自作聪明”，但掩盖不了底层设计问题。用之前先确认：是不是统计信息不准？是不是写法触发了优化器误判？
真实报错场景：
SELECT ... FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 20，明明有
(user_id, created_at)索引，却走了全表扫描 + filesort——可能是因为
user_id值分布极不均匀（比如大量测试数据全是同一个 ID），让优化器误以为走索引不如扫表快。 临时救急可用：
SELECT ... FROM t FORCE INDEX (idx_user_time) WHERE ...，但必须配上监控，确认执行计划稳定且
rows合理 长期依赖
FORCE INDEX通常说明表结构或查询逻辑有问题：比如缺少合适的联合索引，或
WHERE条件里用了无法走索引的表达式 MySQL 8.0+ 支持优化器提示（hints），比
FORCE INDEX更细粒度，例如
/*+ USE_INDEX(t idx_user_time) */，但同样不能替代索引设计
为什么加了索引查询反而变慢
索引不是越多越好，也不是建了就一定生效。最常被忽略的是：索引本身要占磁盘、内存，写操作（INSERT/UPDATE/DELETE）都要维护索引树，而读性能提升的前提是“查询真能走索引且收益大于开销”。
一个典型反例：给
gender列（只有 'M'/'F'）单独建索引，查询
WHERE gender = 'M'时，MySQL 认为走索引要随机 IO 查几千页，不如直接扫表——于是弃用索引，你还以为建了就有用。 单列低区分度字段（如状态码、开关位）单独建索引，大概率被优化器忽略 大字段（如
TEXT、长
VARCHAR）做索引前缀长度不够，会导致索引失效或重复率过高 频繁更新的字段建索引，会显著拖慢写入性能，尤其在高并发写场景下，B+ 树分裂和缓冲池压力都会放大 复合索引中包含太多列（比如 5 列以上），不仅增大索引体积，还容易因查询条件未覆盖最左前缀而完全失效
索引好不好，得看
EXPLAIN里的
key和
rows，而不是看
SHOW INDEX里有没有那行记录。很多人调优卡在第一步，就是没把这两列盯准。
