【TiDB 版本】
【配置】
【遇到的问题】
问题1：5点的时候正在执行的 analyze 任务被中断，导致某个表的部分索引信息没更新成功，但是我看 healthy 健康度已经 100%了，这样可能会导致虽然健康度 ok 但是因为部分索引没更新统计信息，导致优化器选错索引
问题2：analyze jobs 表记录的是一个表拆分列、索引去 analyze，为什么看慢速记录的 SQL 是合并成一个 analyze 语句的，例如 analyze table t1
问题1：可以参考这篇文章 专栏 - TiDB 优化器丨统计信息技术剖析及使用建议 | TiDB 社区
tidb_auto_analyze_end_time 的影响： tidb_auto_analyze_end_time 参数定义了自动 ANALYZE 任务允许执行的截止时间。当达到这个时间点时，TiDB 会尝试终止正在进行的自动 ANALYZE 任务。如果任务未能及时完成，就会被中断，导致部分统计信息未更新。
健康度计算： TiDB 的统计信息健康度（healthy）是根据表的整体统计信息新鲜度来计算的。它可能无法精确反映到表中所有列和索引的统计信息是否都已更新到最新状态，尤其是当部分 ANALYZE 任务被中断时。如果表的主键或主要查询路径涉及的统计信息是健康的，但某些其他索引或列的统计信息因为中断而陈旧，健康度可能仍显示为100%。
问题2：
当 TiDB 内部执行这些由调度器生成的 ANALYZE 任务时，为了提高效率和减少与 TiKV 的交互次数，它会将针对同一张表的多个需要 ANALYZE 的列或索引合并成一个单一的 ANALYZE TABLE SQL 语句来执行。例如，如果 t1 表的 idx_a 索引和 col_b 列都需要更新统计信息，TiDB 可能在慢查询日志中显示 ANALYZE TABLE t1，而不是两条独立的 ANALYZE TABLE t1 INDEX idx_a 和 ANALYZE TABLE t1 COLUMNS col_b 语句。这种合并是内部优化行为。
如果有很大的表的话不建议自动收集，因为自动收集是单线程的，时间可能会很长，并且不一定成功，建议手动部署脚本修改并发参数按比例收集大表。
我们现在有一个大表 analyze 时间过长，导致可能在限制的时间范围内一直执行失败，出现了索引选错有慢速的问题，但是 healthy 健康度是 ok 的情况。
你的 analyze 版本是 1，现在的默认值是 2，还有 batch_size 才是 128，对于大表来说太小了，参考下文档
专栏 - TiDB 优化器丨统计信息技术剖析及使用建议 | TiDB 社区…
你参数设置的不太对，自己改改吧
想请教一下，如果切换 version 2，据官网描述会影响一段时间内没有统计信息，可能会导致大量慢速。这种情况应该怎么处理呢，目前 tidb 应用比较多
还有这个 batch_size 只针对分区表，如果是普通表有可调整的参数吗
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
