TIDB analyze table 卡住， 一直处于运行中

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】4.0.8
【复现路径】analyze table table_name;
【遇到的问题：问题现象及影响】
执行一直运行中，卡住， 日志显示执行sql代价比较大
[2024/04/29 15:51:35.217 +08:00] [WARN] [expensivequery.go:168] [expensive_query] [cost_time=60.066512705s] [conn_id=163533] [user=root] [database=teaching_study_muster_wb] [txn_start_ts=0] [mem_max=“0 Bytes (0 Bytes)”] [sql=“analyze table user_learntime”]

表行数 2.3万条
查看状态
±-------------------------±-----------------±---------------±------------------------±---------------±--------------------±--------+
| Table_schema | Table_name | Partition_name | Job_info | Processed_rows | Start_time | State |
±-------------------------±-----------------±---------------±------------------------±---------------±--------------------±--------+
| teaching | user_learntime | | analyze index IX_userId | 23165 | 2024-04-29 15:50:35 | running |
| teaching | user_learntime | | analyze columns | 23165 | 2024-04-29 15:50:35 | running |
| dba | killed_sql_table | | analyze columns | 0 | 2024-04-29 16:24:26 | running |

集群信息 6TIKV 3PD 3TIDB

2

是不是表mvcc太多了 ，explain analyze 一个全表扫描sql看看

3

这表才2.3万条啊，竟然卡住了，估计版本太老了吧

4

这个怎么处理呢？ 0行的表都卡住

5

4.0.8版本一直没升级

6

show table xxx regions 或者tikv_region_status 看下这个表多少region

7

mysql> explain select * from user_learntime ;
±----------------------±---------±----------±---------------------±---------------------+
| id | estRows | task | access object | operator info |
±----------------------±---------±----------±---------------------±---------------------+
| TableReader_5 | 23165.00 | root | | data:TableFullScan_4 |
| └─TableFullScan_4 | 23165.00 | cop[tikv] | table:user_learntime | keep order:false |
±----------------------±---------±----------±---------------------±---------------------+
2 rows in set (0.00 sec)

8

mysql> show table user_learntime regions;
±----------±----------±--------±----------±----------------±---------------------------±-----------±--------------±-----------±---------------------±-----------------+
| REGION_ID | START_KEY | END_KEY | LEADER_ID | LEADER_STORE_ID | PEERS | SCATTERING | WRITTEN_BYTES | READ_BYTES | APPROXIMATE_SIZE(MB) | APPROXIMATE_KEYS |
±----------±----------±--------±----------±----------------±---------------------------±-----------±--------------±-----------±---------------------±-----------------+
| 285209 | t_984_ | t_986_ | 3813789 | 10 | 3813789, 3866620, 10958513 | 0 | 1683 | 0 | 3 | 40960 |
±----------±----------±--------±----------±----------------±---------------------------±-----------±--------------±-----------±---------------------±-----------------+
1 row in set (0.01 sec)

9

感觉是集群哪里有问题， 是每个表都会卡住，而不是某个个例，日志没有看出什么问题，监控看起来似乎也正常

10

能看到每个组件的状态吗，你这版本应该没tiup吧

11

https://docs.pingcap.com/zh/tidb/stable/sql-faq#在-tidb-中-auto-analyze-的触发策略是怎样的

是不是这个参数调整过，导致频繁analyze

12

4.0.8里我也碰到过，我就几万条 ，analyze过不去
你看看你的 auto analyze是不是也停了很久了

我是重启的所有的tidb server，然后就可以了，应该是tidb server 哪儿卡了
没有报错，问题也没法查。

不行就升级吧~:smiling_imp:

13

4.0开始有tiup了， 组件都是正常状态

14

确实调整过， 时间和阈值都调整了， 0.5->0.3 时间限制范围了

15

你说的现象确实是这样， 好久没有analyze了， 我是有个应该很快的sql执行花费时间特别久， 并且明明是执行中状态，但是processlist里查看是sleep状态， 并且到tidb节点卡顿， 后来把所有的sleep的进程也kill了，然后就不卡顿了，但是那个sql一直执行不下去

16

推荐升级吧。感觉可能是触发了什么 bug。卡主是不应该的。

这个版本已经 EOL

17

服务器资源不足？

18

analyze早先版本bug居多

20

重启已经恢复正常， 分析也快了不少