MySQL 8.0的索引监控（如sys.schema_unused_indexes和performance_schema.table_io_waits_summary_by_index_usage）本质是结构化人工分析，提升覆盖性与一致性而非单次精度；其COUNT_STAR统计索引被选为访问路径的执行次数（非扫描行数），结果反映采集周期内是否被用，需结合业务场景判断“该不该存在”。
MySQL 8.0 的 Schema 级别索引监控（主要指 sys.schema_unused_indexes 和 performance_schema.table_io_waits_summary_by_index_usage）本身并不“更准确”，它只是把原本分散、易遗漏的手动分析过程结构化、自动化了。真正提升的是可覆盖性与一致性，而不是单次判断的数学精度。
为什么手动比对 EXPLAIN + SHOW INDEX 容易漏判？
人工验证索引是否被用、是否覆盖，依赖你「想到要查哪条 SQL」+「记得去查」+「能还原真实执行路径」：
- EXPLAIN 只反映单条语句的计划，而线上可能有几十个不同参数组合的查询变体；
- SHOW INDEX FROM t 只告诉你索引长什么样，不告诉你它在最近一周有没有被任何语句选中过；
- 如果查询带 JSON_CONTAINS()、隐式类型转换（比如 WHERE id = '123' 对 INT 字段），优化器可能弃用索引，但你若没恰好 EXPLAIN 这条，就完全不知道；
- 多租户或微服务场景下，SQL 来自不同应用模块，没人能穷举所有 WHERE 组合。
sys.schema_unused_indexes 是怎么筛出“真闲置”索引的？
这个视图不是靠猜，而是基于 performance_schema 的实际访问记录和统计信息交叉验证：
- 它排除掉那些「理论上可用但从未被选中」的索引（COUNT_STAR = 0）；
- 同时过滤掉主键、外键约束依赖的索引（避免误删）；
- 还会跳过 INFORMATION_SCHEMA 中标记为 UNIQUE 且被唯一性检查强制使用的索引；
- 关键点：sys.schema_unused_indexes 的结果是「过去采集周期内未被任何查询选作访问路径的索引」，不是「永远没用过」——所以必须配合采样窗口（如最近 24 小时慢日志 + performance_schema 开启状态）看；
- 示例查询：
SELECT * FROM sys.schema_unused_indexes WHERE object_schema = 'mydb';
为什么 table_io_waits_summary_by_index_usage 的 COUNT_STAR 不等于扫描行数？
这是最容易误解的地方：
- COUNT_STAR 表示「该索引被某条 SQL 语句选为访问路径的执行次数」，不是「扫了多少行」；
- 一次 SELECT * FROM t WHERE a=1 AND b>10 执行，哪怕扫描 5000 行，COUNT_STAR 也只 +1；
- 如果同一条 SQL 被缓存并复用执行计划，每次执行仍会计 +1；
- 重启 MySQL 后该计数清零，且无法持久化（PERSIST 不支持）；
- 它不区分等值查找（=）和范围扫描（BETWEEN），也不反映回表开销 —— 所以不能单靠它判断“效率高低”，只能回答“是否被用过”。
真正难的不是查出哪个索引没被用，而是判断「它该不该存在」：一个索引可能当前没被用，但下游报表任务每周跑一次；也可能被用于 ORDER BY 排序而非 WHERE 过滤，而 table_io_waits_summary_by_index_usage 依然会计数。这些上下文，监控数据不会自动告诉你。
