analyze table xxx index failed

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】6.1.2
【复现路径】建了个大表的索引，在日志中提示错误，analyze table failed
【遇到的问题：问题现象及影响】

2022-12-15 00:17:56 (GMT+8)
TiDB 12.0.0.88:4000
[update.go:1218] [“[stats] auto analyze failed”] [sql=“analyze table ssss.tab_xxxx index idx_custCode”] [cost_time=19m58.677442321s] [error=“[tikv:9006]GC life time is shorter than transaction duration, transaction starts at 2022-12-14 23:57:58.2 +0800 CST, GC safe point is 2022-12-15 00:07:40.851 +0800 CST”]

6.1版本不是有这个参数了么：tidb_gc_max_wait_time ：这个变量用于指定活跃事务阻碍 GC safe point 推进的最大时间
为啥还会报错？
【资源配置】
【附件：截图/日志/监控】

3

可以试试调整 TiDB 中mysql.tidb 表中的 tikv_gc_life_time 的值来调大 MVCC 版本保留时间.
详见官网：https://docs.pingcap.com/zh/tidb/stable/dev-guide-timeouts-in-tidb#gc-超时

image
image1680×792 176 KB

为啥新的变量没生效，俺也不知。。

4

这个变量用于指定活跃事务阻碍 GC safe point 推进的最大时间，进行的操作就是把超过 time 的 txn 干掉。

5

你把tidb_gc_max_wait_time 这个值设为多少了？从日志来看，语句才执行了19分钟

6

参考下：持续执行ANALYZE TABLE好几天 - #21，来自 Hacker_loCdZ5zu.

7

tidb_gc_max_wait_time 这个从参数是系统容忍gc等待的最长时间，你的报错实际是gc活动时间不够，应该调大的是tidb_gc_life_time这个参数，应该是你的表数据变化太快，索引一直在变化，然后你收集统计信息的动作还没完成，已经超过tidb_gc_life_time这个时间了，建议调大之后再试一下。

8

对于大表，建议手动用脚本收集，自动收集的并发度没办法调整，速度比较慢

9

麻烦看看这个参数

tidb_max_auto_analyze_time 从 v6.1.0 版本开始引入

  • 作用域：GLOBAL
  • 是否持久化到集群：是
  • 默认值：43200
  • 范围：[0, 2147483647]
  • 单位：秒
  • 这个变量用于指定自动 ANALYZE 的最大执行时间。当执行时间超出指定的时间时，自动 ANALYZE 会被终止。当该变量值为 0 时，自动 ANALYZE 没有最大执行时间的限制。
10

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