MySQL 8.0.1+才支持sys.schema_unused_indexes视图，依赖performance_schema.table_io_waits_summary_by_index_usage统计，5.7及更早版本不存在该视图；其结果仅为“近期未用”，需人工核验业务逻辑与外键依赖，不可直接执行drop_statement。
MySQL 8.0+ 才有 sys.schema_unused_indexes，低版本直接查不了
这个视图是 sys 库里的一个只读视图，底层依赖 performance_schema 的索引统计（table_io_waits_summary_by_index_usage），而该表从 MySQL 8.0.1 开始才支持记录「索引未被使用」的场景。MySQL 5.7 及更早版本压根没有这个视图，执行 SELECT * FROM sys.schema_unused_indexes; 会报错 Table 'sys.schema_unused_indexes' doesn't exist。
如果你在 5.7 或 MariaDB 上看到有人提这个视图，基本是记混了或者环境实际是 8.0+。
- 确认版本：
SELECT VERSION(); - 确认
performance_schema已启用且相关消费者已打开：SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE '%statements%' OR NAME LIKE '%waits%';，其中events_waits_summary_by_index_usage必须为ENABLED - 视图本身不实时刷新——它只反映自上次
FLUSH TABLES或服务器重启后、performance_schema收集到的统计周期内的状态
sys.schema_unused_indexes 返回的是“近期未用”，不是“永远没用”
它列出的索引只是在当前 performance_schema 统计窗口内（通常是自启动或上次清空以来）没有被任何语句通过索引查找（index_lookup）访问过。但以下情况会导致误判：
- 索引只用于排序或覆盖扫描（
Using index），但没触发index_lookup——这类使用不会被计入「已使用」，可能被误标为 unused - 查询走的是联合索引的最左前缀，但视图把整个联合索引都列为 unused（因为非前缀字段没单独被查过）
- 应用刚上线、流量还没打进来，或 DBA 刚启用了
performance_schema，统计期太短 - 某些 DDL 操作（如
ANALYZE TABLE）会触发隐式索引访问，但不走常规查询路径，也不会被统计
所以它更适合做「初筛」，而不是直接删索引的依据。
查出来的结果里 schema_name 和 index_name 要人工核对业务逻辑
视图返回的字段包括 object_schema、object_name、index_name、type（PRIMARY/UNIQUE/BASE）、drop_statement（建议删除语句）。但别急着复制 drop_statement 就跑：
-
drop_statement不检查外键依赖——如果该索引被外键引用，直接执行会报错Cannot drop index 'xxx': needed in a foreign key constraint - 有些索引虽未被 SELECT 使用，但被
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO依赖来判断冲突，删了会出错 - 全文索引（
FULLTEXT）和空间索引（SPATIAL）在视图中可能显示为 unused，但它们的使用模式不走普通 wait 统计，不能信 - 务必结合
SHOW CREATE TABLE `table_name`;看索引定义，再翻代码或慢日志确认有没有隐式使用场景
替代方案：手动查 performance_schema 原表更可控
如果想绕过 sys 视图的封装、看原始统计，可以直接查底层表：
SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE COUNT_READ = 0
AND INDEX_NAME IS NOT NULL
AND OBJECT_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');注意点：
-
COUNT_READ = 0表示没发生过索引查找，比视图更原始；但它不区分「真没用」和「统计被重置过」 - 必须排除系统库，否则会看到一堆
innodb内部索引（比如INNODB_SYS_TABLES的主键） - 这个表的数据是累积的，但重启 MySQL 后会清零——所以线上长期运行的实例，结果更有参考性；刚重启不久的实例，几乎全是 0
- 如果你开了
userstat（已废弃）或用了旧版监控工具，可能干扰判断，优先以table_io_waits_summary_by_index_usage为准
真正要动手删索引前，得在低峰期先 SET SESSION optimizer_switch='use_index_extensions=off'; 测试下关键 SQL 执行计划有没有崩，再决定动不动手。
