华为云用户手册

处理告警事件 HSS通过暴力破解检测算法和全网IP黑名单，如果发现暴力破解主机的行为，对发起攻击的源IP进行拦截，并上报告警事件。 当接收到来源于HSS的告警事件时，请登录HSS管理控制台确认并处理告警事件。 如果您的主机被爆破成功，检测到入侵者成功登录主机，账户下所有云服务器可能已被植入恶意程序，建议参考如下措施，立即处理告警事件，避免进一步危害主机的风险。 请立即确认登录主机的源IP的可信情况。 请立即修改被暴力破解的系统账户口令。 请立即执行检测入侵风险账户，排查可疑账户并处理。 请及时执行恶意程序云查杀，排查系统恶意程序。 如果您的主机被暴力破解，攻击源IP被HSS拦截，请参考如下措施，加固主机安全。 请及时确认登录主机的源IP的可信情况。 请及时登录主机系统，全面排查系统风险。 请根据实际需求升级HSS防护能力。 请根据实际情况加固主机安全组、防火墙配置。 详情请参见HSS如何处理账户暴力破解事件？。

算子级调优介绍 一个查询语句要经过多个算子步骤才会输出最终的结果。由于个别算子耗时过长导致整体查询性能下降的情况比较常见。这些算子是整个查询的瓶颈算子。通用的优化手段是EXPLAIN ANALYZE/PERFORMANCE命令查看执行过程的瓶颈算子，然后进行针对性优化。 如下面的执行过程信息中，Hashagg算子的执行时间占总时间的：(51016-13535)/ 56476 ≈66%，此处Hashagg算子就是这个查询的瓶颈算子，在进行性能优化时应当优先考虑此算子的优化。

优化后 测试发现由于两表结果集过大，导致nestloop耗时过长，超过一小时未返回结果，因此性能优化的关键是消除nestloop，让join走更高效的hashjoin。从语义等价的角度消除any-clause，SQL改写如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 select ls_pid_cusr1,COALESCE(max(round(ym/365)),0) from ( ( SELECT ls_pid_cusr1,(current_date-bthdate) as ym FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = t2.id and t1.ls_pid_cusr1 != t2.id15 ) union all ( SELECT ls_pid_cusr1,(current_date-bthdate) as ym FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = id15 ) ) GROUP BY ls_pid_cusr1; 注意：尽量使用union all代替union。union在合并两个集合时会执行去重操作，而union all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑已确认两个集合不存在重叠，可用union all替代union以便提升性能。 优化后的SQL查询由两个等值join的子查询构成，而每个子查询都可以走更适合此场景的hashjoin。优化后的执行计划如下 优化后，从超过1个小时未返回结果优化到7s返回结果。

优化前 in-clause/any-clause是常见的SQL语句约束条件，有时in或any后面的clause都是常量，类似于： 1 2 3 4 select count(1) from calc_empfyc_c1_result_tmp_t1 where ls_pid_cusr1 in (‘20120405’, ‘20130405’); 或者 1 2 3 4 select count(1) from calc_empfyc_c1_result_tmp_t1 where ls_pid_cusr1 in any(‘20120405’, ‘20130405’); 但是也有一些如下的特殊用法： 1 2 3 4 5 SELECT ls_pid_cusr1,COALESCE(max(round((current_date-bthdate)/365)),0) FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = any(values(id),(id15)) GROUP BY ls_pid_cusr1; 其中，id、id15为p10_md_tmp_t2中的两列，“t1.ls_pid_cusr1 = any(values(id),(id15))”等价于“t1.ls_pid_cusr1 = id or t1.ls_pid_cusr1 = id15”。 因此join-condition实质上是一个不等式，这种不等值的join操作必须走nestloop，对应执行计划如下：

建议 推荐使用两个表*的hint。对于两个表的采用*操作符的hint，只要两个表出现在join的两端，都会触发hint。例如：设置hint为rows(t1 t2 * 3)，对于(t1 t3 t4)和(t2 t5 t6)join时，由于t1和t2出现在join的两端，所以其join的结果集也会应用该hint规则乘以3。 rows hint支持在单表、多表、function table及subquery scan table的结果集上指定hint。

