关键看EXPLAIN的type和key列：type为const/ref/range/index且key非空才有效走索引；ALL表示全表扫描，key为空即未走索引，常见因隐式转换、函数操作或联合索引使用不当导致。
怎么看 EXPLAIN 输出里有没有走索引
关键看 type 和 key 两列。type 是 const、ref、range 或 index 才算有效利用索引；如果是 ALL，基本等于全表扫描。key 列显示实际用到的索引名，为空就说明没走索引——哪怕你建了索引，也可能因条件不匹配或隐式转换被跳过。
常见错误现象：key 为空但 possible_keys 有值；type=ALL 却以为“有索引就行”；Extra 出现 Using filesort 或 Using temporary 却没意识到这是性能雷区。
- WHERE 条件里对字段做函数操作（如
WHERE YEAR(create_time) = 2023）会让索引失效 - 字符串字段用数字比较（
WHERE status = 1而status是VARCHAR）触发隐式类型转换 - 联合索引中，跳过左边字段直接查右边（
INDEX(a,b,c)，只查b = ?）无法命中
EXPLAIN FORMAT=TREE 比传统格式多看出什么
MySQL 8.0+ 的树形输出能直观看到执行顺序、是否物化子查询、是否使用缓存结果，尤其适合嵌套查询和 UNION 场景。它把 Extra 里的关键信息（比如 Using index condition）融合进节点描述，避免误读。
使用场景：当你发现传统 EXPLAIN 显示走了索引，但查询还是慢，大概率是 ICP（Index Condition Pushdown） 没生效，或者存在回表放大。树形格式里能看到 “-> Filtered: 10.00%” 这类提示，说明存储引擎层过滤率极低，大量数据被拉到 Server 层再筛。
- 看到节点带
materialized，说明子查询被物化成临时表，注意磁盘/内存开销 - 出现
attached subquery且执行代价高，优先考虑改写为 JOIN -
cost值不是绝对耗时，但同一条语句不同写法间可横向对比
哪些字段值得加索引——别只盯 WHERE
索引价值不仅在过滤，还在排序、分组、覆盖查询。如果 SELECT 字段全在某个索引里（包括 WHERE + ORDER BY + SELECT 列），就能走 Using index（索引覆盖），避免回表。
性能影响很直接：一个 SELECT a,b FROM t WHERE c=? ORDER BY d，比起单独给 c 加索引，建联合索引 INDEX(c,d,a,b) 可能快几倍——前提是 d 是升序需求，且 a,b 不大。
-
ORDER BY字段必须和WHERE字段一起考虑顺序，INDEX(a,b)支持WHERE a=? ORDER BY b，但不支持WHERE b=? ORDER BY a -
GROUP BY同理，且 MySQL 5.7+ 对松散索引扫描（Loose Index Scan）有严格前缀要求 - 大字段（如
TEXT）不能直接建索引，需要指定前缀长度，但前缀太短会导致区分度下降
为什么 count(*) 有时比 count(id) 快
因为 count(*) 在有主键的 InnoDB 表上，优化器可能直接走最小的二级索引（甚至主键 B+ 树叶子节点数），而 count(id) 强制检查每行 id 是否非 NULL，可能触发全索引扫描或回表。
但这不是绝对的——如果表有多个非空唯一索引，count(*) 未必选最优的那个；如果用了 WHERE，两者行为又趋同。真正影响性能的是扫描范围和是否能利用索引覆盖。
- 确认是否走索引：用
EXPLAIN看key和rows，别凭经验猜 - 统计需求频繁时，考虑冗余计数表或缓存，而不是反复扫大表
- MyISAM 的
count(*)是 O(1)，InnoDB 永远是 O(N) 或 O(索引大小)，这点容易被忽略
事情说清了就结束。索引不是越多越好，而是要让 EXPLAIN 里的 key 列真正亮起来，并且 rows 尽量接近你预期过滤后的数量。
