背景信息 ANALYZE语句可收集与数据库中表内容相关的统计信息，统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据，以生成最有效的执行计划。ANALYZE语句操作请参见ANALYZE | ANALYSE。 建议在执行了大批量插入/删除操作后，例行对表或全库执行ANALYZE语句更新统计信息。目前默认收集统计信息的采样比例是30000行（即：GUC参数default_statistics_target默认设置为100），如果表的总行数超过一定行数（大于1600000），建议设置GUC参数default_statistics_target为-2，即按2%收集样本估算统计信息。 对于在批处理脚本或者存储过程中生成的中间表，也需要在完成数据生成之后显式地调用ANALYZE。 对于表中多个列有相关性且查询中有同时基于这些列的条件或分组操作的情况，可尝试收集多列统计信息，以便查询优化器可以更准确地估算行数，并生成更有效的执行计划。

操作步骤 收集SQL中涉及到的所有表的统计信息。在数据库中，统计信息是优化器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化，从而导致性能问题。从经验数据来看，10%左右性能问题是因为没有收集统计信息。具体请参见更新统计信息。 通过查看执行计划来查找原因。如果SQL长时间运行未结束，通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出结果，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及实际运行情况，以便更精确地定位问题原因。有关执行计划的详细介绍请参见SQL执行计划介绍。 审视和修改表定义。 针对EXPLAIN或EXPLAIN PERFORMANCE信息，定位SQL慢的具体原因以及改进措施，具体请参见典型SQL调优点。 通常情况下，有些SQL语句可以通过查询重写转换成等价的，或特定场景下等价的语句。重写后的语句比原语句更简单，且可以简化某些执行步骤达到提升性能的目的。查询重写方法在各个数据库中基本是通用的。经验总结：SQL语句改写规则介绍了几种常用的通过改写SQL进行调优的方法。 如果使用上述常规手段无法分析慢SQL根因的场景，还可以通过使用plan trace特性来分析慢SQL根因，具体请参见PLAN TRACE使用介绍。

审视计划跳变场景 优化器生成计划的方式是基于代价完成的(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等手段进行针对性调优。 父主题： SQL调优指南

操作步骤 收集SQL中涉及到的所有表的统计信息。在数据库中，统计信息是优化器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化，从而导致性能问题。从经验数据来看，10%左右性能问题是因为没有收集统计信息。具体请参见更新统计信息。 通过查看执行计划来查找原因。如果SQL长时间运行未结束，通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出结果，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及实际运行情况，以便更精确地定位问题原因。有关执行计划的详细介绍请参见SQL执行计划介绍。 审视和修改表定义。 针对EXPLAIN或EXPLAIN PERFORMANCE信息，定位SQL慢的具体原因以及改进措施，具体请参见典型SQL调优点。 通常情况下，有些SQL语句可以通过查询重写转换成等价的，或特定场景下等价的语句。重写后的语句比原语句更简单，且可以简化某些执行步骤达到提升性能的目的。查询重写方法在各个数据库中基本是通用的。经验总结：SQL语句改写规则介绍了几种常用的通过改写SQL进行调优的方法。

调优手段之GUC参数 查询优化的主要目的是为查询语句选择高效的执行方式。 如下SQL语句: 1 2 select count(1) from customer inner join store_sales on (ss_customer_sk = c_customer_sk); 在执行customer inner join store_sales的时候，GaussDB支持Nested Loop、Merge Join和Hash Join三种不同的Join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种Join方式的执行代价，然后对比选出执行代价最小的执行计划。 正如前面所说，执行代价计算都是基于一定的模型和统计信息进行估算，当因为某些原因代价估算不能反映真实的cost的时候，就需要通过GUC参数设置的方式让执行计划倾向更优规划。例如：random_page_cost参数表示优化器计算一次非顺序抓取磁盘页面的开销，该参数默认值为4。当机器磁盘随机读取的速度较快时，比如SSD设备，可以将该参数的值适当调小，更改后，索引扫描的代价降低，生成计划时更倾向于选择索引扫描的方式。

调优手段之统计信息 GaussDB优化器是典型的基于代价的优化(Cost-Based Optimization，简称CBO)。在这种优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值，以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost)，进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。这些特征值就是统计信息。从上面描述可以看出统计信息是查询优化的核心输入，准确的统计信息将帮助优化器选择最合适的查询规划，一般来说通过ANALYZE语法收集整个表或者表的若干个字段的统计信息，周期性地运行ANALYZE，或者在对表的大部分内容做了更改之后马上运行它是个好习惯。 注意，DDL可能会导致统计信息发生变化，进而导致计划跳变。当表上做了DDL操作后，应注意统计信息是否需要重新收集。

