直接看EXPLAIN输出判断缺索引：type为ALL/index、key为NULL、Extra含Using filesort/temporary即提示缺失索引；WHERE/ORDER BY/GROUP BY字段组合及顺序决定复合索引设计，建后须用EXPLAIN验证是否生效。
怎么看慢查询日志里哪条 SQL 缺索引
直接看 EXPLAIN 输出，别只盯着执行时间。MySQL 慢查询日志本身不告诉你缺什么索引，它只记录“慢”，真正暴露缺失索引的是执行计划。
实操建议：
- 从慢查询日志中挑出一条典型语句（比如耗时 >1s、
Rows_examined远大于Rows_sent的） - 在测试库上执行
EXPLAIN FORMAT=TRADITIONAL+ 该 SQL，重点看：type是否为ALL或index、key是否为NULL、Extra是否含Using filesort或Using temporary - 注意 WHERE / ORDER BY / GROUP BY 中涉及的字段组合，它们才是索引设计的起点，不是单看 SELECT 列
WHERE 条件字段顺序影响索引是否命中
复合索引不是“包含这些字段就行”，顺序错，索引可能完全失效。
实操建议：
- 如果查询是
WHERE a = ? AND b > ? ORDER BY c，优先建(a, b, c)，而不是(b, a, c)或(c, a, b) -
=条件必须放在最左，>/BETWEEN可接在等值之后，但之后的字段无法用于索引查找（只能用于排序或过滤） - 用
SHOW INDEX FROM table_name确认现有索引字段顺序，别凭印象猜
ORDER BY 和 GROUP BY 触发 filesort 就大概率要加索引
只要 EXPLAIN 的 Extra 出现 Using filesort，说明 MySQL 在内存或磁盘上额外做了排序——这几乎总是性能瓶颈源头之一。
实操建议：
- 如果
ORDER BY a, b，且查询带WHERE a = ?，建(a, b)索引就能消除 filesort - 如果
ORDER BY b DESC, a ASC，MySQL 8.0+ 支持降序索引，可建(b DESC, a ASC)；5.7 及以前一律按升序存，混合方向会退化为 filesort - 避免在
ORDER BY字段上用函数，如ORDER BY UPPER(name)—— 索引失效，且无法优化
建完索引一定要验证执行计划是否真用了
建索引不是“加了就完事”。MySQL 有可能因为统计信息过期、索引选择性差、或者优化器误判而继续走全表扫描。
实操建议：
- 建索引后立刻执行
EXPLAIN，确认key字段已非NULL，且rows显著下降 - 用
ANALYZE TABLE table_name更新统计信息，尤其在大批量写入后 - 留意隐式类型转换：比如字段是
VARCHAR，但查询传了数字WHERE id = 123，会导致索引失效，EXPLAIN中type仍为ALL
索引不是越多越好，联合索引字段数超过 4 个、或单表索引总数超过 5–6 个时，维护成本和优化器决策负担会上升，容易适得其反。