EXPLAIN PERFORMANCE详解 在SQL调优过程中经常需要执行EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看SQL语句实际执行信息，通过对比实际执行与优化器的估算之间的差别来为优化提供依据。EXPLAIN PERFORMANCE相对于EXPLAIN ANALYZE增加了每个DN上的执行信息。 表定义如下： 1 2 CREATE TABLE tt01(c1 int, c2 int) DISTRIBUTE BY hash(c1); CREATE TABLE tt02(c1 int, c2 int) DISTRIBUTE BY hash(c2); 以如下SQL查询语句为例： 1 SELECT * FROM tt01,tt02 WHERE tt01.c1=tt02.c2; 执行EXPLAIN PERFORMANCE输出的显示执行信息分为以下8个部分： 执行计划 以表格的形式将计划显示出来，包含有11个字段，分别是：id、operation、A-time、A-rows、E-rows、E-distinct、Peak Memory、E-memory、A-width、E-width和E-costs。字段含义如下表1。 表1 执行字段说明 字段 描述 id 执行算子节点编号。 operation 具体的执行节点算子名称。 Vector前缀的算子是指向量化执行引擎算子，一般出现含有列存表的Query中。 Streaming是一个特殊的算子，它实现了分布式架构的核心数据shuffle功能，Streaming共有三种形态，分别对应了分布式结构下不同的数据shuffle功能： Streaming (type: GATHER)：作用是coordinator从DN收集数据。 Streaming (type: REDISTRIBUTE)：作用是DN根据选定的列把数据重分布到所有的DN。 Streaming (type: BROADCAST)：作用是把当前DN的数据广播给其他所有的DN。 A-time 各DN相应算子执行时间，一般DN上执行的算子的A-time是由[]括起来的两个值，分别表示此算子在所有DN上完成的最短时间和最长时间，包括下层算子执行时间。 注意：在整个计划中，除了叶子节点的执行时间是算子本身的执行时间，其余算子的执行时间均包含子节点的执行时间。 A-rows 表示相应算子输出的全局总行数。 E-rows 每个算子估算的输出行数。 E-distinct 表示hashjoin算子的distinct估计值。 Peak Memory 此算子在每个DN上执行时使用的内存峰值，[]中左侧为最小值，右侧为最大值。 E-memory DN上每个算子估算的内存使用量，只有DN上执行的算子会显示。某些场景会在估算的内存使用量后使用括号显示该算子在内存资源充足下可以自动扩展的内存上限。 A-width 表示当前算子每行元组的实际宽度，仅对于重内存使用算子会显示，包括：(Vec)HashJoin、(Vec)HashAgg、(Vec) HashSetOp、(Vec)Sort、(Vec)Materialize算子等，其中(Vec)HashJoin计算的宽度是其右子树算子的宽度，会显示在其右子树上。 E-width 每个算子输出元组的估算宽度。 E-costs 每个算子估算的执行代价。 E-costs是优化器根据成本参数定义的单位来衡量的，习惯上以磁盘页面抓取为1个单位， 其它开销参数将参照它来设置。 每个节点的开销（E-costs值）包括它的所有子节点的开销。 开销只反映了优化器关心的东西，并没有把结果行传递给客户端的时间考虑进去。虽然这个时间可能在实际的总时间里占据相当重要的分量，但是被优化器忽略了，因为它无法通过修改规划来改变。 SQL Diagnostic Information SQL自诊断信息。优化和执行过程中识别到的性能优化点，当对DML语句进行带VERBOSE属性的EXPLAIN（EXPLAIN PERFORMANCE内置自带VERBOSE属性）时，SQL自诊断信息也会输出，以辅助性能问题定位。 Predicate Information (identified by plan id) 谓词过滤这部分主要显示的是对应执行算子节点的过滤条件，即在整个计划执行过程中不会变的信息，主要是一些join条件和一些filter信息。 Memory Information (identified by plan id) 内存使用信息这部分显示的是整个计划中会将内存的使用情况打印出来的算子的内存使用信息，主要是Hash、Sort算子，包括算子峰值内存（peak memory），优化器预估的内存（estimate memory），控制内存（control memory），估算内存使用（operator memory），执行时实际宽度（width），内存使用自动扩展次数（auto spread num），是否提前下盘（early spilled），以及下盘信息，包括重复下盘次数（spill Time(s)），内外表下盘分区数（inner/outer partition spill num），下盘文件数（temp file num），下盘数据量及最小和最大分区的下盘数据量（written disk IO [min, max] ）。其中sort算子不会显示具体的下盘文件数，仅在显示排序方法时显示Disk。 Targetlist Information (identified by plan id) 这一部分显示的是每一个算子对应的输出目标列信息。 DataNode Information (identified by plan id) 这部分将各个算子的执行时间（若包含过滤及投影也会显示对应的执行时间）、CPU、buffer的使用情况全部打印出来。 算子执行信息 每个算子的执行信息都包含三个部分： dn_6001_6002/dn_6003_6004表示具体执行的节点信息，括号中的信息是实际的执行信息。 actual time表示实际的执行时间，第一个数字表示执行时进入当前算子到输出第一条数据所花费的时间，第二个数字表示输出所有数据的总执行时间。 rows表示当前算子输出数据行数。 loops表示当前算子的执行次数。需要注意，对于分区表来说，每一个分区表的扫描就是一次完整的扫描操作，当切换到下一个分区的时候，又是一次新的扫描操作。 CPU信息 每个算子执行的过程都有CPU信息，其中cyc代表的是CPU的周期数，ex cyc表示的是当前算子的周期数，不包含其子节点；inc cyc是包含子节点的周期数；ex row是当前算子输出的数据行数；ex c/r则是ex cyc/ex row得到的每条数据所用的平均周期数。 Buffer信息 buffers显示缓冲区信息，包括共享块和临时块的读和写。 共享块包含表和索引，临时块在排序和物化中使用的磁盘块。上层节点显示出来的块数据包含了其所有子节点使用的块数。 User Define Profiling 自定义信息，这一部分显示的是CN和DN、DN和DN建连的时间，以及存储层的一些执行信息。 Query Summary 这一部分主要打印总的执行时间和网络流量，包括了各个DN上初始化和结束阶段的最大最小执行时间、CN上的初始化、执行、结束阶段的时间，以及当前语句执行时系统可用内存、语句估算内存等信息。 DataNode executor start time：DN执行器开始时间，[min_node_name, max_node_name] : [min_time, max_time] DataNode executor run time：DN执行器运行时间，[min_node_name, max_node_name] : [min_time, max_time] DataNode executor end time：DN执行器结束时间，[min_node_name, max_node_name] : [min_time, max_time] Remote query poll time：接收结果时用于poll等待的时间 System available mem：系统可用内存 Query Max mem：查询最大内存 Enqueue time：入队时间 Coordinator executor start time：CN执行器开始时间 Coordinator executor run time：CN执行器运行时间 Coordinator executor end time：CN执行器结束时间 Parser runtime：解析器运行时间 Planner runtime：优化器执行时间 网络流量：stream算子发送的数据量 Query ID：查询ID Unique SQL ID：约束SQL ID Total runtime：总执行时间 A-rows和E-rows的差异体现了优化器估算和实际执行的偏差度。一般情况下两者偏差越大，则可以认为优化器生成的计划的越不可信，人工干预调优的必要性越大。 A-time中的两个值偏差越大，表明此算子的计算偏斜（在不同DN上执行时间差异）越大，人工干预调优的必要性越大。一般来说，两个相邻的算子，上层算子的执行时间包含下层算子的执行时间，但如果上层算子为stream算子，由于各线程不存在驱动关系，上层算子执行时间可能小于下层算子的执行时间，即不存在包含关系。 Max Query Peak Memory经常用来估算SQL语句耗费内存，也被用来作为SQL语句调优时运行态内存参数设置的重要依据。一般会以EXPLAIN ANALYZE或EXPLAIN PERFORMANCE的输出作为进一步调优的输入。

执行计划显示格式 GaussDB(DWS)对执行计划提供了normal、pretty、summary、run四种显示格式。通过设置GUC参数explain_perf_mode，可以显示不同格式的执行计划。 normal：代表使用默认的打印格式。图1中即为此显示格式。 图1 normal格式执行计划示例 pretty：代表使用GaussDB(DWS)改进后的新显示格式。新的格式层次清晰，计划包含了plan node id，性能分析简单直接。如图2。 图2 pretty格式执行计划示例 summary：是在pretty的基础上增加了对打印信息的分析。 run：在summary的基础上，将统计的信息输出到csv格式的文件中，以便于进一步分析。