背景信息 ANALYZE语句可收集与数据库中表内容相关的统计信息，统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据，以生成最有效的执行计划。ANALYZE语句操作请参见ANALYZE | ANALYSE。 建议在执行了大批量插入/删除操作后，例行对表或全库执行ANALYZE语句更新统计信息。目前默认收集统计信息的采样比例是30000行（即：GUC参数default_statistics_target默认设置为100），如果表的总行数超过一定行数（大于1600000），建议设置GUC参数default_statistics_target为-2，即按2%收集样本估算统计信息。 对于在批处理脚本或者存储过程中生成的中间表，也需要在完成数据生成之后显式地调用ANALYZE。 对于表中多个列有相关性且查询中有同时基于这些列的条件或分组操作的情况，可尝试收集多列统计信息，以便查询优化器可以更准确地估算行数，并生成更有效的执行计划。 若表上存在全局二级索引，则需要对基表执行ANALYZE之后再对全局二级索引执行ANALYZE。

相关链接 SQL PATCH相关系统函数、系统表、系统视图和接口函数见表1 SQL PATCH相关系统函数、系统表、系统视图和接口函数介绍。 表1 SQL PATCH相关系统函数、系统表、系统视图和接口函数介绍 类别 名称 说明 系统函数 global_sql_patch_func() 全局各个节点上的SQL PATCH信息，用于返回global_sql_patch视图的结果。 系统表 GS_SQL_PATCH GS_SQL_PATCH系统表存储所有SQL_PATCH的状态信息。 系统视图 GLOBAL_SQL_PATCH GLOBAL_SQL_PATCH视图存放所有SQL PATCH的信息，该视图仅在pg_catalog模式下存在。 接口函数 DBE_SQL_UTIL Schema DBE_SQL_UTIL.create_hint_sql_patch create_hint_sql_patch是用于在当前建连的CN上创建调优SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.create_abort_sql_patch create_abort_sql_patch是用于在当前建连的CN上创建避险SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.drop_sql_patch drop_sql_patch是用于在当前建连的CN上删除SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.enable_sql_patch enable_sql_patch是用于在当前建连的CN上开启SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.disable_sql_patch disable_sql_patch是用于在当前建连的CN上禁用SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.show_sql_patch show_sql_patch是用于显示给定patch_name对应SQL PATCH的接口函数，返回运行结果。 DBE_SQL_UTIL.create_hint_sql_patch create_hint_sql_patch是用于创建调优SQL PATCH的接口函数，返回执行是否成功。本函数是原函数的重载函数，支持通过parent_unique_sql_id值限制hint patch的生效范围。 DBE_SQL_UTIL.create_abort_sql_patch create_abort_sql_patch是用于创建避险SQL PATCH的接口函数，返回执行是否成功。本函数是原函数的重载函数，支持通过parent_unique_sql_id值限制abort patch的生效范围。 DBE_SQL_UTIL.create_remote_hint_sql_patch create_remote_hint_sql_patch是用于指定CN创建调优SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.create_remote_abort_sql_patch create_remote_abort_sql_patch是用于指定CN创建避险SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.drop_remote_sql_patch drop_remote_sql_patch是用于指定CN删除SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.enable_remote_sql_patch enable_remote_sql_patch是用于指定CN开启SQL PATCH的接口函数，返回执行是否成功。 DBE_SQL_UTIL.disable_remote_sql_patch disable_remote_sql_patch是用于指定CN禁用SQL PATCH的接口函数，返回执行是否成功。

