为什么TIDB_INDEX_USAGE中主键索引的PERCENTAGE_ACCESS_100 会很高

🪐 TiDB 技术问题
1

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】测试环境
【TiDB 版本】
【部署方式】云主机
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】7
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】

按照文档的说明，PERCENTAGE_ACCESS_100 指行访问比例为 100% 的次数，我理解等同于index full scan的次数。

主键这种索引走的是点查，过滤性是最高的，按理说不应该出现访问100%的数据行吧。

image
image1692×237 78.3 KB

是我理解有问题还是文档有问题？ :joy:

SQL：

SELECT
    TABLE_SCHEMA,TABLE_NAME,INDEX_NAME,
    SUM(QUERY_TOTAL),
    SUM(PERCENTAGE_ACCESS_0_1),
    SUM(PERCENTAGE_ACCESS_1_10),
    SUM(PERCENTAGE_ACCESS_10_20),
    SUM(PERCENTAGE_ACCESS_20_50),
    SUM(PERCENTAGE_ACCESS_50_100),
    SUM(PERCENTAGE_ACCESS_100)
FROM
    INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE
GROUP BY
    TABLE_SCHEMA,TABLE_NAME,INDEX_NAME
HAVING
    SUM(QUERY_TOTAL) > 100
    AND SUM(PERCENTAGE_ACCESS_50_100 + PERCENTAGE_ACCESS_100) / SUM(QUERY_TOTAL) > 0.3
ORDER BY
    SUM(QUERY_TOTAL);

【资源配置】
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

2

得结合你的业务SQL来分析，方便贴上来看看吗

3

可能要找一找，比如从什么角度来分析

4

先拿 AI 分析下 :rofl:

5

这个百分比算的是「这次扫了多少行 ÷ 表总行数」，不是索引自己的选择性，所以只要一条语句把主键扫了一整张表，就会记进 PRIMARY 的 100%。还有个前提，聚簇表的主键是 v8.4.0 才开始进 TIDB_INDEX_USAGE 的，之前根本不统计主键，你要是新版本才看到主键有数，正常。

主键出现 100% 基本就两个来路。一个是全表扫描，聚簇索引表的行数据本身就是按主键摆的，select * from t、没有别的索引能用的查询、count(*)、覆盖整表的范围扫描，走的都是主键，扫整表记 100% 很正常。另一个是主键上做了几乎覆盖全表的大范围扫描，像 order by 主键把整表拉出来这种。

想确认到底是哪种，把 ROWS_ACCESS_TOTAL 除以 QUERY_TOTAL（平均每次扫多少行）跟 PERCENTAGE_ACCESS_0_1（点查次数）放一起看，再拿 statement summary 或者 slow query 里同表走主键的语句对一下就有结论了。所以我倾向不是文档写错，是主键顺带把全表扫描也记上了，真正该盯的是那些本该点查、结果在主键上大范围扫的语句。

1 个赞
6

但是你的版本是 v8.5 的版本，合理来说应该是没问题的

7

感觉AI解不了这题，对大模型来说信息太少了 :joy:

8

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。