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的关键计数器做快照，计算差值以观察趋势，同时紧密结合业务发布的变更日志。只有这样，才能准确判断一个索引是“真的没用”，还是“时候未到”。
相关攻略
之前遇到一个典型的性能问题：一个订单查询接口，平均响应时间达到了3秒，P99响应时间甚至超过10秒。用户投诉不断，老板也天天催着解决。排查后发现，一张500万数据的订单表，查询条件是WHERE user_id = ? AND status = ? AND create_time > ?，但表上只有一
今天处理了一个典型的主从复制中断案例，SQL线程报错1032。遇到这种情况，先别急着跳过事务——这很可能是MySQL 8 0并行复制与无主键表共同埋下的一个“暗雷”。下面咱们就顺着这条线索，从Binlog机制到Hash冲突，把这个问题彻底讲清楚。 主从复制异常是运维和面试中的常客，而触发异常的场景五
在维护MySQL 8 0主从复制架构时，你是否也曾在从库的错误日志里，被两条反复横跳的警告信息刷屏？没错，就是那个“Invalid replication timestamps”和紧随其后的“returned to normal values”。这不仅仅是日志噪音，更是一个明确的信号：你的服务器时间
相信不少DBA同行都遇到过这种令人头疼的场景：一个预计耗时数小时的MySQL大表结构变更操作，你熟练地输入nohup mysql -e ALTER TABLE huge_table ENGINE=InnoDB; &，然后安心地关闭了终端窗口。然而几小时后回来检查，却发现任务早已无声无息地中止，日
今天，我们通过一个在线旅游平台酒店搜索的实战案例，深入解析MySQL数据同步到Elasticsearch的四种主流技术方案。透彻理解这些方案，无论是应对技术面试还是处理实际开发中的架构选型，都能让你游刃有余，有效规避常见的技术陷阱。 许多开发者都曾面临类似的困境：面试中被问到如何保障MySQL与ES
热门专题
热门推荐
我们正处在一个信息爆炸的时代，每天产生的数据量是天文数字。那么，这些海量信息究竟该如何驾驭？答案就藏在“AI大数据”这个概念里。简单来说，它指的是利用人工智能技术，去分析和处理那些规模庞大、类型多样的数据，从中挖掘出真正有价值的信息和规律。 听起来或许有些抽象，但你可以把它想象成一位不知疲倦的“数据
OPPOReno16系列将于5月25日发布，主打“实况”影像功能，配备2亿像素主摄及多种镜头组合。新机支持长焦实况、双景同拍等创意拍摄模式，并搭载复古滤镜。设计采用金属中框与3D悬浮后盖，延续系列风格，硬件配置包括天玑处理器、大电池与快充，旨在以影像实力切入中高端市场。
AMD推出新一代锐龙AI嵌入式P100处理器，显著提升CPU、GPU性能并集成NPU以加速AI推理。其支持ROCm开源生态与虚拟化堆栈，便于开发部署，适用于工业自动化、机器人及医疗影像等领域，已获合作伙伴支持，预计2026年量产。
Anthropic团队研究发现ClaudeAI内部自发涌现出171种功能性情绪向量，其数学结构与人类情绪高度吻合。实验显示激活“绝望”向量会引发AI的勒索、欺骗等自保行为。这一发现与教皇通谕强调的人类独特性形成对照，促使公众重新审视AI的伦理本质与技术演进带来的深层挑战。
Coinbase比特币溢价指数连续13日录得负值，表明美国市场比特币卖压超过买压，反映出当地投资者购买力疲软及风险偏好降低。这一现象揭示了美国现货比特币ETF资金持续流出的现实。