索引是否被有效使用需综合判断执行计划、慢查询日志、系统视图统计和负载验证：查EXPLAIN确认key/扫描行数，分析slow_log中Rows_examined/Rows_sent比值，用performance_schema或pg_stat_all_indexes看索引读次数，再通过压测验证不同参数下索引稳定性。
索引是否被有效使用，不能只看“建了没”，关键要看执行时“用没用上”。命中率不是数据库自动计算的指标，需结合执行计划、运行统计和业务查询特征综合判断。
看执行计划确认索引是否真实生效
每次重点SQL上线或调优前，必须用 EXPLAIN（MySQL）或 EXPLAIN ANALYZE（PostgreSQL）查看实际执行路径：
- 关注 key 字段（MySQL）或 Index Scan 类型（PG），确认是否命中预期索引
- 检查 rows 或 Actual Rows 是否明显低于全表扫描预估量，过大的扫描行数说明索引选择性差或未生效
- 警惕 Using index condition（ICP）或 Index Only Scan，这类说明走了覆盖索引，效率更高
- 若出现 Using filesort 或 Using temporary，即使走了索引，也可能因排序/分组缺失合适索引而退化
查慢查询日志反推低效索引使用
慢查询日志是索引问题最真实的“报警器”：
- 开启 slow_query_log 并设置合理阈值（如 long_query_time = 1），定期归集分析
- 用工具（如 pt-query-digest）聚合后，重点关注 Rows_examined / Rows_sent 比值远大于 1 的语句——说明扫描大量数据才返回少量结果，索引可能未过滤到位
- 对高频慢查语句，提取 WHERE、ORDER BY、GROUP BY 字段组合，比对现有索引是否满足最左匹配且覆盖筛选条件
用系统视图统计索引访问频次与效率
数据库自带统计视图可反映索引“冷热”程度：
- MySQL：查询 information_schema.STATISTICS 获取索引定义；结合 performance_schema.table_io_waits_summary_by_index_usage 查看各索引的 COUNT_READ（读次数），为 0 的索引高度可疑
- PostgreSQL：查 pg_stat_all_indexes 中的 idx_scan（索引扫描次数）和 idx_tup_read（通过索引读取的元组数），对比 pg_stat_all_tables 的 seq_scan，若某表 seq_scan 高但 idx_scan 为 0，说明索引基本闲置
- 注意：统计值重启后清零，需在稳定业务周期（如 1–7 天）内采集才有参考价值
模拟真实负载做命中率抽样验证
静态分析易漏掉动态场景，建议在准生产环境做轻量级压测验证：
- 选取核心业务接口的典型 SQL，用相同参数构造 50–100 次请求，捕获其执行计划与实际耗时
- 统计其中走索引的比例、平均扫描行数、P95 响应时间，与全表扫描基准对比（如加 IGNORE INDEX 强制走全表）
- 特别关注参数变化影响：同一SQL，不同 IN 列表长度、时间范围跨度下是否始终命中索引？避免“看似可用，实则脆弱”
索引监控不是一次性动作，而是嵌入开发、发布、巡检的常态化环节。真正有效的命中率，来自执行计划里的 key 字段、慢日志里的 rows_examined、系统视图中的 idx_scan 计数，以及你对业务查询模式的理解。不复杂但容易忽略。