执行计划显示信息 除了设置不同的执行计划显示格式外，还可以通过不同的EXPLAIN用法，显示不同详细程度的执行计划信息。常见有如下几种，关于更多用法请参见EXPLAIN语法说明。 EXPLAIN statement： 只生成执行计划，不实际执行。其中statement代表SQL语句。 EXPLAIN ANALYZE statement：生成执行计划，进行执行，并显示执行的概要信息。显示中加入了实际的运行时间统计，包括在每个规划节点内部花掉的总时间(以毫秒计)和它实际返回的行数。 EXPLAIN PERFORMANCE statement：生成执行计划，进行执行，并显示执行期间的全部信息。 为了测量运行时在执行计划中每个节点的开销，EXPLAIN ANALYZE或EXPLAIN PERFORMANCE会在当前查询执行上增加性能分析的开销。在一个查询上运行EXPLAIN ANALYZE或EXPLAIN PERFORMANCE有时会比普通查询明显的花费更多的时间。超支的数量依赖于查询的本质和使用的平台。 因此，当定位SQL运行慢问题时，如果SQL长时间运行未结束，建议通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出来，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及其实际的运行信息，以便更精准地定位问题原因。 执行计划中的常见关键字说明： 表访问方式 Seq Scan/CStore Scan 全表顺序扫描。最基本的扫描算子，用于行/列存表的顺序扫描。 Index Scan/CStore Index Scan 行/列存表的索引扫描。行/列存表上存在索引，条件列为索引列。 优化器决定使用两步的规划：最底层的规划节点访问一个索引，找出匹配索引条件的行的位置，然后上层规划节点真实地从表中抓取出对应行。独立地抓取数据行比顺序地读取数据的开销高很多，但是因为并非所有表的页面都被访问了，这么做实际上仍然比一次顺序扫描开销要少。使用两层规划的原因是，上层规划节点在读取索引标识出来的行位置之前，会先将它们按照物理位置排序，这样可以最小化独立抓取的开销。 如果在WHERE里面使用的好几个字段上都有索引，那么优化器可能会使用索引的AND或OR的组合。但是这么做要求访问两个索引，因此与只使用一个索引，而把另外一个条件只当作过滤器相比，这个方法未必是更优。 索引扫描可以分为以下几类，其差异在于索引的排序机制。 Bitmap Index Scan 使用位图索引抓取数据页，需要索引扫描获取位图后再到基表上扫描。 Index Scan using index_name 使用简单索引搜索，该方式表的数据行是以索引顺序抓取的，这样就令读取它们的开销更大，但是这里的行少得可怜，因此对行位置的额外排序并不值得。最常见的就是看到这种规划类型只抓取一行，以及那些要求ORDER BY条件匹配索引顺序的查询。因为那时候没有多余的排序步骤是必要的以满足ORDER BY。 表连接方式 Nested Loop 嵌套循环，适用于被连接的数据子集较小的查询。在嵌套循环中，外表驱动内表，外表返回的每一行都要在内表中检索找到它匹配的行，因此整个查询返回的结果集不能太大（不能大于10000），要把返回子集较小的表作为外表，而且在内表的连接字段上建议要有索引。 (Sonic) Hash Join 哈希连接，适用于数据量大的表的连接方式。优化器使用两个表中较小的表，利用连接键在内存中建立hash表，然后扫描较大的表并探测散列，找到与散列匹配的行。Sonic和非Sonic的Hash Join的区别在于所使用hash表结构不同，不影响执行的结果集。 Merge Join 归并连接或融合连接，是先将关联表的关联列各自做排序，然后从各自的排序表中抽取数据，到另一个排序表中做匹配。 因为Merge Join需要做更多的排序，所以消耗的资源更多，因此通常情况下执行性能差于Hash Join。 如果源数据已经被排序过，在执行融合连接时，并不需要再排序，此时Merge Join的性能优于Hash Join。 运算符 sort 对结果集进行排序。 filter EXPLAIN输出显示WHERE子句当作一个"filter"条件附属于顺序扫描计划节点。这意味着规划节点为它扫描的每一行检查该条件，并且只输出符合条件的行。预计的输出行数降低了，因为有WHERE子句。不过，扫描仍将必须访问所有 10000 行，因此开销没有降低；实际上它还增加了一些（确切的说，通过10000 * cpu_operator_cost）以反映检查WHERE条件的额外CPU时间。 LIMIT LIMIT限定了执行结果的输出记录数。如果增加了LIMIT，那么不是所有的行都会被检索到。

优化前 创建一个无局部聚簇（以下称为PCK）的列存表orders_no_pck，表定义如下： 执行以下SQL语句，查询某个点查询的执行计划： 1 2 3 4 EXPLAIN PERFORMANCE SELECT * FROM orders_no_pck WHERE o_orderkey = '13095143' ORDER BY o_orderdate; 由下图可知执行时间为48毫秒，查看Datanode Information发现filter时间为19毫秒，CUNone比例为0。

优化后 创建的列存表orders_pck。表定义如下： 使用ALTER TABLE将字段o_orderkey设置为PCK： 执行以下SQL语句，再次查询同样的点查询SQL语句的执行计划： 1 2 3 4 EXPLAIN PERFORMANCE SELECT * FROM orders_pck WHERE o_orderkey = '13095143' ORDER BY o_orderdate; 由下图可知执行时间为5毫秒，查看Datanode Information发现filter时间为0.5毫秒，CUNone比例为82。CUNone比列越高，PCK的性能收益越明显。

