MySQL索引监控实战：如何精准判断索引是否有效工作？
为数据库表创建索引，如同为团队配备高效工具。但工具引入后，是持续发挥作用，还是闲置成为负担？这不能仅凭直觉判断，而需要确凿的数据支撑。要准确评估索引是否被实际使用，必须采用一套组合策略：从运行时性能统计、SQL执行计划分析、存储引擎行为监控到慢查询日志审查，多维度交叉验证，才能洞察真实情况。
核查索引实际使用率：聚焦 performance_schema.table_io_waits_summary_by_index_usage
要掌握索引的“实时使用效能”，最权威的数据源是MySQL内置的performance_schema（5.6及以上版本默认启用）。它能精确记录每个索引在运行期间被读取、更新、删除的操作次数。切勿陷入“创建即生效”的误区，实践中，大量索引自部署之日起，其COUNT_FETCH计数始终为零。
- 若
COUNT_FETCH = 0，则该索引极有可能是从未被查询命中的“无效索引”。需特别警惕联合索引中存在前缀重复的情况，例如同时拥有INDEX(a)和INDEX(a,b)，后者往往能完全替代前者的功能，导致前者冗余。 - 查询时务必排除系统库干扰：添加条件
WHERE OBJECT_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema')，避免大量系统表统计信息影响分析结果。 - 需注意，该表统计的是自MySQL服务启动或计数器重置以来的累计数据，反映的是历史总量而非实时速率。若要长期追踪使用趋势，建议定期采集快照，通过计算差值进行对比分析。
判断索引是否有效工作需综合四大方法：一查performance_schema.table_io_waits_summary_by_index_usage中的COUNT_FETCH是否为零；二用EXPLAIN分析type、key_len、Extra等执行计划关键指标；三监控SHOW STATUS中的Handler_read_*系列状态变量；四启用log_queries_not_using_indexes记录未使用索引的慢查询。
分析单条SQL索引使用情况：深度解读 EXPLAIN 执行计划
EXPLAIN并非简单的查看工具，它是开发者与MySQL查询优化器沟通的核心桥梁。仅观察key字段是否非空远远不够，关键在于综合解读以下关键信号：
type字段显示为ALL或index？这通常是性能警报，表明查询可能在进行全表扫描或全索引扫描，效率低下。key_len数值是否小于预期？这可能意味着查询仅使用了联合索引的前缀列，后续列因查询条件或排序方式未能生效。例如，索引为(a,b,c)，但查询条件仅有WHERE a=1，则key_len通常不会反映索引的全部长度。Extra列是否出现Using filesort或Using temporary？即使查询使用了索引，若排序（ORDER BY）或分组（GROUP BY）操作无法利用索引，MySQL仍可能创建临时表或进行文件排序，此时需结合具体字段进一步排查。
全局评估索引工作强度：监控 Handler_read_* 状态变量
如果说EXPLAIN是对单条SQL进行体检，那么Handler_read_*系列状态变量就是对数据库存储引擎进行长期健康监测。通过执行SHOW STATUS LIKE 'Handler_read%'可查看这些变量，它们揭示了存储引擎层的真实I/O行为，比应用层日志更为底层和可靠：
Handler_read_key数值较高：这是积极信号，说明索引频繁用于定位数据行，索引设计有效。Handler_read_rnd_next数值持续快速增长：这是一个明确的警告，意味着存在大量随机行读取，通常等同于“正在进行全表扫描”。此时应立即检查相关SQL是否缺失索引，或查询条件未满足索引的“最左前缀原则”。Handler_read_first高但Handler_read_key低？这可能是一种“虚假的索引使用”。例如，执行SELECT * FROM table（无WHERE条件）进行全索引扫描，虽然触发了索引，但对提升查询性能并无实际益处。
善用慢查询日志作为“索引失效警报器”
开启log_queries_not_using_indexes = ON配置，相当于设置了一道安全防线。所有未使用索引且执行缓慢的查询都将被记录到慢查询日志中。许多业务SQL在测试环境小数据量下表现良好，一旦上线，随着数据量增长和数据分布变化，可能退化为全表扫描，此配置能帮助您第一时间发现此类问题。
- 请同时合理设置
long_query_time阈值（例如设为1秒甚至0.5秒），避免放过那些虽略有延迟但未走索引的查询。 - 分析慢查询日志时，避免手动翻阅，推荐使用
pt-query-digest等工具进行聚合分析，并按Rows_examined（扫描行数）降序排序，排在前列的通常是索引缺失或失效的重灾区。 - 请注意：该参数主要对独立的
SELECT语句生效，对于INSERT ... SELECT或子查询中的SELECT，可能不会被记录，需要额外验证。
归根结底，真正的挑战往往不在于发现哪个索引未被使用，而在于诊断“它为何未被使用”。是查询条件的写法不当？是数据严重倾斜导致优化器放弃使用索引？还是索引设计本身违反了最左匹配原则？要解答这些问题，必须结合EXPLAIN执行计划、表中的实际数据分布以及业务查询的语义，进行综合研判。仅执行几个检查命令，无法窥见事情的全貌。
