华为云用户手册

资源和成本规划 该解决方案主要部署如下资源，不同产品的花费仅供参考，实际以收费账单为准，具体请参考华为云官网价格： 表1 资源和成本规划（按需计费） 华为云服务 配置示例 每月预估花费 弹性云服务器 E CS 按需计费：2.553元/小时 区域：华北-北京四 计费模式：按需计费 规格：X86计算 | ECS | c7.2xlarge.2 | 8vCPUs | 16GiB 镜像：CentOS 7.6 64bit 系统盘：超高IO | 100GB 数据盘：超高IO | 500GB 购买量：1 2.553*24*30=1838.16元 云数据库 GeminiDB 按需计费：5.39元/小时 区域：华北-北京四 计费模式：按需计费 节点规格：geminidb.redis.large.4 | 2 vCPUs 节点数：3 存储容量：40GB 5.39 * 24 * 30 = 3880.8元 文档数据库服务 DDS 按需计费：3.6元/小时 区域：华北-北京四 实例类型：副本集 节点数：三节点 存储类型：超高IO 节点规格：通用型 性能规格：dds.mongodb.s6.xlarge.2.repset | 4 vCPUs | 8GB 存储空间：300GB 3.6* 24 * 30 = 2592 元 云数据库 RDS for MySQL 按需计费：2.82元/小时 区域：华北-北京四 计费模式：按需计费 数据库引擎：MySQL 数据库版本：8.0 实例类型：主备 存储类型：SSD云盘 性能规格：独享型 4 vCPUs | 8 GB 存储空间：300GB 购买数量：1 2.82* 24 * 30 = 2030.4元 合计 - 10341.36元

安全组规则修改（可选） 该解决方案使用22端口用来远程登录弹性云服务器 ECS，默认对该方案创建的VPC子网网段放开，请参考修改安全组规则，配置IP地址白名单，以便能正常访问服务。 该解决方案使用3306端口用来访问云数据库 RDS for MySQL ，默认对该方案创建的VPC子网网段放开，请参考修改安全组规则，配置IP地址白名单，以便能正常访问服务。 安全组实际是网络流量访问策略，包括网络流量入方向规则和出方向规则，通过这些规则为安全组内具有相同保护需求并且相互信任的云服务器、云容器、云数据库等实例提供安全保护。 如果您的实例关联的安全组策略无法满足使用需求，比如需要添加、修改、删除某个TCP端口，请参考以下内容进行修改。 添加安全组规则：根据业务使用需求需要开放某个TCP端口，请参考添加安全组规则添加入方向规则，打开指定的TCP端口。 修改安全组规则：安全组规则设置不当会造成严重的安全隐患。您可以参考修改安全组规则，来修改安全组中不合理的规则，保证云服务器等实例的网络安全。 删除安全组规则：当安全组规则入方向、出方向源地址/目的地址有变化时，或者不需要开放某个端口时，您可以参考删除安全组规则进行安全组规则删除。

Data Studio图形界面客户端 表2 Data Studio下载地址 适用操作系统 下载地址 校验文件 Windows x64 Data_Studio_8.2.x_64.zip Data_Studio_8.2.x_64.zip.sha256 Data_Studio_8.1.x_64.zip Data_Studio_8.1.x_64.zip.sha256 Data_Studio_8.0.x_64.zip Data_Studio_8.0.x_64.zip.sha256 Windows x86 Data_Studio_8.2.x_32.zip Data_Studio_8.2.x_32.zip.sha256 Data_Studio_8.1.x_32.zip Data_Studio_8.1.x_32.zip.sha256 Data_Studio_8.0.x_32.zip Data_Studio_8.0.x_32.zip.sha256