适用场景 支持并行的算子 计划中存在以下算子支持并行： Scan：支持行存普通表和行存分区表顺序扫描、列存普通表和列存分区表顺序扫描、HDFS内外表顺序扫描；支持GDS数据导入的外表扫描并行。以上均不支持复制表。 Join：HashJoin、NestLoop Agg：HashAgg、SortAgg、PlainAgg、WindowAgg(只支持partition by，不支持order by) Stream：Redistribute、Broadcast 其他：Result、Subqueryscan、Unique、Material、Setop、Append、VectoRow、RowToVec SMP特有算子 为了实现并行，新增了并行线程间的数据交换Stream算子供SMP特性使用。以下新增的算子可以看做Stream算子的子类： Local Gather：实现DN内部并行线程的数据汇总 Local Redistribute：在DN内部各线程之间，按照分布键进行数据重分布 Local Broadcast：将数据广播到DN内部的每个线程 Local RoundRobin：在DN内部各线程之间实现数据轮询分发 Split Redistribute：在集群跨DN的并行线程之间实现数据重分布 Split Broadcast：将数据广播到集群所有DN的并行线程 上述新增算子可以分为Local与非Local两类，Local类算子实现了DN内部并行线程间的数据交换，而非Local类算子实现了跨DN的并行线程间的数据交换。 示例说明 以TPCH Q1的并行计划为例： 在这个计划中，实现了Hdfs Scan以及HashAgg算子的并行，并且新增了Local Gather和Split Redistribute数据交换算子。 其中6号算子为Split Redistribute算子，上面标有的“dop: 4/4”表明Split Redistribute的发送端和接收端线程的并行度均为4。4号算子为Local Gather，上面标有“dop: 1/4”，该算子的发送端线程并行度为4，而接收端线程并行度为1，即下层的5号Hash Aggregate算子按照4并行度执行，而上层的1~3号算子按照串行执行，4号算子实现了DN内并行线程的数据汇总。 通过计划Stream算子上标明的dop信息即可看出各个算子的并行情况。

参数说明 global表示hint设置的配置参数在语句级别生效，不加global表示hint设置的配置参数在子查询级别生效，即仅在hint所在的子查询中生效，在该语句的其它子查询中不生效。 guc_name表示hint指定的配置参数的名称。 guc_value表示hint指定的配置参数的值。 如果hint设置的配置参数在语句级别生效，则该hint必须写在顶层查询中，而不能写在子查询中。对于UNION、INTERSECT、EXCEPT和MINUS语句，可以将在语句级别的guc hint写在参与集合运算的任意一个SELECT子句上，该guc hint设置的配置参数会在参与集合运算的每个SELECT子句上生效。 子查询提升时，该子查询上的所有guc hint会被丢弃。 如果一个配置参数既被语句级别的guc hint设置，又被子查询级别的guc hint设置，则子查询级别的guc hint在对应的子查询中生效，语句级别的guc hint在语句的其它子查询中生效。

优化建议 选取partial cluster key列。 列存表支持创建partial cluster key的类型character varying(n), varchar(n), character(n), char(n), text, nvarchar2, timestamp with time zone, timestamp without time zone, date, time without time zone, time with time zone。 数据的distinct值数量较少，这样能产生较好的过滤效果。 出现在查询where条件中，优先选取能过滤大量数据的列。 partial cluster key中设置多个列时，是先按第一个列排序，当第一个列值相同时，使用第二列比较，后续列依次类推。推荐不要超出3个列。

优化后 where条件中l_shipdate和l_quantity的distinct值数量较少且可以做min max过滤，将字段l_shipdate、l_quantity设置为PCK修改表定义如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 CREATE TABLE lineitem ( L_ORDERKEY BIGINT NOT NULL , L_PARTKEY BIGINT NOT NULL , L_SUPPKEY BIGINT NOT NULL , L_LINENUMBER BIGINT NOT NULL , L_QUANTITY DECIMAL(15,2) NOT NULL , L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL , L_DISCOUNT DECIMAL(15,2) NOT NULL , L_TAX DECIMAL(15,2) NOT NULL , L_RETURNFLAG CHAR(1) NOT NULL , L_LINESTATUS CHAR(1) NOT NULL , L_SHIPDATE DATE NOT NULL , L_COMMITDATE DATE NOT NULL , L_RECEIPTDATE DATE NOT NULL , L_SHIPINSTRUCT CHAR(25) NOT NULL , L_SHIPMODE CHAR(10) NOT NULL , L_COMMENT VARCHAR(44) NOT NULL , partial cluster key(l_shipdate, l_quantity) ) with (orientation = column) distribute by hash(L_ORDERKEY); 重新导入数据后执行查询，查看执行时间： 图3 使用partial cluster key 图4 使用partial cluster key后CU加载情况 使用partial cluster key后，5-- CStore Scan on public.lineitem的时间减少了1.2s，得益于有84个CU被过滤掉了。

审视和修改表定义 在分布式框架下，数据分布在各个DN上。一个或者几个DN的数据存在一块物理存储设备上，好的表定义至少需要达到以下几个目标： 表数据均匀分布在各个DN上，以防止单个DN对应的存储设备空间不足造成集群有效容量下降。选择合适分布列，避免数据分布倾斜可以实现该点。 表Scan压力均匀分散在各个DN上，以避免单DN的Scan压力过大，形成Scan的单节点瓶颈。分布列不选择基表上等值filter中的列可以实现该点。 减少扫描数据量。通过分区的剪枝机制可以实现该点。 尽量减少随机IO。通过聚簇/局部聚簇可以实现该点。 尽量避免数据shuffle，减小网络压力。通过选择join-condition或者group by列为分布列可以最大程度的实现这点。 从上述描述来看表定义中最重要的一点是分布列的选择。创建表定义一般遵循图 1 表定义流程所示流程。表定义在数据库设计阶段创建，在SQL调优过程中进行审视和修改。 图1 表定义流程 父主题： SQL调优指南

