analyze 执行后，引起大量慢查询

🪐 TiDB 技术问题
1

【TiDB 使用环境】

  • 生产环境

【TiDB 版本】

  • 8.1.1

【遇到的问题】
有一张大表（10亿），晚间自动 analyze 执行后，突然大量慢速。因为慢速太多，重启 TiDB 节点后才恢复。

【慢速SQL】

select `post_id`, `created_at` from `user_device_visit_record` where `device_type` = ? and `device_id` = ? and `created_at` >= ? and `type` = ?

【analyze 状态】

image
image3614×372 223 KB

3:53 analyze primary key 的时候卡死了

【疑问】

  • 查看官方文档 https://docs.pingcap.com/zh/tidb/v8.1/statistics/#count-min-sketch ，感觉可能是因为 Count-Min Sketch 导致哈希冲突。
  • 目前 tidb_analyze_version = 1，如果切换 version = 2 会导致所有表的索引统计失效吗，这样可能会引起线上故障
  • 打算让自动 analyze 改为定时手动 analyze，请问针对这种情况，手动收集应该怎么优化呢？
2

1、执行analyze的时候，本身是会影响查询效率的。
2、切换后应该不会失效
3、我们是晚上日终定时作业里去手动收集的。

3

凌晨一直都有自动 analyze，前一天都没问题，突然就出现了。

4

昨天数据量变化大么？凌晨服务器资源充足么？如果什么都没改，一直正常用的功能突然出问题了，一般就是资源问题了。

5

数据量变化正常的，我看监控 tidb 的慢速增多，内存也增加了，io 其实还好

image
image4012×1136 465 KB

6

这是直接oom了吧，你看下tidb-server重启了吗？集群拓扑是啥样的，有混合部署吗？

7

:thinking:看看dashboard里的慢查询，有可能是刚好某个表在analyze，然后查询用到了这个表，导致全表扫描，占用了较多的内存。

8

没有 OOM，6点手动重启的

9

就是 analyze 这张表慢查询最多，也是热点表