如何利用MySQL sys库排查系统中哪些索引是从来没有被使用过的废弃索引

sys.schema_unused_indexes视图仅反映performance_schema中已采集查询未使用的索引，需确认events_statements_history_long已启用且采集满24小时，再结合table_io_waits_summary_by_index_usage的COUNT_FETCH/COUNT_READ为0及EXPLAIN验证真废弃。

直接查 sys.schema_unused_indexes 但必须先确认数据可信

这个视图不是“建了没用就报”，而是“在 performance_schema 已采集的查询里一次都没被选中”。刚重启 MySQL 或采集时间太短，COUNT_FETCH 全是 0，结果全是假阴性。

实操前务必检查：

• SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'events_statements_%' AND ENABLED = 'NO' —— 如果 events_statements_history_long 被关了，sys.schema_unused_indexes 就没数据来源
• SELECT COUNT(*) FROM performance_schema.events_statements_history_long —— 非零才说明语句采集已生效
• 业务高峰期持续采集至少 24 小时，尤其要覆盖定时任务、报表 SQL 等低频但关键查询

别只看 sys.schema_unused_indexes 输出，要交叉验证 COUNT_FETCH

该视图只告诉你“未被使用”，但不区分是真闲置还是压根没进采样窗口。更硬的依据是底层统计表：

SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_FETCH, COUNT_READ FROM performance_schema.table_io_waits_summary_by_index_usage WHERE OBJECT_SCHEMA = 'your_db' AND INDEX_NAME = 'idx_xxx'

重点看 COUNT_FETCH 和 COUNT_READ 是否都为 0。如果其中任一非零，说明索引确实被用过；如果都是 0，再结合 EXPLAIN 和慢日志判断是否漏采。

联合索引里“部分列没用上”不会被 sys.schema_unused_indexes 标记

比如有 INDEX(a, b, c)，但业务查询只有 WHERE a = ? AND c = ?，优化器仍可能选中该索引（key 字段显示索引名），但实际只用到 a，c 列因跳过 b 完全失效。

这时要靠 EXPLAIN 看细节：

• key_len 明显小于理论最大值 → 只用了前缀列
• Extra 出现 Using where 但没有 Using index → 没走覆盖扫描，大概率回表且部分列未参与过滤
• 对 ORDER BY 场景，即使 WHERE 没用全列，只要排序能覆盖，索引仍可能被选中，不能单凭 key 字段存在就认为有效

删之前必须人工核验三类隐性依赖

自动脚本输出的“可删列表”只是起点。真正危险的是那些不显山不露水的依赖：

• SELECT COUNT(*) FROM t WHERE ... 类聚合查询常走索引快速计数，但不会在 table_io_waits_summary_by_index_usage 中高频出现
• CARDINALITY 极低的索引（如 status 列只有 3 个值）即使 COUNT_FETCH = 0 也本就不该存在，删它不解决问题，得重构设计
• ORM 框架隐式调用：Django 的 .exists()、Laravel 的 doesntExist() 生成 SELECT 1 FROM t WHERE ...，这类语句轻量但关键，容易被忽略

索引是否真废弃，不取决于它有没有出现在执行计划里，而取决于删掉后会不会让某条 SQL 从 ref 退化成 ALL —— 这个判断没法全自动，得人盯住慢日志和核心路径的 EXPLAIN 结果。