SQL语句出错自动重试 GaussDB(DWS)支持在SQL语句执行出错时自动重试（下文简称CN Retry）。对于来自gsql客户端、JDBC、ODBC驱动的SQL语句，在SQL语句执行失败时，CN端能够自动识别语句执行过程中的报错，并重新下发任务进行自动重试。 该功能的限制和约束如下： 功能范围限制： 仅能提高故障发生时SQL语句执行成功率，不能保证100%的执行成功。 CN Retry默认开启，开启后temp表会记录日志，关闭CN Retry后，temp表不会记录日志，因此不能在使用temp表时反复打开/关闭CN Retry开关，否则主备切换后再CN Retry会造成数据不一致。 CN Retry默认开启，开启后新创建的unlogged表会忽视unlogged关键字，建成普通表。关闭CN Retry后，unlogged表不会记录日志，因此不能在使用unlogged表时反复打开/关闭CN Retry开关，否则主备切换后再CN Retry会造成数据不一致。 在使用gds进行数据导出时，支持CN Retry。现有机制导出时会对重复文件进行检测并删除相同的文件，因此建议不要对相同的外表重复导出数据，除非确定数据目录中相同文件名的文件需要删除。 错误类型约束： SQL语句出错时能够被识别和重试的错误，仅限在错误类型列表（请参考表1）中定义的错误。 语句类型约束： 支持单语句CN Retry、存储过程、函数、匿名块。不支持事务块中的语句。 存储过程语句约束： 包含EXCEPTION的存储过程，如果在执行过程中（包含语句块执行和EXCEPTION中的语句执行）错误被抛出，可以retry，且系统内部错误发生时，retry会先于EXCEPTION被执行，而如果报错被EXCEPTION捕获则不能retry。 不支持使用全局变量的package。 不支持DBMS_JOB。 不支持UTL_FILE。 如果存储过程中有输出打印信息（如dbms_output.put_line或raise info等），则发生retry时会重复输出已打印的消息，并会在重复消息前输出“Notice：Retry triggered, some message may be duplicated.”加以提示。 集群状态约束： 仅支持DN、GTM实例故障。 CN Retry有次数限制，如果在CN Retry达到最大尝试次数（最大次数由max_query_retry_times控制）之前，集群状态无法从故障状态恢复到正常状态，那么CN Retry不能保证执行成功。 扩容时不支持CN Retry。 数据导入约束： 不支持COPY FROM STDIN语句。 不支持gsql \copy from元命令。 不支持JDBC CopyManager copyIn导入数据。 CN Retry支持的错误类型列表和对应的错误码信息见表1， 可以通过GUC参数retry_ecode_list设置CN Retry支持的错误类型列表，但不建议用户直接修改该参数，如有修改需求请联系技术工程师协助处理。 表1 CN Retry支持的错误类型列表 错误类型 错误码 备注 对端连接重置（CONNECTION_RESET_BY_PEER） YY001 TCP通信错误：Connection reset by peer（CN和DN间通信） 对端流重置（STREAM_CONNECTION_RESET_BY_PEER） YY002 TCP通信错误：Stream connection reset by peer（DN和DN间通信） 锁等待超时（LOCK_WAIT_TIMEOUT） YY003 锁超时，Lock wait timeout 连接超时（CONNECTION_TIMED_OUT） YY004 TCP通信错误，Connection timed out 查询设置错误（SET_QUERY_ERROR） YY005 SET命令发送失败，Set query 超出逻辑内存（OUT_OF_LOGICAL_MEMORY） YY006 内存申请失败，Out of logical memory 通信库内存分配（SCTP_MEMORY_ALLOC） YY007 SCTP通信错误，Memory allocate error 无通信库缓存数据（SCTP_NO_DATA_IN_BUFFER） YY008 SCTP通信错误，SCTP no data in buffer 通信库释放内存关闭（SCTP_RELEASE_MEMORY_CLOSE） YY009 SCTP通信错误，Release memory close SCTP、TCP断开（SCTP_TCP_DISCONNECT） YY010 SCTP通信错误，TCP disconnect 通信库断开（SCTP_DISCONNECT） YY011 SCTP通信错误，SCTP disconnect 通信库远程关闭（SCTP_REMOTE_CLOSE） YY012 SCTP通信错误，Stream closed by remote 等待未知通信库通信（SCTP_WAIT_POLL_UNKNOW） YY013 等待未知通信库通信，SCTP wait poll unknow 无效快照（SNAPSHOT_INVALID） YY014 快照非法，Snapshot invalid 通讯接收信息错误（ERRCODE_CONNECTION_RECEIVE_WRONG） YY015 连接获取错误，Connection receive wrong 内存耗尽（OUT_OF_MEMORY） 53200 内存耗尽，Out of memory 连接失败（CONNECTION_FAILURE） 08006 GTM出错，Connection failure 连接异常（CONNECTION_EXCEPTION） 08000 连接出现错误，DN的通讯失败，Connection exception 管理员关闭系统（ADMIN_SHUTDOWN） 57P01 管理员关闭系统，Admin shutdown 关闭远程流接口（STREAM_REMOTE_CLOSE_SOCKET） XX003 关闭远程套接字，Stream remote close socket 重复查询编号（ERRCODE_STREAM_DUPLICATE_QUERY_ID） XX009 重复查询，Duplicate query id Stream查询并发更新同一行（ERRCODE_STREAM_CONCURRENT_UPDATE） YY016 Stream查询并发更新同一行，Stream concurrent update LLVM内存分配错误（ERRCODE_LLVM_BAD_ALLOC_ERROR ） CG003 内存分配错误， Allocate error LLVM致命错误（ERRCODE_LLVM_FATAL_ERROR） CG004 致命错误，Fatal error HashJoin临时文件读取错误（ERRCODE_HASHJOIN_TEMP_FILE_ERROR） F0011 临时文件读取错误，File error Buffer文件读取错误（ERRCODE_BUFFER_FILE_ERROR） F0012 文件读取错误，File error 分区个数发生变化（ERRCODE_PARTITION_NUM_CHANGED） 45003 在扫描LIST分区表时，发现此时的分区个数和优化阶段的分区个数不一致，一般出现在查询和ADD/DROP分区并发时。（此错误类型仅8.1.3及以上集群版本支持） 节点间对象SCHEMA名称不一致（ERRCODE_UNMATCH_OBJECT_SCHEMA） 42P30 对象SCHEMA名称不一致，Unmatched schema name 开启CN Retry功能需要设置如下GUC参数： 必选的GUC参数（CN和DN都需设置） max_query_retry_times CN Retry功能开启时会为临时表数据记录日志，为保证数据一致性，在使用临时表时不能切换CN Retry开关状态，保持使用临时表的会话中CN Retry开关始终处于打开状态或者关闭状态。 可选的GUC参数 cn_send_buffer_size max_cn_temp_file_size 父主题： SQL执行troubleshooting

