MySQL schema_index_statistics 怎样找出读取延迟最高的索引

排查 MySQL 查询变慢时，光看表结构只能知道“有哪些索引”，却不知道哪个索引真的承受了大量读取等待。比较实用的做法是先看 sys.schema_index_statistics，按 select_latency 和 rows_selected 排序，再回到具体 SQL 和执行计划确认原因。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/sys-schema-index-statistics.html

先记住一个判断：读取延迟高，说明累计等待成本高；读取行数高，说明通过这个索引读出的行多。两者都只是 Performance Schema 汇总出来的观察指标，不能单独作为删除索引或改表结构的结论。

这个视图解决了什么问题

MySQL 的 sys schema 是对 Performance Schema 数据的易读封装，适合做调优和诊断。schema_index_statistics 专门把索引级别的访问统计整理出来，默认按索引总延迟降序排列。它回答的是“哪些索引在已采集的工作负载中更忙”，而不是“哪些索引一定设计错误”。

视图里最重要的识别字段是 table_schema、table_name 和 index_name；读取侧看 rows_selected、select_latency，写入侧看 rows_inserted、insert_latency、rows_updated、update_latency、rows_deleted 和 delete_latency。

先按读取延迟找出高开销索引

第一轮不要急着做优化，先把读取延迟最高的索引列出来。下面的查询把库名、表名、索引名、读取行数和读取延迟放在一起，便于后续回到具体业务表。

-- 按累计读取延迟排序，先找出最值得排查的索引
SELECT
    table_schema,
    table_name,
    index_name,
    rows_selected,
    select_latency,
    rows_inserted,
    rows_updated,
    rows_deleted
FROM sys.schema_index_statistics
WHERE table_schema NOT IN ('mysql', 'sys', 'performance_schema', 'information_schema')
ORDER BY select_latency DESC
LIMIT 20;

select_latency 是已计时读取的累计等待时间，排序靠前表示累计成本更高。它不等于某一次查询的平均耗时，也不能直接说明索引本身“慢”。高延迟可能来自访问次数很多、每次扫描行数很多，或者底层存储和并发等待较重。

再按 rows_selected 区分高频访问和大范围扫描

只看总延迟容易把“访问次数很多”和“单次读得很重”混在一起。第二轮按 rows_selected 排序，再把两个结果对照起来：

-- 按索引累计读出的行数排序，观察扫描量较大的访问路径
SELECT
    table_schema,
    table_name,
    index_name,
    rows_selected,
    select_latency,
    ROUND(select_latency / NULLIF(rows_selected, 0), 2) AS latency_per_row
FROM sys.schema_index_statistics
WHERE table_schema NOT IN ('mysql', 'sys', 'performance_schema', 'information_schema')
ORDER BY rows_selected DESC
LIMIT 20;

这里的 latency_per_row 只是一个粗略观察值：它把累计延迟除以累计读取行数，适合帮助排序，不应被当作精确的单行耗时。常见的三种情况如下：

别忘了写入延迟：读得快不代表代价小

有些索引读取表现不错，却给写入带来明显维护成本。插入、更新和删除都会维护相关索引，因此要把写入字段也拉出来看：

-- 找出写入维护成本较高的索引，避免只盯着读取侧
SELECT
    table_schema,
    table_name,
    index_name,
    rows_inserted,
    insert_latency,
    rows_updated,
    update_latency,
    rows_deleted,
    delete_latency
FROM sys.schema_index_statistics
WHERE table_schema NOT IN ('mysql', 'sys', 'performance_schema', 'information_schema')
ORDER BY (insert_latency + update_latency + delete_latency) DESC
LIMIT 20;

这个排序仍然是累计量。它适合发现“写入路径上维护成本高”的候选项，但不能据此直接删除索引，因为索引可能承担关键查询、唯一性约束或外键相关职责。

统计结果为什么可能和直觉不一致

第一，视图展示的是已采集工作负载的累计统计。刚启动实例、刚清空 Performance Schema，或者业务流量没有覆盖某条 SQL 时，排名都可能和生产高峰不同。

第二，schema_index_statistics 说明的是索引访问统计，不会替你解释某条语句为什么选择了这条索引。对排名靠前的项，还要回到语句摘要、慢查询记录和 EXPLAIN，确认它对应哪类查询。

第三，如果当前账号读不到 sys 视图，先处理权限和监控采集配置。不要为了让查询返回数据而把权限扩大到不必要的范围，也不要把空结果解释为“索引没有被使用”。

一套比较稳的排查顺序

1. 先按 select_latency 排名前 20，记录库、表和索引名。
2. 对同一批数据按 rows_selected 再排一次，区分总等待和扫描量。
3. 查看写入延迟，识别可能增加写放大的索引。
4. 把候选索引映射回具体 SQL，再用执行计划确认过滤、排序和连接条件。
5. 在业务低峰或可控窗口做变更，保留变更前后的统计观察，避免仅凭一次排名下结论。

我在实际排查里最容易犯的错，是看到一个索引排名靠前就直接认为它应该被删除。更可靠的做法是把它当作入口：它告诉你哪里值得看，最终是否改索引仍要由查询收益、写入代价和业务约束共同决定。

常见问题

select_latency 是单次查询耗时吗？

不是。它是已计时读取的累计等待时间，适合做相对排序，不等价于某一次请求的平均或 P99 延迟。

rows_selected 越大，索引就越差吗？

不一定。高读取行数可能只是业务访问量大，也可能提示过滤不够精确。需要结合具体 SQL 和返回行数判断。

为什么查不到某个刚创建的索引？

可能是新索引还没有被工作负载使用，也可能是统计采集或权限配置不完整。空结果不能直接证明索引不可用。

看到高写入延迟后能马上删索引吗？

不能。先确认该索引是否支撑关键读取、唯一性约束或其他业务约束，再通过可回滚的变更流程处理。

总结一下：select_latency 适合发现累计读取等待高的索引，rows_selected 适合发现累计扫描量高的索引，写入延迟则提醒你关注维护成本。三组指标一起看，再回到 SQL 和执行计划，才是比较稳的 MySQL 索引诊断路径。