应优先通过 performance_schema.table_io_waits_summary_by_index_usage 查看 COUNT_READ 值确认索引是否被真实使用，再结合 EXPLAIN、INFORMATION_SCHEMA.STATISTICS 和 slow_query_log 分析索引有效性与查询效率。
如何用 SHOW INDEX 和 INFORMATION_SCHEMA.STATISTICS 快速确认索引是否被读取
MySQL 本身不直接暴露“索引读取延迟”这个指标，所谓“索引读取慢”，本质是查询执行时没能高效命中索引，或命中后回表/排序开销大。第一步不是看延迟，而是确认索引有没有被真正用上。
常见错误现象：EXPLAIN 显示 type=ALL 或 key=NULL，但表明明建了索引；或者 rows 值远大于实际匹配行数，说明索引选择性差或统计信息过期。
- 用
SHOW INDEX FROM table_name检查索引字段顺序、是否唯一、基数（Cardinality）是否合理——基数接近 0 或远小于表行数，大概率没生效 - 查
INFORMATION_SCHEMA.STATISTICS更灵活，比如：SELECT TABLE_NAME, INDEX_NAME, SEQ_IN_INDEX, COLUMN_NAME, CARDINALITY FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 't1';
- 更新统计信息别只靠
ANALYZE TABLE，在大表上它可能跳过采样；可加STATS_SAMPLE_PAGES=200提高精度（5.7+ 支持）
用 performance_schema.table_io_waits_summary_by_index_usage 看索引真实使用频次
这是最接近“索引读取活跃度”的原生指标，但它不提供延迟，只记录每个索引的 COUNT_READ 和 COUNT_WRITE。值为 0 表示该索引从未被查询使用过，比 EXPLAIN 更反映线上真实行为。
使用场景：清理冗余索引、验证新索引上线后是否真被用到、排查“为什么加了索引还是慢”。注意它默认关闭，且只统计开启后的新查询。
- 启用前确保：
performance_schema开启，且table_io_waits_summary_by_index_usage的消费者已打开：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_waits_current';
- 查询语句：
SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_READ FROM performance_schema.table_io_waits_summary_by_index_usage WHERE INDEX_NAME IS NOT NULL ORDER BY COUNT_READ DESC LIMIT 10;
- 兼容性影响：5.6+ 支持，但 5.6 默认不收集索引级等待；8.0 中更稳定，不过仍不记录延迟毫秒值
延迟感知必须靠 slow_query_log + pt-query-digest 定位具体 SQL
真正能体现“索引读取延迟”的，是某条 SQL 因索引效率低导致执行时间长。MySQL 不单独输出“索引延迟”，但 slow_query_log 里的 Rows_examined 和实际返回行数比值，就是索引筛选效率的代理指标。
容易踩的坑：只设 long_query_time=1，漏掉大量 Rows_examined 高但执行快的低效查询；或没开启 log_queries_not_using_indexes，导致全表扫描不进慢日志。
- 关键配置项：
slow_query_log = ON<br>long_query_time = 0.1<br>log_queries_not_using_indexes = ON<br>log_throttle_queries_not_using_indexes = 10
- 分析时重点看：
Rows_examined / Rows_sent比值 > 100？说明索引过滤能力弱；Rows_examined接近表总行数？基本等于没走索引 - 用
pt-query-digest聚合后，按Rows_examined排序，比单纯看执行时间更能揪出“伪快实慢”的索引误用查询
不要依赖 Handler_read_* 状态变量判断索引延迟
Handler_read_key、Handler_read_next 这类状态变量常被误读为“索引读取次数”，其实它们反映的是存储引擎层的底层操作次数，和 SQL 层索引是否高效无关。值高不一定代表索引好，也可能是因为索引设计差导致反复跳转。
性能影响明显：这些变量每秒刷新几十次，频繁 SHOW STATUS LIKE 'Handler%' 会增加 Performance Schema 开销，尤其在高并发写入时。
-
Handler_read_key高 ≠ 索引高效：它只是“尝试通过索引定位第一条记录”的次数，哪怕后续要扫 10 万行，也只算 1 次 -
Handler_read_next高才值得警惕——说明在索引有序扫描中做了大量连续读，往往对应范围查询未截断、或ORDER BY强制全索引扫描 - 替代方案：优先用
performance_schema.events_statements_summary_by_digest查SORT_MERGE_PASSES和ROWS_AFFECTED，更贴近 SQL 实际行为
索引延迟不是独立指标，它是查询执行计划、数据分布、统计信息、硬件 I/O 共同作用的结果。最容易被忽略的是：即使 EXPLAIN 显示用了索引，如果 key_len 远小于预期长度，或者 Extra 出现 Using filesort / Using temporary，那所谓的“索引读取”早就不是瓶颈所在了。