处理步骤 通过下列的操作步骤，可以分析出查询效率异常降低的原因。 使用ANALYZE命令分析数据库。 ANALYZE命令更新所有表中数据大小以及属性等相关统计信息，该命令为轻量级，可以经常执行。如果此命令执行后性能恢复或者有所提升，则表明autovacuum未能很好的完成它的工作，有待进一步分析。 检查查询语句是否返回了多余的数据信息。 例如，如果查询语句先查询一个表中所有的记录，而只用到结果中的前10条记录。对于包含50条记录的表，查询起来是很快的；但是，当表中包含的记录达到50000条，查询效率将会有所下降。 若业务应用中存在只需要部分数据信息，但是查询语句却是返回所有信息的情况，建议修改查询语句，增加LIMIT子句来限制返回的记录数。这样至少使数据库优化器有了一定的优化空间，一定程度上会提升查询效率。 检查查询语句单独运行时是否仍然较慢。 尝试在数据库没有其他查询或查询较少的时候运行查询语句，并观察运行效率。如果效率较高，则说明可能是由于之前运行数据库系统的主机负载过大导致查询低效。此外，还可能是执行计划比较低效，但是由于主机硬件较快使得查询效率较高。 检查相同查询语句重复执行的效率。 查询效率低的一个重要原因是查询所需信息没有缓存在内存中，这可能是由于内存资源紧张，缓存信息被其他查询处理覆盖。 重复执行相同的查询语句，如果后续执行的查询语句效率提升，则可能是由于上述原因导致。

不支持下推的函数 首先介绍函数的易变性。在GaussDB(DWS)中共分三种形态： IMMUTABLE 表示该函数在给出同样的参数值时总是返回同样的结果。 STABLE 表示该函数不能修改数据库，对相同参数值，在同一次表扫描里，该函数的返回值不变，但是返回值可能在不同SQL语句之间变化。 VOLATILE 表示该函数值可以在一次表扫描内改变，因此不会做任何优化。 函数易变性可以查询pg_proc的provolatile字段获得，i代表IMMUTABLE，s代表STABLE，v代表VOLATILE。另外，在pg_proc中的proshippable字段，取值范围为t/f/NULL，这个字段与provolatile字段一起用于描述函数是否下推。 如果函数的provolatile属性为i，则无论proshippable的值是否为t，则函数始终可以下推。 如果函数的provolatile属性为s或v，则仅当proshippable的值为t时，函数可以下推。 random如果出现CTE中，也不下推。因为这种场景下下推可能出现结果错误。 对于用户自定义函数，可以在创建函数的时候指定provolatile和proshippable属性的值，详细请参考CREATE FUNCTION。 对于函数不能下推的场景： 如果是系统函数，建议根据业务等价替换这个函数。 如果是自定义函数，建议分析客户业务场景，看函数的provolatile和proshippable属性定义是否正确。

语句下推介绍 目前，GaussDB(DWS)优化器在分布式框架下制定语句的执行策略时，有三种执行计划方式：生成下推语句计划、生成分布式执行计划、生成发送语句的分布式执行计划。 下推语句计划：指直接将查询语句从CN发送到DN进行执行，然后将执行结果返回给CN。 分布式执行计划：指CN对查询语句进行编译和优化，生成计划树，再将计划树发送给DN进行执行，并在执行完毕后返回结果到CN。 发送语句的分布式执行计划：上述两种方式都不可行时，将可下推的查询部分组成查询语句（多为基表扫描语句）下推到DN进行执行，获取中间结果到CN，然后在CN执行剩下的部分。 在发送语句的分布式执行计划策略中，要将大量中间结果从DN发送到CN，并且要在CN运行不能下推的部分语句，会导致CN成为性能瓶颈（带宽、存储、计算等）。在进行性能调优的时候，应尽量避免只能选择该策略的查询语句。 执行语句不能下推是因为语句中含有不支持下推的函数或者不支持下推的语法。一般都可以通过等价改写规避执行计划不能下推的问题。

优化后 将查询中的关联条件作为分布键，执行下列语句修改b作为t2的分布列： 1 ALTER TABLE t2 DISTRIBUTE BY HASH (b); 将表t2的分布列改为b列之后，执行计划将不再包含“Streaming(type: REDISTRIBUTE)”，减少了DN之间存在的通信数据量的同时，执行时间也从8.7毫秒降低至2.7毫秒，从而提升查询性能，如图2所示。 图2 选择合适的分布列案例（二）

优化前 将a作为t1和t2的分布列，表定义如下： 1 2 CREATE TABLE t1 (a int, b int) DISTRIBUTE BY HASH (a); CREATE TABLE t2 (a int, b int) DISTRIBUTE BY HASH (a); 执行如下查询： 1 SELECT * FROM t1, t2 WHERE t1.a = t2.b; 则执行计划存在“Streaming(type: REDISTRIBUTE)”，即DN根据选定的列把数据重分布到所有的DN，这将导致DN之间存在较大通信数据量，如图1所示。 图1 选择合适的分布列案例（一）

概述 GaussDB(DWS)实现基于query_band的负载识别和队列内优先级控制，一方面提供了更为灵活的负载识别手段，可根据作业类型、应用名称、脚本名称等识别负载队列，使用户根据业务场景可灵活配置query_band识别队列；另一方面实现了队列内作业下发优先级控制，后续将逐步实现队列内资源优先级控制。 管理员用户可根据业务场景及作业类别配置query_band所关联队列及估算内存限制等实现更为灵活的负载控制与资源管控。如果业务未配置query_band或用户未将query_band关联行为时，作业会默认使用用户关联队列和队列内优先级。

示例 设置query_band“JobName=abc”关联资源池p1、队列内优先级Rush、次序为1。 1 2 3 4 5 SELECT * FROM gs_wlm_set_queryband_action('JobName=abc','respool=p1;priority=rush',1); gs_wlm_set_queryband_action ----------------------------- t (1 row) 修改query_band“JobName=abc”的关联资源池为p2。 1 2 3 4 5 SELECT * FROM gs_wlm_set_queryband_action('JobName=abc','respool=p2'); gs_wlm_set_queryband_action ----------------------------- t (1 row) 修改query_band“JobName=abc”的队列内优先级为High。 1 2 3 4 5 SELECT * FROM gs_wlm_set_queryband_action('JobName=abc','priority=high'); gs_wlm_set_queryband_action ----------------------------- t (1 row) 修改query_band“JobName=abc”的次序为3。 1 2 3 4 5 SELECT * FROM gs_wlm_set_queryband_order('JobName=abc',3); gs_wlm_set_queryband_order ----------------------------- t (1 row) 查询query_band关联的负载行为。 1 2 3 4 5 6 SELECT * FROM pg_queryband_action; qband | respool_id | respool | priority | qborder --------------+------------+---------+----------+--------- AppName=test | 16974 | p1 | low | -1 JobName=abc | 17119 | p2 | high | 1 (2 rows)

