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 结果。
