答案是通过EXPLAIN分析执行计划，检查索引使用情况，优化WHERE条件写法，避免索引失效，结合慢查询日志定位问题SQL，并根据查询模式合理设计索引。
当 MySQL 查询性能下降，很可能是索引未命中导致的。要分析这类问题，核心是理解查询执行计划、检查索引设计是否合理，并结合实际数据访问模式进行优化。
使用 EXPLAIN 分析查询执行计划
在 SELECT 语句前加上 EXPLAIN 或 EXPLAIN FORMAT=JSON，可以查看 MySQL 如何执行这条查询。
重点关注以下字段：
- type：表示连接类型。常见值有 ALL（全表扫描）、index（全索引扫描）、ref 或 range（使用索引）。若为 ALL，基本说明索引未命中。
- key：实际使用的索引。如果为 NULL，表示没有使用索引。
- possible_keys：可能用到的索引。如果这里有索引但 key 为 NULL，说明优化器没选它，需进一步分析。
- rows：估算需要扫描的行数。数值越大，效率越低，可能和索引缺失有关。
- Extra：额外信息。出现 Using where; Using filesort 或 Using temporary 通常意味着性能隐患。
检查 WHERE 条件是否有效利用索引
即使建了索引，WHERE 子句写法不当也会导致索引失效。
- 避免在索引列上使用函数或表达式，如 WHERE YEAR(create_time) = 2023，应改为 WHERE create_time >= '2023-01-01' AND create_time 。
- 避免对索引列做隐式类型转换，比如字符串字段传入数字会导致全表扫描。
- 使用 LIKE 时，前导通配符（如 LIKE '%abc'）无法使用索引，应尽量使用后缀匹配（LIKE 'abc%'）。
- 复合索引注意最左前缀原则。例如索引 (a, b, c)，查询条件必须包含 a 才可能命中，只查 b 或 c 不会走索引。
查看慢查询日志定位高频低效 SQL
开启慢查询日志可以帮助发现长期存在的性能问题。
- 在配置文件中启用：
slow_query_log = ON
long_query_time = 1
slow_query_log_file = /var/log/mysql/slow.log - 使用 mysqldumpslow 或 pt-query-digest 分析日志，找出执行时间长、扫描行数多的 SQL。
- 结合 EXPLAIN 检查这些慢 SQL 是否走了索引。
验证索引是否存在或设计是否合理
有时问题出在缺少必要的索引，或者索引顺序不合理。
- 使用 SHOW INDEX FROM 表名 查看当前索引结构。
- 根据高频查询的 WHERE、ORDER BY、GROUP BY 字段判断是否需要创建新索引。
- 对于经常一起出现的查询条件，考虑建立联合索引，减少多个单列索引带来的维护开销。
- 注意索引选择性：高选择性的字段（如用户 ID）更适合做索引前导列。
基本上就这些。关键是从执行计划入手，结合实际 SQL 写法和索引策略，逐步排查为什么索引没被用上。不复杂但容易忽略细节。
