持续执行ANALYZE TABLE好几天

不频繁,使我们给客户私有化部署。初次MySQL同步到tidb后,就一直自动执行analyze

好的,多谢,我试一下这个参数

hi,有什么更新吗?

  1. (可能)auto_analyze 现在是写死的并发度 为 1 ,可能是数据量大导致就是很慢;
  2. (根因)现在其实还根因不明,analyze 慢只是现象,还需 表数据量,日志信息去分析为啥慢;
  3. (措施) tidb菜鸟一只 老师说的是一种可行的办法,但是降低 SAMPLERATE 有一定的执行计划不稳的可能;
  4. (措施) h5n1 老师说的也是一种可行的办法,手动 analyze 是可以调并发参数的,如果是因为数据量很大一直跑不完,这种办法是有效的。 tidb_build_stats_concurrency and tidb_distsql_scan_concurrency and tidb_index_serial_scan_concurrency

大表自动跑的一直失败 请问下为什么会失败呢

请问下老师,自动跑的analyze 语句会受到 max_execution_time 系统变量的控制嘛,如果自动跑的analyze 语句能够受到max_execution_time 系统变量控制的话,那么是不是可以把max_execution_time 设置一个能够接收的值呢?

自动跑是单线程跑的,肯定慢啊,所以会收集失败

难道是因为慢就收集失败?这不应该一直跑嘛,是不是有什么超时机制,或者跑的时候出问题了

有窗口期啊,不然一直跑,影响你正常业务了

你这个窗口期是通过max_execution_time 实现的嘛?

tidb_auto_analyze_start_time tidb_auto_analyze_end_time 这俩吧几点开始几点结束,大表不建议走自动收集,可以部署定时任务,开多线程小样本收集,不然太大的表真收集不完。。。

get了,多谢老师

其实也受这变量控制,多种条件相互干扰吧, tidb菜鸟一只 老师说的也是对的。

好的,谢谢


看下日志是不是这个错误“GC life time is shorter than transaction duration”?如果是,估计是大表,analyze超过了gc life time ;可以通过手动analyze或者建一个crontab任务来进行。

这种analyze 会阻塞gc嘛

对于 GC 来说,分版本,高版本有个 max-gc-wait-time 之类的系统变量,低版本会等 24h 之后干掉那个事务(hard code),高版本因为这个变量干掉 txn 的时间可变。

https://github.com/pingcap/tidb/pull/32726/files

对于 analyze 来说,分版本,低版本是取 maxUint64 做 txn start_ts 忽略 txn 影响,但高版本选择了 snapshot 方式进行 analyze,会受到 txn 影响。

问题是 : analyze 会阻塞gc嘛?
首先,要看是什么版本,下面采用了什么机制,假设 max-gc-wait-time 设置无限长,同时 analyze 无限长时间跑不完,同时 analyze 又是取 snapshot 的方式,那么是会影响。需要具体问题,具体版本,具体分析。

总结来说,是否阻塞 GC 与 txn 有关,analyze 又与 txn 有关。

GC life time is shorter than transaction duration ,在高版本 不太容易 报这个错。
就是说 GC 会等 txn 执行完。

这应该是 v4 常出的一个问题🤔,我记得

老师,您好,想请教1个问题
以前根据我们v5.0版本的使用经验,一条语句最多执行24h,超过24h后,gc不会被阻塞,gc 就继续往前面推进了,想请问下
1.v5.0版本中,语句超过24h后,这条语句应该就是被tidb 自动Kill 了吧
2.之前听说到了6.1版本后,语句执行不能超过24h的这个硬限制,有1个系统变量来控制这种行为,那么这个系统变量应该就是 tidb_gc_max_wait_time 吧,这个变量的作用原理 应该就是把超过这个系统变量运行的时间的语句给自动kill 吧?

可以手动用命令执行,这个会快一点

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。