【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.1.7
【复现路径】通过DTS全量灌入数据
【遇到的问题：问题现象及影响】 执行show stats_healthy发现70%的表【表个数总计2万+张】的统计值均是0，只有30%所有的表的值是100，TIDB对表统计信息的收集有过特殊处理么？ 因为原生MySQL还未遇到过这类问题
直接查询表看有多少呢
统计信息，有两种处理方式：
- 自动处理，需要开启并配置规则
- 手动处理，通过SQL 语句运行即可
数据量级的变化，如果没及时收集统计信息，会引发查询优化上的不一致…
参考文档：
https://docs.pingcap.com/zh/tidb/stable/statistics#统计信息简介
https://docs.pingcap.com/zh/tidb/stable/dev-guide-delete-data#更新统计信息
查询表数据量没问题，只是担心统计信息不准会导致执行计划也不准
我理解统计信息的收集需要产品自身自动处理的，我看官方文档中，关于自动处理的内容并不多，主要讲了tidb_analyze_version配置，看当前默认是2，对于统计信息收集的一些配置对比了官方文档，也没发现什么线索，难道TIDB的统计信息收集任务是单线程运行的？几万张表的场景是不是收集速度太慢了 
对，自动的任务还就是单线程的 
嫌慢可以手动搞搞 
看来这里会有个很严重的坑，万一哪天线上表【表数量比较多的场景】统计信息不准了，执行计划在一不准就完蛋了
没事，tidb 的版本还在迭代，后续的资源隔离的能力，就是为了适用资源的最大利用场景，会慢慢改善的
目前如果发现有类似的问题，可能需要手动的方式来处理下（或者 采用 hint 的方式，即使采集的统计信息落后了，也不会影响 sql 的优化 和命中的过程）
6.5引入了一个参数，如果核数和内存充足，可以并发大点：
tidb_auto_build_stats_concurrency 从 v6.5.0 版本开始引入
- 作用域：GLOBAL
- 是否持久化到集群：是
- 类型：整数型
- 默认值：
1 - 范围：
[1, 256] - 这个变量用来设置执行统计信息自动更新的并发度。
看来又得升级版本了，哈哈
全新导入的数据是要全部收集统计信息的，你可以看看lightning导入，他最后都是要analyze 全部表
如果不立即收集，只能等他自动收集了
原生MySQL肯定是不需要的【innodb和rocksdb】
而且还发现了一个问题，人工触发的analyze table操作其实是同步进行的【采样比例基本都在10%左右，所以耗时比较长】，不像原生mysql一样，是异步进行的
我看6.1.7版本中有tidb_build_stats_concurrency这个参数了，我试试增加并发看看效果