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的关键计数器做快照，计算差值以观察趋势，同时紧密结合业务发布的变更日志。只有这样，才能准确判断一个索引是“真的没用”，还是“时候未到”。
相关攻略
MySQL 8 0 索引跳跃扫描：一个被误解的“优化捷径” 提到MySQL 8 0的索引跳跃扫描（Index Skip Scan），很多人的第一反应是：“终于可以不用管联合索引最左前缀原则了！” 但事实果真如此吗？先泼一盆冷水：它并非一个可以随意开关的“万能钥匙”，而是优化器在特定场景下才会动用的“
RC降低死锁概率的根本原因是默认不使用间隙锁，仅对命中行加记录锁，锁范围更小、冲突更少；而RR对范围条件自动加Next-Key锁，易引发循环等待死锁。 RC 隔离级别为什么能降低死锁概率 说到底，RC级别降低死锁概率的核心秘诀，就在于它“不轻易动用”间隙锁（Gap Lock）——除了检查唯一键或外键
MySQL索引使用率：一个被过度简化的伪命题 在数据库优化的讨论中，“索引使用率”常常被当作一个关键指标。但这里有个根本性的认知偏差：MySQL本身并不提供，也计算不出一个精确的“索引使用率”百分比。 市面上有些工具或文章，试图用sys库视图的数据做除法，得出诸如“某索引使用率95%”的结论，这种做
MySQL 5 7 到 8 0 升级：字符集与排序规则的“暗礁”与避坑指南 先明确一个核心事实：从 MySQL 5 7 升级到 8 0，字符集和排序规则的默认设置发生了根本性改变。这绝非一个简单的版本号变化，而是一个可能直接导致数据乱码、查询异常甚至业务逻辑错误的“硬切换”。 MySQL 5 7 和
慢查询日志：从开启到分析，避开那些“开了等于没开”的坑 想优化数据库性能，慢查询日志是绕不开的起点。但这里有个常见的误区：你以为开启了全局日志就万事大吉？如果关键的阈值没设对，很可能跑上一天也抓不到一条有效记录。而在分析工具的选择上，pt-query-digest凭借其SQL归一化、细粒度指标分析和
热门专题
热门推荐
WF-1000XM4蓝牙配对指南：两种触发路径，一个核心逻辑 给索尼WF-1000XM4配对，核心其实就一件事：让耳机进入“被发现”的状态。有意思的是，它并不依赖某个单一的物理按键，而是提供了双路径的触发方式。根据官方的操作指南以及多次的实际测试，无论是通过充电盒上的功能键，还是直接操作耳机本身，都
迅捷路由器桥接失败怎么办？原因分析与解决方法大全 许多用户在使用迅捷路由器进行无线桥接时，经常遇到“显示已连接但无法访问互联网”的问题。实际上，这通常并非设备故障，而是由于关键的网络参数配置不当或主副路由器之间的通信协调不畅所致。简单来说，就是两台路由器之间的设置没有完全匹配。那么，具体哪些环节最容
迅捷路由器无线桥接：手机端设置实操指南 使用手机为迅捷路由器配置无线桥接（WDS），听似专业，实则通过官方适配的移动端界面就能轻松完成。只要满足几个关键条件，您仅需一部手机即可高效架设扩展网络。操作时，请先将手机连接至副路由器的默认无线信号（通常以FAST_XXXX格式命名），随后在Safari或C
小米空调联网故障全解析：从新手排查到专家级修复，步步为营 当小米空调始终无法成功连接网络时，许多用户的第一反应往往是联系售后或怀疑设备故障。然而实际情况是，超过九成的联网失败案例，根源都出在网络配置、操作流程这类“软性”环节，空调硬件本身出问题的概率极低。解决问题的核心在于掌握系统化的排查思路，按照
有线音响加装蓝牙功能并不复杂，普通用户借助外置蓝牙接收器即可在十分钟内完成升级 想给家里的老款有线音响“剪掉”那根烦人的音频线？其实这件事没你想的那么复杂。普通用户完全不需要动用电烙铁，借助一个小巧的外置蓝牙接收器，十分钟之内就能搞定升级。核心操作很简单：确认你的音箱背面有标准的3 5毫米或RCA音