mysql.stats_histograms未走索引

【TiDB 使用环境】生产环境
【TiDB 版本】v6.5.3
【问题复现路径】无
【遇到的问题:问题现象及影响】
监测慢查询发现每次navicat连接数据库的时候特别慢,跟踪语句是截图中的语句,表没有主键,只有唯一索引 UNIQUE KEY tbl (table_id,is_index,hist_id),每次都是全表扫描,表大小为6700w 。这里后续有调整么?什么版本调整的?

业务库的表,字段,索引应该都很多,才会导致这张表数据量大。。看看高版本是否有其它的索引? 提交给官方修复一下/是否可以给元数据表添加索引

mysql下的表没啥办法,不知道后面的版本会不会针对这个表有优化,可以升级测试下。。。

:joy:目前不能升级,所以想问问在哪个版本里优化了。

UNIQUE KEY tbl (table_id,is_index,hist_id)属于符合索引,我记得需要符合table_id=0 and is_index=0才能用到。

是的,但是这个语句是数据库系统语句,没有办法修改。

https://github.com/pingcap/tidb/pull/50874 这个 PR 应该是优化这个问题。
v6 版本只要查询 information_schema.tables 就会触发这个查询 sql 来补充 tables 表的一些信息, 高版本是把 table_id 下推了,相当于过滤条件变多了,应该会快很多。

优化的表里,没有我提到的那个表,另外这个版本跨度太大了,短时间不会升级。

tidb 查询 information_schema.tables 时,需要先在内存里构建 information_schema.tables 内存表,这个时候会触发内部 sql (就是你现在出问题的语句)查询 stats_histograms 表去查询列长度信息以此来填充 information_schema.tables 的某个字段。

所以根本原因问题不是优化 stats_histograms 而是需要去优化 information_schema.tables
ps: navicate 每次连接都会查询 information_schema.tables 表的,为了方便你通过 navicate 查看表信息。

:thinking: 很奇怪,不知道是不是因为有个长期存在的全局临时表导致的。

和表的数量以及列的数量有关系,你可以分析下里面的数据是不是符合预期的。

+------------------+-----------------+------+------+---------+-------+
| Field            | Type            | Null | Key  | Default | Extra |
+------------------+-----------------+------+------+---------+-------+
| table_id         | bigint          | NO   | MUL  | NULL    |       |
| is_index         | tinyint         | NO   |      | NULL    |       |
| hist_id          | bigint          | NO   |      | NULL    |       |
| distinct_count   | bigint          | NO   |      | NULL    |       |
| null_count       | bigint          | NO   |      | 0       |       |
| tot_col_size     | bigint          | NO   |      | 0       |       |
| modify_count     | bigint          | NO   |      | 0       |       |
| version          | bigint unsigned | NO   |      | 0       |       |
| cm_sketch        | mediumblob      | YES  |      | NULL    |       |
| stats_ver        | bigint          | NO   |      | 0       |       |
| flag             | bigint          | NO   |      | 0       |       |
| correlation      | double          | NO   |      | 0       |       |
| last_analyze_pos | longblob        | YES  |      | NULL    |       |
+------------------+-----------------+------+------+---------+-------+

对,这个表里数据量个人感觉有点太多了。这个表有定时清理机制么?

:thinking:这个mysql.stats_histograms 表按table_id汇总,一共有600w个table_id,但是INFORMATION_SCHEMA.TABLES表里按TIDB_TABLE_ID汇总,只有1179个tidb_table_id。
这里就很奇怪,是因为我们用了太多临时表导致的么?理论上两个表的table_id应该一样吧。

找一些 stats_histograms 里存在,TABLES 不存在的 table_id 去看看都是啥表名呗

:thinking:好像找到原因了,有个业务会不停的创建、使用、删除临时表。会不会是这个临时表的直方图信息?

这种table_id从哪里找对应的表名?

是不是有任务

什么任务?定时清理的任务么?