mysql如何监控索引命中率_通过性能视图分析未使用的冗余索引-mysql教程-PHP中文网

需先启用performance_schema的索引统计功能，再查table_io_waits_summary_by_index_usage视图的COUNT_READ和SUM_TIMER_WAIT等字段判断索引是否被有效命中。

mysql如何监控索引命中率_通过性能视图分析未使用的冗余索引

如何用 `performance_schema` 查索引是否被命中

MySQL 5.6+ 默认开启 performance_schema，但默认不收集索引级别的统计——必须手动启用对应消费者和仪器。不打开就看不到任何索引访问记录，这是最常被忽略的前提。

执行以下语句激活关键组件：

UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'statements_digest';
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'wait/io/table/%';
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'statement/sql/select';

注意：wait/io/table/sql/handler 这类底层仪器才真正记录索引读取行为，仅开 statements_digest 不够；TIMED = 'YES' 要设上，否则部分统计字段为 NULL。

之后查 performance_schema.table_io_waits_summary_by_index_usage 视图，重点关注 COUNT_STAR（该索引被使用的总次数）和 COUNT_READ（实际通过该索引做查找的次数）。值为 0 且持续多天，才值得怀疑是否冗余。

识别“伪命中”：为什么 `COUNT_READ > 0` 还可能是无效索引

某些索引看似被用过，实则只是全表扫描时顺带触发了索引遍历（比如 SELECT * FROM t WHERE id > 0 扫聚簇索引），或优化器选了索引但最终走的是 index_merge 中的某一分支，而非单独依赖该索引。

判断依据要叠加多个维度：

检查 table_io_waits_summary_by_index_usage 中 SUM_TIMER_WAIT 是否极低（
结合 sys.schema_unused_indexes（MySQL 8.0+）视图交叉验证，它会过滤掉仅用于约束/主键/外键的索引
用 EXPLAIN FORMAT=TREE 重放可疑 SQL，确认执行计划里是否真实出现 using index 或 using index condition
注意覆盖索引场景：如果一个索引能覆盖查询所有字段，COUNT_READ 可能很高，但它和其他更短的索引功能重叠，仍属冗余

删除前必做的三件事：避免误删主键、唯一约束和隐式依赖

直接 DROP INDEX 可能破坏业务逻辑，尤其当索引承载了约束或被其他工具依赖时。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

务必确认：

查 INFORMATION_SCHEMA.STATISTICS 中 NON_UNIQUE = 0 且 INDEX_NAME != 'PRIMARY' 的索引，它们是唯一索引但非主键，删前得确认应用层没做唯一性校验假设
运行 SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'your_table'，排除 CONSTRAINT_NAME 非空的索引（即由 UNIQUE/FOREIGN KEY 自动创建的）
检查慢查询日志或应用 ORM 日志，确认近期是否有 SQL 显式指定 USE INDEX 或 FORCE INDEX 引用该索引名

哪怕 COUNT_READ = 0，只要出现在 KEY_COLUMN_USAGE 里且 CONSTRAINT_NAME 不为空，就不能删。