mysql如何查看索引的使用率_通过sys库分析冗余索引

MySQL索引使用率：一个被过度简化的伪命题

在数据库优化的讨论中，“索引使用率”常常被当作一个关键指标。但这里有个根本性的认知偏差：MySQL本身并不提供，也计算不出一个精确的“索引使用率”百分比。 市面上有些工具或文章，试图用sys库视图的数据做除法，得出诸如“某索引使用率95%”的结论，这种做法其实相当危险——它很可能误导你删掉真正有价值的索引，而留下那些“看起来活跃”的负担。

为什么这么说？因为sys库本质上只是一个数据包装器，它聚合了performance_schema和information_schema的信息，并未引入任何魔法公式。索引的价值，绝非一个简单的百分比所能衡量。

sys.schema_unused_indexes：它只告诉你“完全没用过”的

这个视图常被误认为是“低使用率索引”的名单，其实它的筛选条件非常绝对：只找出那些自MySQL实例启动以来，一次都没有被SELECT语句读取过（COUNT_FETCH = 0）的索引。它的底层逻辑大致如下：

SELECT object_schema, object_name, index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL
  AND count_fetch = 0
  AND object_schema NOT IN ('mysql', 'information_schema', 'performance_schema');

看明白了吗？它捕捉的是“幽灵索引”。但问题随之而来：一个每周只为凌晨跑批任务服务一次的索引，COUNT_FETCH可能只是1，它就不会出现在这个列表里，但这能算“高使用率”吗？显然不能。

• 它忽略业务节奏：一个每年只在年终决算时用一次的报表索引，其业务重要性可能远超一个每天被更新很多次、却很少被查询的索引。
• 它无视写入开销：有些索引存在的意义在于保障数据唯一性（如唯一约束），COUNT_FETCH可能很低，但每次写入都要维护它。sys.schema_unused_indexes对此只字不提。
• 它受制于统计周期：MySQL重启后，所有计数归零。一个新上线的索引，在业务流量切过来之前，立刻就会出现在这个“无用”列表里，此时参考它做决策，无异于刻舟求剑。

sys.schema_redundant_indexes：关注结构重复，而非使用效率

这个视图的作用是识别定义上的冗余，例如：

• 已经有INDEX(a, b)，又建了INDEX(a)，后者会被标记为冗余。
• 已经有UNIQUE(a)，再建INDEX(a)，普通索引就显得多余。

但是，它完全不关心这两个索引在实际业务中谁更“忙”、谁的性能更好。 这就埋下了几个典型的陷阱：

• 业务代码中明确使用了FORCE INDEX(a)来强制使用某个短索引，但sys.schema_redundant_indexes依然会建议你删除它——你能删吗？当然不能。
• 联合索引INDEX(a,b,c)和INDEX(a,b)被标记为冗余。但如果绝大部分查询条件只用到a和b列，那么更短的INDEX(a,b)在内存中占用更小，缓存效率更高，反而可能是更优选择。
• 这个视图不会告诉你，使用INDEX(a,b)比INDEX(a,b,c)能让Handler_read_next减少多少。这类真实的性能差异，只能通过压力测试或分析慢查询日志来发现。

核心思路转变：从“使用率”到“性价比”

说到底，评估一个索引，关键不是看它被用了多少次，而是权衡它的“读收益”是否远远大于其带来的“写代价”。我们应该关注以下几组更有意义的对比：

• 对比同一张表的索引读写比：查询performance_schema.table_io_waits_summary_by_index_usage。如果一个索引COUNT_FETCH很高，但COUNT_INSERT/UPDATE/DELETE极低，那它是安全的“好同志”。反之，如果COUNT_FETCH接近零，而COUNT_INSERT却持续增长，那它就是首要的清理目标——光吃饭不干活。
• 关注全局访问模式：执行SHOW GLOBAL STATUS LIKE 'Handler_read%'。如果Handler_read_rnd_next（全表扫描读数）的值远高于Handler_read_key（通过索引查找读数），说明大量查询根本没用到索引。这时，盲目删索引不如先去优化SQL语句。
• 结合慢日志深度分析：慢查询日志中的Rows_examined（检查行数）是照妖镜。有时EXPLAIN显示走了索引，但实际执行却扫描了50万行才返回3条结果。这通常意味着索引的列顺序不对，或选择性太差。这种索引比“完全没用”的索引更危险，因为它制造了一种“我在工作”的假象。

所以，别再执着于那个虚幻的“使用率”百分比了。MySQL世界里没有一键优化的银弹。真正靠谱的做法是：定期（比如每周或每月）为performance_schema的关键计数器做快照，计算差值以观察趋势，同时紧密结合业务发布的变更日志。只有这样，才能准确判断一个索引是“真的没用”，还是“时候未到”。