特性约束 仅支持针对Unique SQL ID添加补丁，如果存在Unique SQL ID冲突，用于hint调优的SQL PATCH可能影响性能，但不影响语义正确性。 仅支持不改变SQL语义的hint作为PATCH，不支持SQL改写。 不支持逻辑备份、恢复。 不支持在DN上创建SQL PATCH。 仅初始用户、运维管理员、监控管理员、系统管理员用户有权限执行。 库之间不共享，创建SQL PATCH时需要连接目标库。如果创建SQL PATCH的CN被剔除并触发全量Build，则会继承全量Build的目标CN中的SQL PATCH，因此建议在各个CN上尽量都创建对应的SQL PATCH。 CN之间由于Unique SQL ID不同，不共享SQL PATCH，需要用户手动在不同的CN上创建对应的SQL PATCH。 限制在存储过程内的SQL PATCH和全局的SQL PATCH不允许同时存在。 使用PREPARE + EXECUTE语法执行的预编译语句执行不支持使用SQL PATCH。存在特殊情况，请参见特殊说明。 SQL PATCH不建议在数据库中长期使用，只应该作为临时规避方法。遇到内核问题所导致的特定语句触发数据库服务不可用问题，以及使用hint进行调优的场景，需要尽快修改业务或升级内核版本解决问题。并且升级后由于Unique SQL ID生成方法可能变化，可能导致规避方法失效。 当前，除DML语句之外，其他SQL语句（如CREATE TABLE等）的Unique SQL ID是对语句文本直接哈希生成的，所以对于此类语句，SQL PATCH对大小写、空格、换行等敏感，即不同文本的语句，即使语义相同，仍然需要对应不同的SQL PATCH。对于DML，则同一个SQL PATCH可以对不同入参的语句生效，并且忽略大小写和空格。

