版本7.1
数据清理+数据插入造成的吗？如何避免这种频繁的analyze table?
顺便也问下，触发的机制和参数是哪些？
show variables like ‘%analyze%’ 先看这几个参数的作用
嗯，找到了
如何避免短时间内，进行多次的analyze?
有版主吗，帮看下问题
嗯，触发机制的各种参数看了，但是好像没有控制这个短时间执行多次的问题
如果是大批量的插入，会在一次批量插入中间，触发几次anal?
如果开启自动analyze应该可以配置时间范围吧。
这个时间是实例级别的参数吧，不能控制某个表的时间范围吧？
还有就是这个参数例如调整到13点到15点 ，是指只有这2个小时符合analyze的变动表执行，还是说其他时间也都在收集统计信息，但只是没有执行analyze？
收集统计信息=analyze
是一回事。
另外控制analyze，是集群级别的参数，整个集群只会在规定的时间范围内执行自动analyze。除非你手动analyze。
比实例和表的粒度都粗。
另外我总觉得，你这个一次analyze需要30s+，不太像是自动的anlyze，像是手动的analyze。
去tidb_ddl_history表里查查看，我记得自动的analyze后面不会是这种光秃秃的。后面会有一堆SAMPLES之类的参数。
你这个图上看着后面什么参数都没有。我很怀疑是不是自动analyze的原因。
是自动的，截图是从dashboard慢sql里截的
1 个赞
在anlyze start-end time间超过 analyze ratio 都可能会触发分析，你的表增删改很频繁吗？ 可以把这个表 lock stats
就是一次性灌入了100多万行数据，就这一个操作
能把这表的show analyze status 发出来看看吗
不想短时间多次可以配置一个时间段触发，那个时间段意外不触发
不能像mysql那样完全无感吗？
mysql是抽样，tidb好像是全量收集
短时间大规模的数据变动就会引起后台任务。一般性影响不大，但是如果你的表数据比较大，就可能存在风险了。
- 版本升级到7.5+ ， TiDB 分布式执行框架 | PingCAP 文档中心用这个特性避免后台任务导致tidb内存占用过高被系统kill。
- 表转换成分区表，原理就是把数据打散，避免后台执行任务效率问题。