审视计划跳变场景

优化器生成计划的方式是基于代价完成的(Cost Based Optimizer)，其会根据代价模型和相关表的统计信息生成最优的执行计划。因此，相关表的统计信息变更或代价模型的参数修改都会影响最优计划的生成。此外，生产业务的许多操作均会导致计划缓存失效并重建，如更新统计信息的相关操作（VACUUM、ANALYZE、AUTOVACUUM、AUTOANALYZE）、重建索引等DDL操作、施加SQL Patch和其他导致缓存失效的场景。如果期间基于代价生成的最优计划与之前不同，就会发生计划跳变。故计划跳变在生产业务中是一种较为常见的现象。

一般而言，正向的计划跳变无需重点关注。需要重点关注因计划跳变导致性能下降、CPU冲高等一系列后果的场景。这通常伴随着数据库环境变量变更，如统计信息更新，表结构变更或数据库版本升级。

在GaussDB中，有如下几类场景可能导致计划跳变，需要业务审视并应用精准的调优手段（Hint等）。

• Generic-Plan的重建：业务稳定运行时通常执行的是Generic-Plan，表示计划已经稳定不再需要优化器对SQL进行优化。而有些情况会导致Generic-Plan失效需要重新构建：
  • 修改GUC参数：修改GUC参数会导致Generic-Plan的重建，而修改优化器相关参数如query_dop等会导致计划跳变。稳定业务非特殊需求应尽量避免修改优化器相关参数。
  • 对查询中涉及的基表进行了DDL操作：对表的DDL操作会导致Generic-Plan的重建，而对索引进行增删改会影响计划选择。若对索引进行调优需要保证索引有效性且及时更新索引统计信息保证选择更优的计划。
  • 对表进行IUD操作并手动或自动收集统计信息：统计信息的变化会导致Generic-Plan的重建。一般认为若统计信息收集及时，即使计划跳变通常不会引入性能劣化。业务中常见情况是对于查询中涉及的基表进行大量IUD而统计信息未及时更新，此时需要手动收集统计信息或审视自动收集统计信息的触发情况。
• 智能优化器：Generic-Plan在部分场景中并不能满足业务需求，例如数据倾斜的场景，对于不同的数据最优计划不同。而智能优化器会生成多个备选的Generic-Plan并实时根据查询反馈决策挑选其中最优的计划执行。智能优化器和业务执行的顺序有关，若智能优化器不能满足要求，建议对关键业务语句使用Hint或SQL Patch等手段进行针对性调优。