query_band支持的负载行为 query_band是一个session级别的GUC参数，作为作业标识符本身没有特殊含义，数据类型为字符型，支持赋值任何字符串。但是为方便区分和设置，query_band负载识别仅支持识别键值对形式的query_band，示例： SET query_band='JobName=abc;AppName=test;UserName=user'; 其中，‘JobName=abc’，‘AppName=test’以及‘UserName=user’都是一个独立的键值对。query_band键值对规格： query_band使用键值对方式设置，即'key=value'；session内支持设置多个query_band键值对，多个键值对之间使用分号分隔。query_band键值对和query_band参数值长度的上限均为1024个字符。 query_band键值对支持的有效字符包括：数字0~9、大写字母A~Z、小写字母a-z、'.'、'-'、'_' 以及'#'。 query_band负载识别以键值对为单位设置和识别负载行为，目前支持的负载行为，如表1所示： 表1 QUERY_BAND支持负载行为 类别 行为 行为表现 负载管理(workload) 资源池(respool) query_band关联资源池 负载管理(workload) 优先级(priority) 队列内优先级 次序(order) 队列（respool） 目前为无效字段，主要用于后续扩展。 query_band搜索次序 其中，行为类别用于负载行为归类，不同的负载行为可能属于同一个类别，比如资源池和优先级同属于负载管理类别；负载行为代表query_band键值对关联的是哪种负载行为；行为表现用于记录具体的负载行为是什么；负载类别中的次序用于标记query_band负载行为识别的优先级，一个session内设置多个query_band键值对时，优先使用次序较小的query_band键值对识别负载行为。每一个query_band键值对都可以对应0个或多个负载行为，但是一种负载行为只能关联一个。query_band负载行为详细说明如下： 资源池：query_band支持关联资源池，作业执行时，若query_band指定了资源池，则使用query_band关联的资源池，否则使用用户关联的资源池。 query_band关联资源池时，资源池不存在报错退出，关联失败。 query_band关联资源池时，记录query_band与资源池依赖关系。 query_band关联资源池删除时，提示有query_band依赖，资源池删除失败。 队列内优先级：query_band支持关联作业优先级，支持高中低(High/Medium/Low)三个优先级，同时提供Rush作为特殊优先级（绿色通道），默认优先级为Medium。正常实践过程中，大部分作业使用Medium优先级，优先级较低作业使用Low优先级，特权作业使用High优先级，High作业不建议过多。Rush优先级作为特殊场景下应急使用，平时不建议使用。 队列内优先级实现队列内排队优先级： 静态负载管理场景下，CN并发不足时，触发CN全局队列排队，CN全局队列为优先级队列。 动态负载管理场景下，DN内存不足时，触发CCN全局队列排队，CCN全局队列为优先级队列。 资源池并发或内存不足时，触发资源池排队，资源池队列为优先级队列。 以上优先级队列均遵守以下调度规则： 优先级高作业优先调度。 优先级高作业全部调度完之后调度优先级低作业。 动态负载管理场景下，CN全局队列不支持query_band优先级。 次序：支持设置query_band识别次序，未设置识别次序的使用默认次序-1。除默认次序外，不存在次序相同的两个query_band。设置次序时对query_band次序进行校验，存在相同次序时，已存在次序递归+1直到不存在相同次序为止。 session内设置多个query_band键值对时，使用次序较小的query_band键值对作为负载识别的query_band。 次序最小为0，默认次序-1为最大次序。 次序都为默认次序时，使用设置靠前的query_band作为负载识别的query_band。 示例：set query_band='b=1;a=3;c=1'; b=1，其中b=1次序-1，a=3次序4，c=1次序1，则使用c=1作为负载识别的query_band，此设计可提供负载管理员对负载调度调整能力。

场景二：优化后 在以上查询中，supplier、lineitem、partsupp三表做hashjoin的条件为(lineitem.l_suppkey = supplier.s_suppkey) AND (lineitem.l_partkey = partsupp.ps_partkey)，此hashjoin条件中存在两个过滤条件，这前一个过滤条件中的lineitem.l_suppkey和后一个过滤条件中的lineitem.l_partkey同为lineitem表的两列，这两列存在强相关的关联关系。在这种情况，估算hashjoin条件的选择率时，如果使用cost_param的bit1为0时，实际是将AND的两个过滤条件分别计算的2个选择率的值相乘来得到hashjoin条件的选择率，导致行数估算不准确，查询性能较差。所以需要将cost_param的bit1为1时，选择最小的选择率作为总的选择率估算行数比较准确，查询性能较好，优化后的计划如下图所示：

场景二：优化前 当cost_param的bit1（set cost_param=2）为1时，表示求多个过滤条件（Filter）的选择率时，选择最小的作为总的选择率，而非两者乘积，此方法在过滤条件的列之间关联性较强时估算更加准确。下面查询的例子是cost_param的bit1为1时的优化场景。 表结构如下所示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 CREATE TABLE NATION ( N_NATIONKEYINT NOT NULL , N_NAMECHAR(25) NOT NULL , N_REGIONKEYINT NOT NULL , N_COMMENTVARCHAR(152) ) distribute by replication; CREATE TABLE SUPPLIER ( S_SUPPKEYBIGINT NOT NULL , S_NAMECHAR(25) NOT NULL , S_ADDRESSVARCHAR(40) NOT NULL , S_NATIONKEYINT NOT NULL , S_PHONECHAR(15) NOT NULL , S_ACCTBALDECIMAL(15,2) NOT NULL , S_COMMENTVARCHAR(101) NOT NULL ) distribute by hash(S_SUPPKEY); CREATE TABLE PARTSUPP ( PS_PARTKEYBIGINT NOT NULL , PS_SUPPKEYBIGINT NOT NULL , PS_AVAILQTYBIGINT NOT NULL , PS_SUPPLYCOSTDECIMAL(15,2)NOT NULL , PS_COMMENTVARCHAR(199) NOT NULL )distribute by hash(PS_PARTKEY); 查询语句如下所示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 set cost_param=2; explain verbose select nation, sum(amount) as sum_profit from ( select n_name as nation, l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount from supplier, lineitem, partsupp, nation where s_suppkey = l_suppkey and ps_suppkey = l_suppkey and ps_partkey = l_partkey and s_nationkey = n_nationkey ) as profit group by nation order by nation; 当cost_param的bit1为0时，执行计划如下图所示：

