答案是通过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) = 2025，应改为 WHERE create_time >= '2025-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 写法和索引策略，逐步排查为什么索引没被用上。不复杂但容易忽略细节。