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 统计，并配合业务节奏更新统计信息，才能让索引真正发挥价值。
评论(0)