最简路径是查sys.schema_unused_indexes，但它仅反映performance_schema采集窗口内未被优化器选中的索引，并非绝对闲置；需确保events_statements_history_long等消费者已启用、采集满24小时且覆盖低频关键查询，再结合table_io_waits_summary_by_index_usage中COUNT_FETCH与COUNT_READ均为0判断，同时排除外键、索引提示、隐性聚合查询等依赖，推荐先设为INVISIBLE观察。

直接查 sys.schema_unused_indexes 是最简路径，但结果默认不可信——它只反映 performance_schema 采集窗口内未被选中的索引，不是“建了没用就报”，而是“在已采集的查询里一次都没被优化器挑中”。刚重启、采集时间不足、消费者未开，查出来全是空，删了就出事。

确认 performance_schema 数据是否可信

这个视图的数据源头是 performance_schema.table_io_waits_summary_by_index_usage，但它默认不收集，必须手动激活：

• 检查关键消费者是否启用：SELECT * FROM performance_schema.setup_consumers WHERE NAME IN ('events_statements_history_long', 'events_waits_current') AND ENABLED = 'NO'；如果返回结果，说明语句和等待事件没采集，sys.schema_unused_indexes 就是空壳
• 验证采集是否生效：SELECT COUNT(*) FROM performance_schema.events_statements_history_long；非零才代表有真实语句进来了
• 业务高峰期持续运行至少 24 小时，尤其要覆盖定时任务、报表 SQL 等低频但关键查询——否则 COUNT_FETCH = 0 只是漏采，不是真闲置

别只看 sys.schema_unused_indexes，盯紧底层 COUNT_FETCH 和 COUNT_READ

sys.schema_unused_indexes 是个快捷入口，但容易误导。真正硬指标在底层表：

• 执行：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 = 0 AND COUNT_READ = 0 是必要条件；任一非零，说明索引确实被用过（哪怕只是排序扫描或回表读）
• 注意：ORDER BY 单独走索引（如 ORDER BY created_at LIMIT 10）可能不触发 COUNT_READ，但会记入 COUNT_FETCH；如果两者都为 0，再结合 EXPLAIN 和慢日志交叉判断

联合索引部分列失效不会被标记，得靠 EXPLAIN 看 key_len 和 used_key_parts

比如有 INDEX(a, b, c)，但查询是 WHERE a = ? AND c = ?，优化器仍可能选中该索引，sys.schema_unused_indexes 不会报它“未使用”——但它实际只用了 a，b 被跳过，c 无法参与过滤。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 用 EXPLAIN FORMAT=JSON 查 used_key_parts 字段，看实际命中了哪几列
• 对比 key_len 和理论最大值：比如 a 是 INT（4 字节），b 是 VARCHAR(50)（utf8mb4 下最多 200 字节），理论上 key_len 最大为 204，若实际只有 4，说明只用了第一列
• Extra: Using where 且没有 Using index → 没走覆盖扫描，大概率回表，部分列未生效

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

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

• 外键约束：SELECT CONSTRAINT_NAME, COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'tbl_name' AND REFERENCED_TABLE_NAME IS NOT NULL；有结果就不能删
• 应用层硬编码索引提示：grep -r "FORCE INDEX\|USE INDEX" ./src/ 或查代理层 SQL 日志；哪怕查询本身不依赖，MySQL 也会强制走
• 聚合查询快速计数：SELECT COUNT(*) FROM t WHERE status = 'done' 常走索引完成，但 table_io_waits_summary_by_index_usage 中 COUNT_FETCH 可能很低甚至为 0——这类索引不能单凭统计值判断

真正难的不是查出哪些索引“看起来没用”，而是确认它在所有执行路径下都不被依赖——包括你没见过的凌晨批处理、DBA 手动跑的诊断 SQL、甚至某个被遗忘的监控脚本。隐形索引（ALTER INDEX idx_name INVISIBLE）比直接删更安全，先切掉观察一周，比赌一把强。