查索引是否被真正用上需综合四方面：一查performance_schema.table_io_waits_summary_by_index_usage中COUNT_FETCH是否为0；二用EXPLAIN看type、key_len、Extra等执行计划细节；三盯SHOW STATUS中的Handler_read_*变量；四开启log_queries_not_using_indexes捕获未走索引的慢查询。
查索引有没有被真正用上：看 performance_schema.table_io_waits_summary_by_index_usage
MySQL 5.6+ 默认启用 performance_schema，它能告诉你每个索引在运行时被读、写、删了多少次——这才是“实时利用率”的唯一可靠来源。别信“建了就等于用了”，很多索引上线后一次 COUNT_FETCH 都没发生过。
-
COUNT_FETCH = 0的索引，99% 是未被查询命中的“幽灵索引”，尤其要警惕联合索引中前缀重复的（比如同时存在INDEX(a)和INDEX(a,b)） - 注意过滤系统库：
WHERE OBJECT_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema')，否则结果会被干扰 - 该表统计的是自上次重启或清空计数器以来的累计值，不是瞬时速率；如需长期观察，建议定期快照并做差值对比
判断某条 SQL 到底走没走索引：必须用 EXPLAIN 看执行计划
EXPLAIN 不是“看看就行”的玩具，它是你和 MySQL 查询优化器之间最直接的对话窗口。只看 key 字段是否为 NULL 还不够，关键要看组合信号：
-
type是ALL或index？说明大概率在全表/全索引扫描，性能已亮红灯 -
key_len值比预期小？可能只用了联合索引的前几列，后面列失效了（例如索引是(a,b,c)，但查询只用了WHERE a=1，key_len就不会覆盖全部） -
Extra出现Using filesort或Using temporary？即使走了索引，排序/分组仍可能绕开索引，得结合ORDER BY和GROUP BY字段再检查
从全局看索引“干活勤不勤”：盯住 Handler_read_* 状态变量
这些变量藏在 SHOW STATUS LIKE 'Handler_read%' 里，反映的是存储引擎层的真实读取行为，比应用层日志更底层、更诚实：
-
Handler_read_key高 → 索引被频繁定位使用，说明有效 -
Handler_read_rnd_next持续飙升 → 大量随机行读取，基本等于在说“我正在全表扫”，得立刻查对应 SQL 是否漏了索引或条件没打中索引最左前缀 -
Handler_read_first高但Handler_read_key低？可能是SELECT *扫全索引，却没带WHERE条件，这种“伪索引使用”对性能无益
别漏掉慢查询日志这个“索引使用报警器”
开启 log_queries_not_using_indexes = ON 后，每一条没走索引的慢查询都会进日志——这不是锦上添花，而是兜底手段。很多业务 SQL 在测试环境看似 OK，一到线上因数据分布变化就退化成全表扫描，靠这个配置才能第一时间捕获。
- 记得同时设
long_query_time = 1（甚至 0.5），否则轻微延迟的未走索引查询会被放过 - 日志分析别手翻，用
pt-query-digest聚类后按Rows_examined排序，排在前面的往往就是索引缺失重灾区 - 注意：该参数对
SELECT生效，但对INSERT ... SELECT或子查询中的SELECT可能不记录，需额外验证
真正难的不是查出哪个索引没用，而是判断“它为什么没被用”——是查询条件写法问题？数据倾斜导致优化器放弃？还是索引本身设计违背了最左匹配？这些得结合 EXPLAIN、实际数据分布、以及业务语义一起看，光刷几个 SQL 是看不出真相的。