命令行客户端（包含GDS工具包） 表1 gsql下载地址 操作系统类别 适用操作系统版本 下载地址 校验文件 Microsoft Windows Microsoft Windows x86_64： Windows 7及以上。 Windows Server 2008及以上。 dws_8.1.x_gsql_for_windows.zip dws_8.1.x_gsql_for_windows.zip.sha256 dws_8.2.x_gsql_for_windows.zip dws_8.2.x_gsql_for_windows.zip.sha256 Redhat x86_64 RHEL 6.4~7.6 dws_client_8.2.x_redhat_x64.zip dws_client_8.2.x_redhat_x64.zip.sha256 dws_client_8.1.x_redhat_x64.zip dws_client_8.1.x_redhat_x64.zip.sha256 dws_client_8.0.x_redhat_x64.zip dws_client_8.0.x_redhat_x64.zip.sha256 SUSE x86_64 SLES 11.1~11.4，SLES 12.0~12.3 dws_client_8.2.x_suse_x64.zip dws_client_8.2.x_suse_x64.zip.sha256 dws_client_8.1.x_suse_x64.zip dws_client_8.1.x_suse_x64.zip.sha256 dws_client_8.0.x_suse_x64.zip dws_client_8.0.x_suse_x64.zip.sha256 Euler Kunpeng_64 EulerOS 2.0 SP8 dws_client_8.1.x_euler_kunpeng_x64.zip dws_client_8.1.x_euler_kunpeng_x64.zip.sha256 Redhat Kunpeng_64 CentOS-7.6-aarch64和NeoKylin-7.6-aarch64 (适配鲲鹏920处理器) dws_client_8.1.x_redhat_kunpeng_x64.zip dws_client_8.1.x_redhat_kunpeng_x64.zip.sha256

建议 推荐使用两个表*的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用法，显示不同详细程度的执行计划信息。常见有如下几种，关于更多用法请参见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，那么不是所有的行都会被检索到。

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格式的文件中，以便于进一步分析。

参数说明 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在语句的其它子查询中生效。

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_ LOG ICAL_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命令分析数据库。 ANALYZ命令更新所有表中数据大小以及属性等相关统计信息，该命令为轻量级，可以经常执行。如果此命令执行后性能恢复或者有所提升，则表明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成为性能瓶颈（带宽、存储、计算等）。在进行性能调优的时候，应尽量避免只能选择该策略的查询语句。 执行语句不能下推是因为语句中含有不支持下推的函数或者不支持下推的语法。一般都可以通过等价改写规避执行计划不能下推的问题。

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

调优手段之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(DWS)支持Nested Loop、Merge Join和Hash Join三种不同的Join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种join方式的执行代价，然后对比选出执行代价最小的执行计划。 正如前面所说，执行代价计算都是基于一定的模型和统计信息进行估算，当因为某些原因代价估算不能反映真实的cost的时候，就需要通过guc参数设置的方式让执行计划倾向更优规划。

优化查询性能概述 性能调优是数据库应用开发和迁移过程中的关键步骤，在整个项目实施过程中占据很大的份量。通过性能调优可以提高数据库的资源利用率，降低业务成本，还可以大大降低应用系统的运行风险，提高系统稳定性，给客户带来更大的价值。 SQL调优的唯一目的是“资源利用最大化”，即CPU、内存、磁盘IO、网络IO四种资源利用最大化。所有调优手段都是围绕资源使用开展的。所谓资源利用最大化是指SQL语句尽量高效，节省资源开销，以最小的代价实现最大的效益。比如做典型点查询的时候，可以用seqscan+filter（即读取每一条元组和点查询条件进行匹配）实现，也可以通过indexscan实现，显然indexscan可以以更小的代价实现相同的效果。 本章通过介绍性能调优最基本的数据库命令ANALYZE和EXPLAIN，来详细解读EXPLAIN展示的数据库执行计划，介绍如何通过执行计划了解数据库的执行过程、识别性能瓶颈，针对性调优。另外，通过介绍性能参数、典型应用场景、SQL诊断、SQL性能调优和SQL改写案例等性能调优的实际操作，为数据库性能调优提供全方位的参考指导。

存储层数据倾斜 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提示。

规格约束 告警字符串长度上限为2048。如果告警信息超过这个长度（例如存在大量未收集统计信息的超长表名，列名等信息）则不告警，只上报warning： WARNING, "Planner issue report is truncated, the rest of planner issues will be skipped" 如果query存在limit节点（即查询语句中包含limit），则不会上报limit节点以下的Operator级别的告警。 对于“数据倾斜”和“估算不准”两种类型告警，在某一个plan树结构下，只上报下层节点的告警，上层节点不再重复告警。这主要是因为这两种类型的告警可能是因为底层触发上层的。例如，如果在scan节点已经存在数据倾斜，那么在上层的hashagg等其他算子很可能也出现数据倾斜。

统计信息调优介绍 GaussDB(DWS)是基于代价估算生成的最优执行计划。优化器需要根据analyze收集的统计信息行数估算和代价估算，因此统计信息对优化器行数估算和代价估算起着至关重要的作用。通过ANALYZE收集全局统计信息，主要包括：pg_class表中的relpages和reltuples；pg_statistic表中的stadistinct、stanullfrac、stanumbersN、stavaluesN、histogram_bounds等。

