tidb系统查询较多

【TiDB 版本】5.0

【问题描述】

SELECT
value
FROM
mysql.stats_fm_sketch
WHERE
table_id = 15188
AND is_index = 0
AND hist_id = 2;

这种查询很多,占较大内存,导致对网络有影响

这类查询是一直都有还是集中在 08:36 左右出现的?这个期间有做过 analyze 操作吗?

有做过analyze 操作

analyze 操作之后这个查询语句是一直存在的吗?还是说只存在一会就没有了?可以看下具体 SQL 详情,看下具体慢在哪个阶段上。

能不能控制某些表不收集统计信息?

统计信息自动收集的时间窗口可以控制,参考下:
https://docs.pingcap.com/zh/tidb/stable/statistics#自动更新
但现在没有这种类似黑名单的功能来指定不收集哪些表的统计信息。

集群关闭重启后还存在这些查询,有没有什么终极方案?

请问重启之后 dashboard 中的系统查询 SQL 还是上面访问 mysql.stats_fm_sketch 的语句吗?

是的,还有很多

看table_id就是两张表的信息不停的刷

这两张表数据量变化很频繁吗?麻烦核实下在重启之后是否发生了 analyze ,可以从 dashboard 或者下面这条 SQL 查询下:

SELECT * FROM `ANALYZE_STATUS`;

重启之后没有分析过这两张表

麻烦反馈下重启之后的 tidb 日志,我们这边分析下可能触发的原因。

tidb_10_250_148_70_4000.zip (1.3 MB)

不好意思,麻烦再提供下上面两张表的表名和 table_id

13483 async_task_uncompleted
15188 sync_task

我在日志中发现有集群重启后发生了多次 auto stats ,日志信息类似如下:

["[stats] auto analyze triggered"] [sql="analyze table `retail_ios`.`async_task_uncompleted`"] [reason="too many modifications(4548/9082>0.5)"]

你可以对照日志中的时间和 dashboard 中出现慢 SQL 的时间点比对一下,看下是否一致。

终极方案,删表重建,问题解决:upside_down_face:

:thinking:

这个是由于统计信息在更新时的没有清理干净 mysql.stats_fm_sketch 中的历史版本导致单词读取的值偏大导致的
在 master 上已经由 https://github.com/pingcap/tidb/pull/23830 修复。目前 5.0 branch 的 fix 还和合并流程中。
历史版本干净之后,虽然因为频繁更新它的读取频率不会低,但是网络影响会减轻很多

这个表是为了得到精度足够的分区表的全局统计信息引入的新的表。4.0 中不会有同样的问题出现。

简单一些的 workaround 是 delete 掉 mysql.stats_fm_sketch 中对应表的记录之后再 analyze 就可以。delete * from mysql.stats_fm_sketch where table_id = ...

1赞