TiDB统计信息自动更新导致执行计划突变，本质上是优化器依赖的统计信息突然变化，导致生成的执行计划与之前不同，可能引发性能回退。解决的核心思路是：理解统计信息收集机制，通过手动干预更新策略、使用执行计划绑定或SQL Hint来稳定执行计划，同时监控"stats_meta"表的变化并考虑调整"auto_analyze"相关系统变量。
理解TiDB统计信息自动更新的触发机制
TiDB的统计信息自动更新主要由"auto_analyze"机制驱动。当表中数据发生大量变更（如超过"tidb_auto_analyze_ratio"阈值，默认0.5）时，TiDB会在后台自动触发"ANALYZE"操作来重新收集统计信息。此外，统计信息本身也有健康度（health）的概念，当健康度过低时也可能触发更新。这个机制旨在保证优化器拥有最新数据分布信息，但副作用是：如果新收集的统计信息与旧版本差异巨大，优化器可能选择截然不同的执行计划（例如从索引扫描变为全表扫描），造成查询延迟突然增加。
突变场景的具体分析：何时最易发生？
执行计划突变通常出现在以下场景：
(1) 批量数据导入或删除后，自动"ANALYZE"立即运行，统计信息剧烈变化；
(2) 表中数据分布不均匀，自动收集的采样率（默认"tidb_auto_analyze_ratio"）可能无法准确反映真实分布，导致基数估算错误；
(3) 多版本统计信息（从TiDB v6.5.0开始支持）切换时，如果新版本统计信息有偏差，也会引发计划变化。你需要检查"mysql.stats_meta"表的"modify_count"和"version"字段，观察统计信息更新时间点是否与性能问题发生时间吻合。
立即应对：如何快速稳定当前执行计划？
若突变已导致生产环境性能下降，优先使用执行计划绑定（SQL Binding）强制固定原有高效计划。通过"CREATE [GLOBAL] BINDING FOR ... USING ..."语句将问题SQL绑定到原有执行计划。例如：
CREATE GLOBAL BINDING FOR SELECT * FROM t WHERE a = ? USING SELECT /*+ USE_INDEX(t, idx_a) */ * FROM t WHERE a = ?;
同时，可临时禁用自动更新：设置全局变量"set global tidb_enable_auto_analyze = OFF;"，但需谨慎，长期关闭可能导致统计信息过时。
中期调整：优化自动更新配置与策略
为避免频繁突变，需调整自动分析参数。主要变量包括："tidb_auto_analyze_ratio"（触发自动分析的修改比例阈值，可适当调高至0.8以减少触发频率）、"tidb_auto_analyze_start_time"和"tidb_auto_analyze_end_time"（将自动分析限制在业务低峰期，如凌晨02:00-04:00）。此外，可考虑对关键表改为手动定时分析，通过crontab在低峰期执行"ANALYZE TABLE"命令，并配合"WITH"参数控制采样精度，例如：
ANALYZE TABLE orders WITH 1024 SAMPLES, 0.8 RATE;
对于分区表，注意统计信息可能按分区收集，需评估是否需要对整个表进行全局分析。
长期监控：建立统计信息与执行计划变更的预警体系
构建监控链路至关重要。首先，通过TiDB Dashboard或监控系统追踪"auto_analyze"相关指标，如"tidb_statistics_auto_analyze_total"。其次，定期查询"INFORMATION_SCHEMA.CLUSTER_STATEMENTS_SUMMARY"或使用"SQL诊断"功能，对比同一SQL在不同时间段的执行计划差异。推荐开启"statistics_feedback"功能（实验性），它可能帮助优化器微调基数估算。对于核心业务查询，可定期使用"EXPLAIN ANALYZE"验证执行计划稳定性，并将历史计划存入备份表以便对比。
深入方案：使用SQL Hint与优化器规则干预
在SQL中嵌入Hint是直接干预优化器的有效方法。除索引Hint外，还可使用"MAX_EXECUTION_TIME"限制查询最大执行时间，防止突变计划长时间占用资源。对于复杂查询，考虑使用"MERGE_JOIN(t1, t2)"等Join方法Hint固定连接顺序。注意，Hint需嵌入原始SQL，如果应用层SQL不易修改，可结合执行计划绑定使用。同时，评估调整优化器相关系统变量，如"tidb_opt_agg_push_down"等，但需充分测试，避免影响全局。
进阶考量：统计信息管理功能与多版本选择
TiDB v6.5.0后引入了统计信息多版本管理。你可以通过"SHOW STATS_META"查看历史版本，并使用"SET GLOBAL tidb_analyze_version = 2;"切换统计信息版本（v2更准确但收集耗时更长）。如果自动更新后计划突变，可考虑回退到之前版本的统计信息：
RESTORE STATS stats_table_name TO '2023-10-01 12:00:00';
此外，关注"ANALYZE"的并发度控制（"tidb_analyze_version"和"tidb_build_stats_concurrency"），避免分析操作对在线业务造成资源竞争。
总结：构建预防为主的治理流程
根本解决执行计划突变需建立统计信息治理流程：
(1) 在重大数据变更（如批量ETL）后手动执行"ANALYZE"并验证执行计划；
(2) 为核心查询创建基线绑定，并纳入版本管理；
(3) 定期审核自动分析配置与阈值，根据业务数据变化周期调整；
(4) 培训团队识别执行计划突变的关键指标，如"Scan"算子行数估算严重偏差、执行时间陡增等。TiDB的优化器仍在持续演进，保持版本更新并关注新特性（如Histogram的增强）也是长期优化的一部分。
