mysql索引监控需结合information_schema、performance_schema和explain分析，核心是确认查询是否真正高效使用索引；通过show indexes或statistics查基数，analyze table刷新统计；explain看type、key、key_len、rows判断索引使用效果；performance_schema.table_io_waits_summary_by_index_usage追踪实际访问频次；长期观察count_read=0的非约束索引识别冗余索引，删除前需验证业务影响。
MySQL 提供了多种方式来监控索引的使用情况，核心是结合 information_schema、performance_schema 和执行计划分析，而非依赖单一指标。关键不在于“索引是否被创建”，而在于“查询时是否真正走索引”以及“索引是否高效”。
查看索引元信息与基数估算
通过 SHOW INDEXES FROM table_name 或查询 information_schema.STATISTICS，可获取索引名称、列顺序、基数（CARDINALITY）等基础信息。基数反映索引列中不同值的大致数量，数值越接近表行数，说明该列选择性越高，索引越可能被优化器选用。但注意：该值由采样估算得出，并非实时精确值，且 InnoDB 不会自动更新，需手动执行 ANALYZE TABLE 来刷新。
识别实际是否走索引（执行计划分析）
对重点 SQL 使用 EXPLAIN 或 EXPLAIN FORMAT=JSON 查看执行计划。重点关注以下字段：
-
type：值为
const、ref、range、index表示走了索引；ALL表示全表扫描，需警惕 -
key：显示实际使用的索引名；为
NULL即未用索引 - key_len：反映索引使用了多少字节，可判断是否用了联合索引的最左前缀
- rows：优化器预估扫描行数，越小越好；若远大于实际结果集，可能索引失效或统计信息不准
追踪索引访问频次（MySQL 5.6+ performance_schema）
启用 performance_schema 后，可通过以下表观察索引级别的运行时访问统计：
-
performance_schema.table_io_waits_summary_by_index_usage：记录每个索引的读写等待次数（COUNT_READ是关键指标），直接反映该索引被查询命中的频率 - 需确保相关 consumers 和 instruments 已开启，例如：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_waits_current';UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'wait/io/table/%'; - 注意：该统计是累积值，重启后清零；适合中长期趋势观察，不适合秒级诊断
发现未使用但存在的索引（冗余/无效索引）
长期运行后，可结合以下方法识别“从不被用到”的索引：
- 查
performance_schema.table_io_waits_summary_by_index_usage中COUNT_READ = 0且非主键/唯一约束索引 - 排除明显只用于写入约束（如 UNIQUE）的索引
- 结合慢查询日志 +
pt-index-usage（Percona Toolkit 工具）可更精准分析 SQL 文本中哪些索引从未被 WHERE/JOIN/ORDER BY 引用 - 删除前务必确认：该索引是否服务于低频但关键的报表、归档或备份逻辑？避免误删
索引监控不是一次性任务，而是持续观察、验证、清理的过程。把 EXPLAIN 当成日常习惯，定期检查 performance_schema 统计，并配合业务节奏更新统计信息，才能让索引真正发挥价值。