审视计划跳变场景 优化器生成计划的方式是基于代价完成的(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等手段进行针对性调优。 父主题： SQL调优指南

功能描述 GaussDB当前已有慢查询相关视图，并具备了SPM的基础能力。然而，当发生计划跳变时，无法对非慢查询的执行计划进行历史记录。因此，本特性在基于SPM的基础上，对历史执行计划进行记录，以提升SPM的易用性。由于SPM当前仅支持Generic-Plan，因此本功能所管理的计划类型限定在Generic-Plan。 当前计划跳变存在两种主要情况： 优化器对相同查询产生了不同的执行计划，并最终选用了新的计划。 每次执行时，优化器在历史已有的计划中切换。 这两种事件，均被称为跳变事件。 由于本特性涉及对计划跳变的快速感知和快速恢复两部分，以下将分别进行简明介绍。 快速感知 如果要实现全量的计划跳变历史记录，最直接的方法是记录每次执行计划与上一次的不同。这种方法会带来极大的性能开销。因此，出于性能和资源的考虑，本特性在以下两种场景进行跳变事件记录： 当优化器产生了SPM的baseline中不存在的新的计划。 当优化器产生了SPM的baseline中存在的，但超过一段时间未执行的老计划。 具体的执行流程，如图1所示。 图1 计划跳变支持快速感知流程图 此特性需要保证GUC参数spm_enable_plan_capture设置为STORE模式，且打开跳变历史记录开关spm_enable_plan_history_logging。 从图1可知，除了以下情况，均会对因产生新计划导致的跳变事件进行记录。 场景一：如果当前所捕获的基线个数已经超出上限 （spm_plan_capture_max_plannum），则查看当前计划是否是SPM所捕获过的查询的新计划。当前spm_enable_plan_history_logging打开并且历史记录数未超过上限，则进行额外的基线捕获，并进行历史记录。 场景二：如果当前所记录的跳变事件个数已经超出上限 （spm_plan_capture_max_plannum），则不进行历史记录。 为了确保在长期运行中能够记录更多的跳变历史，SPM会设置定时任务，在数据库启动起的每24小时触发一次历史记录清理，其校验准则是查看当前的历史记录数占最大上限的百分比，若超出此百分比，则会删除一些最旧的历史记录以保证记录数在此百分比要求之下，此百分比由spm_plan_history_reserved_percentage设置。 快速恢复 当发生计划跳变时，可以通过设置历史时间点的某条计划相应的baseline状态为ACC/FIXED，再结合计划选择功能spm_enable_plan_selection，即可实现回退至历史计划完成计划固化，也即完成快速回退。

最佳实践 通常建议在业务低谷期打开spm_enable_plan_capture为STORE进行计划捕获，在批量执行业务完成后，打开历史记录开关spm_enable_plan_history_logging进行跳变历史记录。 在发生计划跳变时，可参考如下步骤操作。 获取unique_sql_id，比如通过statement_history查询。 gaussdb=# SELECT unique_query_id FROM DBE_PERF.statement_history; 根据unique_sql_id从PG_CATA LOG .GS_SPM_ID_HASH_JOIN中查出sql_hash。 gaussdb=# SELECT sql_hash FROM PG_CATALOG.gs_spm_id_hash_join WHERE unique_sql_id = $unique_query_id; 根据sql_hash和发生跳变的历史时间，利用系统函数（DBE_SQL_UTIL.GS_SPM_GET_PLAN_HISTORY）/视图(PG_CATALOG.GS_SPM_PLAN_HISTORY_DETAIL) /系统表（PG_CATALOG.GS_SPM_PLAN_HISTORY）中查出跳变历史。 gaussdb=# SELECT * FROM pg_catalog.gs_spm_plan_history WHERE sql_hash = $sql_hash; 锁定发生跳变的计划后，找出其plan_hash，并利用系统函数（DBE_SQL_UTIL.GS_SPM_ACCEPT_HISTORICAL_PLAN）接受指定时间的历史计划，或者直接使用系统函数（DBE_SQL_UTIL.GS_SPM_SET_PLAN_STATUS）来完成对应基线状态的设置，可设置为ACC/FIXED。 gaussdb=# SELECT dbe_sql_util.gs_spm_accept_historical_plan($sql_hash, $given_time, 'ACC'); 打开spm_enable_plan_selection完成计划快速回退。 gaussdb=# SET spm_enable_plan_selection = ON; 本特性仅支持Generic Plan。 与本特性相关的GUC参数有spm_enable_plan_history_logging，spm_enable_plan_history_logging_expired_time和spm_plan_history_reserved_percentage。 由于gs_spm_plan_history可写入记录数存在上限，因此新增GUC参数spm_plan_history_reserved_percentage用于指定gs_spm_plan_history可被占用的百分比。 快速感知和快速回退要求必须设置spm_enable_plan_capture = STORE 且 spm_enable_plan_history_logging = on。 该特性旨在解决当生成新计划时导致的计划跳变，对于智能优化器从现存的多个计划中进行最佳计划选择导致的计划变化，若未超出过期时间，则不属于新计划产生导致的计划跳变，不属于特性支持范围。

操作步骤 收集SQL中涉及到的所有表的统计信息。在数据库中，统计信息是优化器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化，从而导致性能问题。从经验数据来看，10%左右性能问题是因为没有收集统计信息。具体请参见更新统计信息。 通过查看执行计划来查找原因。如果SQL长时间运行未结束，通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出结果来，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及实际运行情况，以便更精准地定位问题原因。有关执行计划的详细介绍请参见SQL执行计划介绍。 审视和修改表定义。 针对EXPLAIN或EXPLAIN PERFORMANCE信息，定位SQL慢的具体原因以及改进措施，具体参见典型SQL调优点。 通常情况下，有些SQL语句可以通过查询重写转换成等价的，或特定场景下等价的语句。重写后的语句比原语句更简单，且可以简化某些执行步骤达到提升性能的目的。查询重写方法在各个数据库中基本是通用的。经验总结：SQL语句改写规则介绍了几种常用的通过改写SQL进行调优的方法。

调优手段之GUC参数 查询优化的主要目的是为查询语句选择高效的执行方式。 如下SQL语句: 1 2 select count(1) from customer inner join store_sales on (ss_customer_sk = c_customer_sk); 在执行customer inner join store_sales的时候，GaussDB支持Nested Loop、Merge Join和Hash Join三种不同的Join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种Join方式的执行代价，然后对比选出执行代价最小的执行计划。 正如前面所说，执行代价计算都是基于一定的模型和统计信息进行估算，当因为某些原因代价估算不能反映真实的cost的时候，我们就需要通过GUC参数设置的方式让执行计划倾向更优规划。例如：random_page_cost参数表示优化器计算一次非顺序抓取磁盘页面的开销，该参数默认值为4。当机器磁盘随机读取的速度较快时，比如SSD设备，可以将该参数的值适当调小，更改后，索引扫描的代价降低，生成计划时更倾向于选择索引扫描的方式。

调优手段之统计信息 GaussDB优化器是典型的基于代价的优化 (Cost-Based Optimization，简称CBO)。在这种优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值，以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost)，进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。这些特征值就是统计信息。从上面描述可以看出统计信息是查询优化的核心输入，准确的统计信息将帮助优化器选择最合适的查询规划，一般来说我们通过analyze语法收集整个表或者表的若干个字段的统计信息，周期性地运行ANALYZE，或者在对表的大部分内容做了更改之后马上运行它是个好习惯。 DDL可能会导致统计信息发生变化，进而导致计划跳变。当表上做了DDL操作后，应注意统计信息是否需要重新收集。