大多数关系型数据库都采用基于成本的 CBO 优化器，CBO 工作依赖表的统计信息，因此统计信息的正确性、可管理性、收集稳定性等对系统非常重要，TiDB 在不断的进行相关优化，6.0 版本中针对统计信息管理方面引入了几个非常实用的功能，大大提升了系统的可管理性。

       统计信息其他问题可参考：统计信息十问: 你不了解的那些事儿 https://tidb.net/blog/92447a59

1 Kill Auto analyze

在 6.0 版本前 tidb 的 show processlist 仅显示了普通用户会话的信息，相关的数据结构中未记录内部会话或事务的信息，因此对于自动统计信息收集等内部 session 无法使用该命令查看，仅能通过 stats leader 的 tidb.log 日志看到相关的触发信息或show analyze status 查看。由于无法获得 auto analyze 任务的 connect id，也没有其他的专有命令，因此对于正在执行的 auto analyze 任务无法被用户取消或kill。

       TiDB 6.0 版本开始通过 show processlist 可以查看内部会话的信息，对于 auto analyze 任务可以直接使用kill取消正在执行的收集任务，当出现因 auto analyze 导致的性能影响时能够及时处理。

被 kill 的 auto analyze 会显示状态为 failed。

2 GC safepoint 优化

在 GC 计算 safepoint 时，会从 PD 获取当前时间 now 并减去 24 小时( max-txn-time-use )作为 startTSLowerLimit，然后获取所有活动事务的 processlist 的 startts, 以 min(startTSLowerLimit，startts) 为 safepoint 时间。 在 6.0 版本前 auto analyze 和其他的内部 session 和事务 并不会被作为 GC safepoint 的计算依据 (show processlist 也不会展示)，这样会导致 safepoint > auto analyze 事务的 start_ts 的情况，对于大表 auto analyze 需要读取的数据已被 GC 导致 auto analyze 失败。

       6.0 版本后 tidb 不仅对内部会话和内部事务的管理做了调整，同时对 GC safepoint 时间计算也考虑了内部事务信息，从而保证 auto analyze 不会因为 GC 导致失败。

3 Stats history

统计信息记录在 mysql 模式下 stats* 相关表里，每次统计信息收集时会使用新的数据覆盖原来的数据。在有些情况下当系统出现问题后，需要对问题发生时的统计信息进行分析，由于统计信息收集后进行了更新，导致不能获得当时的统计信息。

       在 6.0 版本中引入了 stats_meta_history、stats_history 2个表用于存储历史统计信息，stats_meta_history 是 stats_meta 的历史信息，stats_history 里是具体的统计信息，以 longblob 字段存储。当统计信息收集时会先将历史信息插入到2个表中，然后在更新 stats* 表的统计信息。该功能默认关闭，可通过调整变量 tidb_enable_historical_stats 开启。