需先确认performance_schema及索引统计消费者是否启用，再结合count_fetch与写入量比值、explain结果、sys.schema_unused_indexes视图及pt-index-usage日志综合判断索引是否滥用。
查 performance_schema.table_io_waits_summary_by_index_usage 前先确认开关开了没
这个表不是默认全开的——哪怕 MySQL 5.7+，performance_schema 启用了，相关消费者（consumer）也可能被关着，导致表里全是 0 或空数据。
执行这两条命令确认：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema'; SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'events%index%' AND ENABLED = 'YES';
如果第二条没返回，说明索引使用统计没开，得手动开：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_history_long';UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_waits_history_long';
改完不用重启，但需要等一段时间（比如 15–30 分钟以上）让真实查询打点积累数据，否则 COUNT_FETCH 全是 0 就没参考价值。
怎么从 table_io_waits_summary_by_index_usage 里揪出“滥用”索引
滥用不等于“没用”，而是“写得多、读得少”，或者“读得极少但占着空间和 buffer pool”。关键看三组数字的比值：
-
COUNT_FETCH接近 0，但COUNT_INSERT/COUNT_UPDATE很高 → 索引纯拖累写入，几乎不加速查询 -
COUNT_FETCH极低（比如日均 - 同一张表多个索引的
COUNT_FETCH总和远低于主键索引（PRIMARY）的十分之一 → 说明大部分查询还是靠主键或全表扫，辅助索引利用率极差
别直接删，先加个时间过滤再筛：
SELECT OBJECT_SCHEMA AS db, OBJECT_NAME AS tbl, INDEX_NAME AS idx,
COUNT_FETCH, COUNT_INSERT, COUNT_UPDATE, COUNT_DELETE
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE OBJECT_SCHEMA NOT IN ('mysql','information_schema','performance_schema')
AND COUNT_FETCH = 0
AND (COUNT_INSERT + COUNT_UPDATE + COUNT_DELETE) > 1000
ORDER BY COUNT_INSERT + COUNT_UPDATE + COUNT_DELETE DESC;
EXPLAIN 显示走了索引，但 COUNT_FETCH 为 0？这不矛盾
因为 EXPLAIN 是预估执行计划，COUNT_FETCH 是运行时真实调用次数。常见错位场景：
- 查询带了
LIMIT 1且命中首行，实际只触发了一次索引查找，但performance_schema统计粒度是“等待事件”，可能被聚合或采样漏掉 - 查询走的是覆盖索引（
Extra: Using index），底层用的是二级索引 B+ 树的叶子节点，不触发常规的 “index read” 等待事件，所以COUNT_FETCH不涨 - 查询被 query cache 缓存了（MySQL 8.0 已移除，但 5.7 还有），后续响应不经过索引扫描路径
这时更该信 EXPLAIN 的 rows 和 type：如果 rows 动辄几万、type 是 index 或 ALL，哪怕 key 不为空，也是假走索引。
MySQL 8.0+ 可直接用 sys.schema_unused_indexes 快速筛查
这是封装好的视图，底层就是查 performance_schema + 表结构 + 查询历史，省去手写过滤逻辑：
SELECT * FROM sys.schema_unused_indexes
WHERE object_schema NOT IN ('mysql','sys');
但它有个硬限制：只报告“过去 30 天内完全没被任何查询使用的索引”。如果你刚上线新索引，或业务有月度批处理周期，它会误报。建议把它当初步筛选器，而不是删除依据。
真正决定删之前，还得做两件事：一是用 pt-index-usage 跑一周慢日志，确认没有隐性依赖；二是把疑似索引名加到监控告警里，观察删除前后 Innodb_buffer_pool_read_requests 和 Handler_read_next 的波动——有些索引删了之后，buffer pool 压力反而上升，说明它悄悄承担了部分缓存作用。