示例 创建表t1、t2、t3： 1 2 3 create table t1(a1 int,b1 int,c1 int,d1 int); create table t2(a2 int,b2 int,c2 int,d2 int); create table t3(a3 int,b3 int,c3 int,d3 int); 原语句为： 1 explain select * from t3, (select a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 上述查询中，可以使用以下两种方式禁止子查询s1进行提升： 方式一： 1 explain select /*+ no merge(s1) */ * from t3, (select a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 方式二： 1 explain select * from t3, (select /*+ no merge */ a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 提升后效果：

操作步骤 查看阻塞的查询语句及阻塞查询的表、模式信息。 1 2 3 4 5 6 7 8 9 10 11 SELECT w.query as waiting_query, w.pid as w_pid, w.usename as w_user, l.query as locking_query, l.pid as l_pid, l.usename as l_user, t.schemaname || '.' || t.relname as tablename from pg_stat_activity w join pg_locks l1 on w.pid = l1.pid and not l1.granted join pg_locks l2 on l1.relation = l2.relation and l2.granted join pg_stat_activity l on l2.pid = l.pid join pg_stat_user_tables t on l1.relation = t.relid where w.waiting; 该查询返回线程ID、用户信息、查询状态，以及导致阻塞的表、模式信息。 使用如下命令结束相应的会话。其中，139834762094352为线程ID。 1 SELECT PG_TERMINATE_BACKEND(139834762094352); 显示类似如下信息，表示结束会话成功。 PG_TERMINATE_BACKEND ---------------------- t (1 row) 显示类似如下信息，表示用户正在尝试结束当前会话，此时仅会重连会话，而不是结束会话。 FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command The connection to the server was lost. Attempting reset: Succeeded. gsql客户端使用PG_TERMINATE_BACKEND函数终止本会话后台线程时，客户端不会退出而是自动重连。

Plan Hint实际调优案例 本节以TPC-DS标准测试的Q24的部分语句为例，在1000X，24DN环境上，说明使用plan hint进行实际调优的过程。示例如下： 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 26 27 28 29 30 31 32 33 34 35 36 select avg(netpaid) from (select c_last_name ,c_first_name ,s_store_name ,ca_state ,s_state ,i_color ,i_current_price ,i_manager_id ,i_units ,i_size ,sum(ss_sales_price) netpaid from store_sales ,store_returns ,store ,item ,customer ,customer_address where ss_ticket_number = sr_ticket_number and ss_item_sk = sr_item_sk and ss_customer_sk = c_customer_sk and ss_item_sk = i_item_sk and ss_store_sk = s_store_sk and c_birth_country = upper(ca_country) and s_zip = ca_zip and s_market_id=7 group by c_last_name ,c_first_name ,s_store_name ,ca_state ,s_state ,i_color ,i_current_price ,i_manager_id ,i_units ,i_size); 该语句的初始计划如下，运行时间110s： 该计划中，第10层算子使用broadcast性能较差，由于第11层算子估算行数为2140，比实际行数严重低估。错误行数估算主要来源于第13层算子的行数低估，根因是第13层hashjoin中，使用store_sales的(ss_ticket_number, ss_item_sk)列和store_returns的(sr_ticket_number, sr_item_sk)列进行关联，由于缺少多列相关性的估算导致行数严重低估。 2. 使用如下的rows hint进行调优后，计划如下，运行时间318s： 1 2 select avg(netpaid) from (select /*+rows(store_sales store_returns * 11270)*/ c_last_name ... 时间反而劣化了，原因是第8层hashjoin过慢引起第9层redistribute时间过慢导致，其中第9层redistribute并没有数据倾斜，hashjoin慢的原因是由于第18层redistribute后数据倾斜导致。 3. 经过实际数据查证，customer_address的两个join列的不同值数目较少，使用其进行join容易出现数据倾斜，故把customer_address放到最后进行join。使用如下的hint进行调优后，计划如下，运行时间116s： 1 2 3 4 select avg(netpaid) from (select /*+rows(store_sales store_returns *11270) leading((store_sales store_returns store item customer) customer_address)*/ c_last_name ... 发现时间基本花在了第6层redistribute算子上，需要进一步优化。 4. 由于最后一层redistribute包含倾斜，所以时间较长。为了避免倾斜，需要将item表放在最后join，由于item表的join并不能使行数减少。修改hint如下并执行，计划如下，运行时间120s： 1 2 3 4 select avg(netpaid) from (select /*+rows(store_sales store_returns *11270) leading((customer_address (store_sales store_returns store customer) item)) c_last_name ... 该计划中的redistribute问题并没有解决，因为第22层item表做了broadcast，导致与customer_address表join后的倾斜并没有被消除掉。 5. 增加如下禁止item表做broadcast的hint，使与customer_address join的表做redistribute（也可以进行join表redistribute的hint），计划如下，运行时间105s： 1 2 3 4 5 select avg(netpaid) from (select /*+rows(store_sales store_returns *11270) leading((customer_address (store_sales store_returns store customer) item)) no broadcast(item)*/ c_last_name ... 6. 发现最后一层使用单层Agg，但行数缩减较多。使用相同的hint，同时结合参数best_agg_plan=3进行双层Agg调优，最终计划如下图所示，运行时间94s，完成调优。 如果有统计信息变更引起的查询劣化，可以考虑用plan hint来调整到之前的查询计划。这里以TPCH-Q17为例，在收集default_statistics_target设置为–2的统计信息之后，计划相比于默认统计信息发生劣化。 1. 默认统计信息（default_statistics_target设置为100）的计划如下： 2. 统计信息变更（default_statistics_target设置为–2）的计划如下： 3. 经过对比，劣化的原因主要为lineitem和part表join时stream类型由BroadCast变更为Redistribute导致。可以对语句进行stream方式的hint来调整到之前的计划，例如： 父主题： 使用Plan Hint进行调优

控制台说明 CAE控制台说明如表1所示。 表1 CAE控制台说明 类别 说明 概览 提供CAE产品的整体看板信息，包含了应用健康度、CPU使用量、并发连接数、Memory使用量、流量、网络流入速率、引擎信息和最新特性等模块。 组件列表 提供组件新增、部署、升级等能力，组件是可以部署的自有包或者公共的中间件，对外提供服务。 实例列表 提供实例信息查看、实例删除及通过CloudShell登录容器功能。 组件配置 提供基于组件的中间件配置和运维管理，包括RDS数据库、 微服务引擎CSE 、环境变量、访问方式、伸缩策略、 云存储 配置，性能管理、自定义监控指标等资源的管理运维。 组件事件 用户可基于组件事件查看组件部署及运行期间发生的事件信息。 组件监控 提供组件监控功能，主要涉及上下行BPS、上下行PPS、文件系统写入/读取速率、CPU和内存使用情况等可视化实时监控。 组件日志 提供实例级别的运行日志，帮助用户定位问题。 系统设置 系统设置当前提供了云存储授权、域名配置和证书配置的能力，可查看和解绑已授权的对象存储，进行域名配置和证书配置。还提供了设置启停策略，配置监控系统和事件通知规则等能力。

操作步骤 进入企业路由器列表页面。 通过名称过滤，快速找到待创建传播的企业路由器。 您可以通过以下两种操作入口，进入企业路由器的“路由表”页签。 在企业路由器右上角区域，单击“管理路由表”。 单击企业路由器名称，并选择“路由表”页签。 在路由表列表中选择目标路由表，并在“传播”页签下，单击右侧区域的“创建传播”。 弹出“创建传播”对话框。 根据界面提示，配置传播的基本信息，如表1所示。 表1 创建传播-参数说明 参数名称 参数说明 取值样例 连接类型 必选参数。 选择连接类型，连接类型说明如下： “虚拟私有云（VPC）”：表示接入的网络实例是虚拟私有云。 “虚拟网关（VGW）”：表示接入的网络实例是云专线的VGW网关。 “VPN网关（VPN）”：接入的网络实例是 虚拟专用网络 VPN。 “对等连接（Peering）”：表示接入的网络实例是其他区域的另一个企业路由器。 “企业连接网（ECN）”：表示接入的网络实例是同区域或者不同区域的企业连接网络。 “ 云防火墙 （CFW）”连接：表示接入的网络实例是云防火墙。 关于连接更多信息，请参见连接概述。 虚拟私有云（VPC） 传播 必选参数。 在传播下拉列表中，选择待创建传播的连接。 er-attach-02 基本信息设置完成后，单击“确定”。 返回传播列表页面，可以看到创建的传播。

修订记录 发布日期 修订记录 2024-04-25 第十次正式发布。 本次变更说明如下： 根据控制台风格变化修改全文截图。 2024-03-15 第九次正式发布。 本次变更说明如下： 在创建企业路由器和在企业路由器中添加VPC连接等章节，增加标签策略说明。 2023-10-23 第八次正式发布。 本次变更说明如下： 在创建企业路由器、连接概述和删除Peering连接等章节，修改云连接中心网络的内容。 2023-08-08 第七次正式发布。 本次变更说明如下： 在连接概述、关联概述、传播概述和路由概述等章节，增加支持CFW的说明。 在在企业路由器中添加VPC连接章节，修改创建连接截图。 2023-06-30 第六次正式发布。 本次变更说明如下 在连接概述、关联概述、传播概述和路由概述等章节，增加支持ECN的说明。 2023-04-20 第五次正式发布。 本次变更说明如下： 在流日志章节，增加流日志内容。 2023-01-13 第四次正式发布。 本次变更说明如下： 在路由概述、创建静态路由和修改静态路由章节，增加黑洞路由相关说明。 2022-10-30 第三次正式发布。 本次变更说明如下： 在在企业路由器中添加VPC连接章节，修改ER接入子网的参数说明。 增加删除VPN连接章节。 在连接概述、关联概述和传播概述章节，增加VPN描述。 全文增加企业路由器控制台截图。 2022-05-31 第二次正式发布。 本次变更说明如下： 在创建企业路由器和支持审计的关键操作章节，删除企业路由器规格相关说明。 2022-03-30 第一次正式发布。

操作步骤 进入企业路由器列表页面。 通过名称过滤，快速找到待创建路由表的企业路由器。 您可以通过以下两种操作入口，进入企业路由器的“路由表”页签。 在企业路由器右上角区域，单击“管理路由表”。 单击企业路由器名称，并选择“路由表”页签。 在“路由表”页签下，单击“创建路由表”。 弹出“创建路由表”对话框。 根据界面提示，配置路由表的基本信息，如表1所示。 表1 创建路由表-参数说明 参数名称 参数说明 取值样例 名称 必选参数。 输入路由表的名称。要求如下： 长度范围为1~64位。 名称由中文、英文字母、数字、下划线（_）、中划线（-）、点（.）组成。 er-rtb-01 描述 可选参数。 你可以根据需要在文本框中输入对该路由表的描述信息。 - 标签 可选参数。 您可以在创建路由表的时候为路由表绑定标签，标签用于标识云资源，可通过标签实现对云资源的分类和搜索。 关于标签更详细的说明，请参见标签概述。 说明： 如您的组织已经设定路由表的相关标签策略，则需按照标签策略规则为路由表添加标签。标签如果不符合标签策略的规则，则可能会导致路由表创建失败，请联系组织管理员了解标签策略详情。关于标签策略的详细说明，请参见标签策略概述。 “标签键”：test “标签值”：01 基本信息设置完成后，单击“确定”。 返回路由表列表页面。 在路由表列表页面，查看路由表状态。 待状态由“创建中”变为“正常”，表示路由表创建完成。

约束与限制 当路由表为默认关联路由表或者默认传播路由表时，不支持删除。 路由表的基本信息中“默认路由关联”为“是”，说明该路由表是默认关联路由表。 路由表的基本信息中“默认路由传播”为“是”，说明该路由表是默认传播路由表。 如果需要删除默认关联路由表，需要更改企业路由器的“默认路由关联”和“默认路由传播”配置，具体请参见修改企业路由器配置。 当路由表中有关联、传播关系时，不支持删除。 删除关联，请参见删除路由表中关联的连接。 删除传播，请参见删除路由表中连接的传播。 当路由表中只有静态路由时，支持删除。因此删除前请确保该路由已不再使用。

相关操作 企业路由器创建完成后，需要为网络实例创建连接，将网络实例接入企业路由器中，并配置路由信息，常见组网的配置流程请参见企业路由器快速入门。 如果创建企业路由器时，未开启“默认路由表关联”和“默认路由表传播”功能，则连接创建完成后，需要手动执行以下操作： 在企业路由器中创建自定义路由表，具体请参见创建路由表。 在路由表中为指定连接创建关联，具体请参见创建关联将连接关联至路由表中。 在路由表中配置连接的路由信息，以下两个方法二选一： 在路由表中创建传播，具体请参见在路由表中创建连接的传播。 创建传播之后，企业路由器可以自动学习连接的路由信息，不用手动配置路由。 在路由表中创建静态路由，具体请参见创建静态路由。