MySQL索引命中率是衡量查询是否有效利用索引的重要指标。高命中率说明大部分索引查找都成功匹配了数据，低命中率则可能意味着存在全表扫描或索引设计不合理。通过分析命中率，可以优化查询性能和索引结构。
查看索引命中相关状态变量
MySQL提供了多个status variables来帮助评估索引使用情况，主要关注以下两个值：
Index_reads：从存储引擎中读取索引块的次数（无法在内存中找到所需索引页时发生） Index_read_requests：应用程序请求读取索引块的总次数这两个变量可通过如下命令查看：
SHOW STATUS LIKE 'Handler_read%';其中关键字段包括：
Handler_read_key：基于索引读取行的请求数（对应 Index_read_requests） Handler_read_next：按顺序读取下一行，常用于范围扫描 Handler_read_first：读取索引中第一条记录，常见于 ORDER BY 或 MIN() Handler_read_rnd：基于固定位置读取行，通常表示使用了文件排序或临时表 Handler_read_rnd_next：执行全表扫描的请求数，越高说明全表扫描越频繁计算索引命中率公式
索引命中率可近似通过以下公式计算：
索引命中率 = (Handler_read_key) / (Handler_read_key + Handler_read_rnd_next) * 100%注意：虽然 Handler_read_rnd_next 主要反映全表扫描行为，但该公式为一种估算方式，并非官方定义。理想情况下，该值应接近 100%，若低于 90%，需检查是否存在缺失索引或低效查询。
结合慢查询日志定位问题SQL
仅看全局命中率不够，还需定位具体未命中索引的语句。启用慢查询日志并配合EXPLAIN分析是关键步骤：
确保开启慢查询日志：SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1; 对可疑SQL执行 EXPLAIN，观察是否出现： type=ALL：表示全表扫描 key=NULL：未使用索引 Extra 中包含 Using filesort 或 Using temporary：可能存在性能瓶颈
优化建议与注意事项
提高索引命中率的核心在于合理设计索引和优化SQL写法：
为 WHERE、JOIN、ORDER BY 和 GROUP BY 字段建立合适索引 避免在索引列上使用函数或表达式，如 WHERE YEAR(create_time) = 2023 使用复合索引时注意最左前缀原则 定期审查冗余或未使用的索引，可通过 information_schema.statistics 和 performance_schema 配合分析 考虑使用 pt-index-usage 工具分析实际索引使用情况基本上就这些。索引命中率只是一个参考指标，更重要的是结合具体业务场景和执行计划进行综合判断。持续监控和调优才能保障数据库高效运行。
