【 TiDB 使用环境】生产环境
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】
SELECT * FROM INFORMATION_SCHEMA.ANALYZE_STATUS WHERE table_name=‘XXX’;
如果，同一个表，2亿多的表，自动收集就没一次成功的，执行了20分钟报错。
手动收集只话了11分钟就好了。看job info内容都是一样的。
auto analyze table all columns with 256 buckets, 500 topn, 0.0004305733879263856 samplerate
analyze table all columns with 256 buckets, 500 topn, 0.0004305733879263856 samplerate
这个自动收集和手动收集差别在哪？为啥相差这么大？
Long auto-analyze txn blocks GC · Issue #35062 · pingcap/tidb (github.com)
Auto analyze throw GCTooEarly error · Issue #29862 · pingcap/tidb (github.com)
确实是影响6.1
concurrency 手动和自动的参数比较一下就看到差异了，自动的设置都比较低
没有手动设置过。你指的是哪个参数？
| tidb_auto_build_stats_concurrency | 1 |
| tidb_build_stats_concurrency | 8 |
我这个版本怎么只有| tidb_build_stats_concurrency | 4 |
auto那个没有。
哦 看到文档了，6.5新增的
是不是遇到啥bug了？
自动收集的并发的设置成1了，所以速度比较慢。20分钟就报错，看看gc 的时间，是不是超过gc 了
好吧，我刚升级到这个版本
哪里可以看到自动收集的并发是1呢？我就是想知道这个差别在哪
你可以把下面的参数都是设置成1，然后手动的收集一下，执行的时间应该是和自动收集时间是差不多的。
执行 ANALYZE 语句的时候，你可以通过一些参数来调整并发度，以控制对系统的影响。
目前 ANALYZE 执行的时候会被切分成一个个小的任务，每个任务只负责某一个列或者索引。tidb_build_stats_concurrency 可以控制同时执行的任务的数量，其默认值是 4。
在执行分析普通列任务的时候，tidb_distsql_scan_concurrency 可以用于控制一次读取的 Region 数量，其默认值是 15。
在执行分析索引列任务的时候，tidb_index_serial_scan_concurrency 可以用于控制一次读取的 Region 数量，其默认值是 1。
自动收集的时候这些参数值都是1吗？这个哪个文档里面有提到？
6.5上没有遇到类似问题
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