存储层数据倾斜 GaussDB(DWS)数据库中，数据分布存储在各个DN上，通过分布式执行提高查询的效率。但是，如果数据分布存在倾斜，则会导致分布式执行某些DN成为瓶颈，影响查询性能。这种情况通常是由于分布列选择不合理，可以通过调整分布列的方式解决。 例如下例： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 explain performance select count(*) from inventory; 5 --CStore Scan on lmz.inventory dn_6001_6002 (actual time=0.444..83.127 rows=42000000 loops=1) dn_6003_6004 (actual time=0.512..63.554 rows=27000000 loops=1) dn_6005_6006 (actual time=0.722..99.033 rows=45000000 loops=1) dn_6007_6008 (actual time=0.529..100.379 rows=51000000 loops=1) dn_6009_6010 (actual time=0.382..71.341 rows=36000000 loops=1) dn_6011_6012 (actual time=0.547..100.274 rows=51000000 loops=1) dn_6013_6014 (actual time=0.596..118.289 rows=60000000 loops=1) dn_6015_6016 (actual time=1.057..132.346 rows=63000000 loops=1) dn_6017_6018 (actual time=0.940..110.310 rows=54000000 loops=1) dn_6019_6020 (actual time=0.231..41.198 rows=21000000 loops=1) dn_6021_6022 (actual time=0.927..114.538 rows=54000000 loops=1) dn_6023_6024 (actual time=0.637..118.385 rows=60000000 loops=1) dn_6025_6026 (actual time=0.288..32.240 rows=15000000 loops=1) dn_6027_6028 (actual time=0.566..118.096 rows=60000000 loops=1) dn_6029_6030 (actual time=0.423..82.913 rows=42000000 loops=1) dn_6031_6032 (actual time=0.395..78.103 rows=39000000 loops=1) dn_6033_6034 (actual time=0.376..51.052 rows=24000000 loops=1) dn_6035_6036 (actual time=0.569..79.463 rows=39000000 loops=1) 在performance信息中，可以看到inventory表各DN的scan行数，发现各DN的行数差距较大，最大的为63000000，最小的只有15000000，差了4倍。这个差距对于数据扫描的性能影响还可以接受，但如果上层有join算子，则影响较大。 通常，数据表在各DN上是hash分布的，因此分布列的选择很重要。通过table_skewness()来查看上述inventory表在各DN的数据分布倾斜，查询结果如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 select table_skewness('inventory'); table_skewness ------------------------------------------ ("dn_6015_6016 ",63000000,8.046%) ("dn_6013_6014 ",60000000,7.663%) ("dn_6023_6024 ",60000000,7.663%) ("dn_6027_6028 ",60000000,7.663%) ("dn_6017_6018 ",54000000,6.897%) ("dn_6021_6022 ",54000000,6.897%) ("dn_6007_6008 ",51000000,6.513%) ("dn_6011_6012 ",51000000,6.513%) ("dn_6005_6006 ",45000000,5.747%) ("dn_6001_6002 ",42000000,5.364%) ("dn_6029_6030 ",42000000,5.364%) ("dn_6031_6032 ",39000000,4.981%) ("dn_6035_6036 ",39000000,4.981%) ("dn_6009_6010 ",36000000,4.598%) ("dn_6003_6004 ",27000000,3.448%) ("dn_6033_6034 ",24000000,3.065%) ("dn_6019_6020 ",21000000,2.682%) ("dn_6025_6026 ",15000000,1.916%) (18 rows) 通过查询建表定义，可以发现，目前该表是以inv_date_sk作为分布列的，导致存在倾斜。通过查看各列的数据分布情况，改为inv_item_sk作为分布列，则倾斜情况分布如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 select table_skewness('inventory'); table_skewness ------------------------------------------ ("dn_6001_6002 ",43934200,5.611%) ("dn_6007_6008 ",43829420,5.598%) ("dn_6003_6004 ",43781960,5.592%) ("dn_6031_6032 ",43773880,5.591%) ("dn_6033_6034 ",43763280,5.589%) ("dn_6011_6012 ",43683600,5.579%) ("dn_6013_6014 ",43551660,5.562%) ("dn_6027_6028 ",43546340,5.561%) ("dn_6009_6010 ",43508700,5.557%) ("dn_6023_6024 ",43484540,5.554%) ("dn_6019_6020 ",43466800,5.551%) ("dn_6021_6022 ",43458500,5.550%) ("dn_6017_6018 ",43448040,5.549%) ("dn_6015_6016 ",43247700,5.523%) ("dn_6005_6006 ",43200240,5.517%) ("dn_6029_6030 ",43181360,5.515%) ("dn_6025_6026 ",43179700,5.515%) ("dn_6035_6036 ",42960080,5.487%) (18 rows) 数据分布倾斜的问题得到解决。 除了table_skewness()视图外，当前版本还提供了table_distribution函数和PGXC_GET_TABLE_SKEWNESS视图，可以更加高效的查询各表的数据倾斜情况。

示例 对示例中原语句使用如下hint： 1 2 explain select /*+ no redistribute(store_sales store_returns item store) leading(((store_sales store_returns item store) customer)) */ i_product_name product_name ... 原计划中，(store_sales store_returns item store)和customer做join时，前者做了重分布，此hint表示禁止前者混合表做重分布，但仍然保持join顺序，则生成计划如下所示：

建议 通常优化器会根据统计信息选择一组不倾斜的分布键进行数据重分布。当默认选择的分布键有倾斜时，可以手动指定重分布的列，避免数据倾斜。 在选择分布键的时候，通常要根据数据分布特征选取一组distinct值比较高的列作为分布列，这样可以保证重分布后，数据均匀的分布到各个DN。 在编写好hint后，可以通过explain verbose+SQL打印执行计划，查看指定的分布键是否有效，如果指定的分布键无效会有warning提示。

更多优化示例 示例1：修改基表为REPLICATION表，并且在过滤列上创建索引。 1 2 3 create table master_table (a int); create table sub_table(a int, b int); select a from master_table group by a having a in (select a from sub_table); 上述事例中存在一个相关性子查询，为了提升查询的性能，可以将sub_table修改为一个REPLICATION表，并且在字段a上创建一个index。