【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 日志，我们这边分析下可能触发的原因。
不好意思，麻烦再提供下上面两张表的表名和 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 的时间点比对一下，看下是否一致。
终极方案,删表重建,问题解决
这个是由于统计信息在更新时的没有清理干净 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 = ...
2 个赞