真正关键的四列是type、key、rows、extra：type反映访问类型优先级，key显示是否用索引，rows预估扫描行数，extra揭示临时表或文件排序等性能隐患。
怎么看 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 里有没有那行记录。很多人调优卡在第一步，就是没把这两列盯准。
