Greenplum数据库设计开发规范[技术学习].doc

《Greenplum数据库设计开发规范[技术学习].doc》由会员分享，可在线阅读，更多相关《Greenplum数据库设计开发规范[技术学习].doc（24页珍藏版）》请在三一文库上搜索。

1、互联网络 0 0 目目 录录 第一章第一章前言前言 .2 1.1文档目的.2 1.2预期读者.2 1.3参考资料.2 第二章第二章设计规范设计规范.3 2.1数据库对象数量.3 2.2表创建规范.3 2.3表结构设计.4 2.3.1字段命名.4 2.3.2数据类型.4 2.3.3数据分布.5 2.3.4分区.7 2.3.5压缩存储.8 2.3.6索引设计.9 2.4其他数据库对象设计.10 2.4.1schema.10 2.4.2视图.11 2.4.3临时表和中间表 .11 第三章第三章SQL 开发规范开发规范.12 3.1基本要求.12 3.2WHERE 条件.12 3.3分区字段使用.13

2、 3.4表关联.13 3.5排序语句.16 3.6嵌套子查询.16 3.7UNION / UNION ALL.16 互联网络 1 1 3.8高效 SQL 写法的建议.18 互联网络 2 2 第一章第一章前言前言 1.1 文档目的文档目的 随着 Greenplum 数据库的正式上线使用。为了保证 Greenplum 数据仓库 系统平台的平稳运行，保证系统的可靠性、稳定性、可维护性和高性能。特制 定本开发规范，以规范基于 Greenplum 数据库平台的相关应用开发，提高开发 质量。 1.2 预期读者预期读者 Greenplum 数据仓库平台应用的设计与开发人员； Greenplum 数据仓库平台

3、的系统管理人员和数据库管理员； Greenplum 数据仓库平台的运行维护人员； 1.3 参考资料参考资料 参考 Greenplum4.3.x 版本官方指引： GPDB43AdminGuide.pdf GPDB43RefGuide.pdf GPDB43UtilityGuide.pdf 互联网络 3 3 第二章第二章设计规范设计规范 2.1 数据库对象数量数据库对象数量 数据库对象类型包括数据表、视图、函数、序列、索引等等，在 Greenplum 数据库中，系统元数据同时保存在 Master 服务器和 Segment 服务 器上，过多的数据库对象会造成系统元数据的膨胀，而过多的系统元数据造成 系

4、统运行逐步变慢；同时，类似数据库的备份、恢复、扩容等较大型的操作都 导致效率变慢。因此，依据 GreenplumDB 产品的最佳时间，单个数据库的对 象数量，应控制在 10 万以内。 GP 数据库的对象包括：表、视图、索引、分区子表、外部表等。 如果数据表的数量太多，建议按应用域进行分库，尽量将单个数据库的表 数量控制在 10 万以内，可以在一个集群中创建多个数据库。 【备注】：在 Greenplum 数据库中，一张分区表，在数据库中存储为一张 父表、每张分区子表都是一张独立的库表；例如：一张按月进行分区的存储一 年数据的表，如果含默认分区，共 14 张表。 2.2 表创建规范表创建规范 为了

5、避免数据库表数量太多，避免单个数据表的数据量过大，给系统的运 行和使用带来困难，在 Greenplum 数据库中需遵循如下的表创建规范： 1、GP 系统表中保存的表名称都是以小写保存。通常 SQL 语句中表名对 大小写不敏感。但不允许在建表语句中使用双引号（“” ）包括表名，这样会影 响系统表中存储的名称，使得表名存在大小写或特殊字符。表命名也不允许出 现中文字。 2、单个数据库的数据表数量建议不要超过 10 万张； 3、禁止使用二级分区表，因为二级分区表会造成表对象数量的急剧膨胀； 互联网络 4 4 4、由于过多的数据文件会导致操作系统对文件的操作效率降低，直接影响 到数据库的管理效率。如果

6、数据文件数量过多，建议增加多个表空间，把数据 表均匀分布到不同的表空间。每个表空间目录下的数据文件数量，应控制在 80 万以内。文件数统计可以直接到某个 Segment 实例目录下指定的表空间目录下 统计。 5、创建数据表（DDL）的时候（不含临时表和程序中使用的中间表） ，必 须使用 tablespace 子句指定用于存储的表空间，而不是把所有表都存储在默认 表空间；例如： Create table employee ( id int,name varchar) TABLESPACETABLESPACE tpc_data_01tpc_data_01 distributed by (id);

7、6、对于数据量超过 1TB 的大表,需从应用设计方面，考虑对大表进行优化， 例如是否可划分为历史数据表和当前数据表，并分开存放；是否应采用压缩存 储节省空间；是否合理分区；是否应定期清理数据等等。 2.3 表结构设计表结构设计 2.3.1字段命名字段命名 表字段的命名，与表名类似。在 GP 系统表中保存的表名称都是以小写保 存。通常 SQL 语句中字段名称对大小写不敏感。但不允许在建表语句中使用双 引号（“” ）包括字段名，这样会影响系统表中存储的名称，使得表名存在大小 写或特殊字符。字段命名也不允许出现中文字。 2.3.2数据类型数据类型 数据类型的定义与相关数据的加载和使用紧密相关，数据类

8、型的定义决定 了数据所占用的空间大小，因此，必须慎重设计 GP 数据仓库数据表的字段类 型。 数据仓库的数据来自于多个异构的业务应用系统，通常情况下，业务应用 互联网络 5 5 系统的字段类型选择较为随意，不同的业务系统数据类型定义存在多样化，彼 此之间差异较大；因此，在数据仓库中，需在参考源系统字段类型定义的情况 下，结合 Greenplum 数据仓库平台的特点和要求，对字段数据类型进行设计。 Greenplum 数据库的数据类型定义需遵循以下原则： 1、在满足业务需求的条件下，尽可能选择空间占用最小的数据类型；以节 省数据存储空间； 2、在 GP 系统中，CHAR、VARCHAR 和 TE

9、XT 之间不存在性能差异，在 其他的 DB 系统中，可能 CHAR 会表现出最好的性能，但在 GPDB 中是不存在 这种性能优势的。在多数情况下，应该选择使用 VARCHAR 而不是 CHAR； 3、定长字符串类型使用 varchar,而不使用 char. 4、对于数值类型来说，应该尽量选择更小的数据类型来适应数据；比如， 选择 BIGINT 类型来存储 SMALLINT 类型范围内的数值，会造成空间的大量浪 费。 5、用来做 Table Join 的 Column 来说，应该考虑选择相同的数据类型。 如果做 Join 的 Column 具有相同的数据类型(比如主键 PrimaryKey 与外

10、键 ForeignKey)，其工作效率会更高。 6、一般情况下，应尽量使用上述规范数据类型，避免出现诸如： Address，INET，ARRAY 等特殊类型字段。 2.3.3数据分布数据分布 基于 Greenplum 数据仓库平台的特点，每张数据表都必须指定分布键 DK，Greenplum 数据库根据数据分布键（Distributed Key,简称 DK，后同）值 来决定记录存储在哪一个 segment 上，DK 不仅决定了数据在集群节点上的分 布，还严重影响数据查询和处理操作的执行效率，需要非常慎重的选择数据表 的分布键。对于 Greenplum 数据仓库平台，DK 的选择需要遵循以下原则：

11、 1、数据均匀分布原则 互联网络 6 6 为了尽可能达到最好的性能，所有的 Instance 应该尽量储存等量的数据。 若数据的分布不平衡或倾斜，那些储存了较多数据的 Instance 在处理自己那部 分数据时将需要耗费更多的工作量。为了实现数据的平坦分布，可以考虑选择 具有唯一性的 DK，如主键。 2、本地操作原则 在处理查询时，很多处理如关联、排序、聚合等若能够在 Instance 本地完 成，其效率将远高于跨越系统级别(需在 Instance 之间交叉传输数据)的操作。 当不同的 Table 使用相同的 DK 时，在 DK 上的关联或者排序操作将会以最高 效的方式把绝大部分工作在 Ins

12、tance 本地完成。 3、均衡的查询负载原则 在一个查询正被处理时，我们希望所有的 Instance 都能够处理等量的工作 负载，从而尽可能达到最好的性能。通过合理的 DK 设计，尽量使得查询处理 的负载均匀分布在每个节点上，并且尽量保证 where 条件产生的结果集在各个 节点上也是均匀的。 4、关联一致原则 当表于表之间存在关联时，各表应选择相同字段作为 DK，并且做关联查 询时，使用 DK 作为连接字段，尽可能使连接包含全部 DK 字段； 5、DK 一致原则 总分父子表的 DK 应保持一致；中间过程表、临时表的 DK 应尽可能保持 和源表的 DK 一致； 6、DK 精简原则 DK 字段

13、不宜过多，DK 字段越少越好。 基于以上原则，Greenplum 数据仓库平台的数据表 DK 设计规范如下： 每个数据表必须通过 Distribiuted 子句显式指定分布键，不允许使用默 认 DK 的方式创建数据表； 分布键字段原则上为 1 个，应尽量不要超过 3 个； 分区的父子表的分布键应完全一致； 互联网络 7 7 中间过程表、临时表、派生表的 DK 应尽可能保持和源表一致； 具有关联关系的数据表，应尽可能使用关联字段作为分布键； 分布键字段不可执行 Update 操作； 为了保证数据分布均匀，在没有合适字段作为分布键的情况下，应选择 数据表的主键作为分布键； 对于没有逻辑主键，又没有

14、其他合适字段作为分布键的数据表，才建议 设置其分布策略为 Distributed Randomly， 这只应该为最后的选择； 随机分布的适合使用场景：查询时不需要和其它表关联、或只与小表关 联的数据表，使用随机分布策略。 2.3.4分区分区 表分区用以解决特别大的表的问题，分区表在执行给定的查询语句时，扫 描相关的部分数据而不是全表的数据从而提高查询性能。分区表对于数据库的 管理也有帮助。并不是任何数据表都适合做分区，应从如下几个方面判断是否 应进行分区： 1、表是否足够大？ 只有非常大的事实表才适合做表分区。若在一张表中有数亿条记录，从逻 辑上把表分成较小的分区将可以改善性能。而对于只有数万

15、条或者更少记录的 表，对分区预先进行的管理开销将远大于可以获得的性能改善。 2、对目前的性能不满意？ 作为一种调优方案，应该在查询性能低于预期时再考虑表分区。 3、查询条件是否能匹配分区条件？ 检查查询语句的 WHERE 条件是否与考虑分区的 COLUMN 一致。例如， 如果大部分的查询使用日期条件，那么按照月或者周的日期分区设计也许很有 用，而如果查询条件更多的是使用地区条件，可以考虑使用地区将表做列表类 型的分区。 4、按照某个规则数据是否可以被均匀的分拆？ 互联网络 8 8 应该选择尽量把数据均匀分拆的规则。若每个分区储存的数据量相当，那 么查询性能的改善将与分区的数量相关。例如，把一张

16、表分为 10 个分区，命中 单个分区条件的查询扫表性能将比未分区的情况下高 10 倍。 如果以上几个方面的回答都是 Yes，这样的表可以通过分区策略来提高查 询性能。如上面章节所述，在 Greenplum 中，每个分区子表都对应一张独立 的数据表，系统通过父子表之间的继承关系来维护分区定义信息。如果过多的 数据表进行了分区，会造成表对象数量过多，系统元数据急剧膨胀，给系统的 运行和维护带来很大负担。因此，还要综合考虑系统的表数据量情况，才可决 定是否对数据表进行分区。 基于以上原则，Greenplum 数据库数据分区的使用规范如下： 在性能可以满足的情况下，尽量不使用数据分区； 因会造成表对象

17、数量过多，增加执行计划生成的复杂性，禁止使用二级 分区； 数据量在亿级别以下，建议不要使用分区； 表的数据在单个实例的数据量在 100 万级别以下，不需要分区； 分区字段不可以 UPDATE，需要用 delete + insert 或者 truncate + insert 替代实现。 2.3.5压缩存储压缩存储 Greenplum 数据表分两种类型：heap 表和 AO 表（Append-optimized） 。 在 Greenplum 数据库中，需要对数据进行压缩，数据表则需要设置为 AO 表。 对数据表进行压缩，可以减少磁盘占用空间，同时也减少了对 IO 资源的开销 （以 CPU 资源换

18、IO 资源） 。特别是在目前 IO 资源不足的硬件环境下，数据库 设计应该尽可能多的使用 AO 表。建议在选择压缩储存模式时，最好根据比较 测试的结果来确定。 互联网络 9 9 综合以上考虑，数据表压缩的设计规范如下： 数据量在百万级以下的小表，不建议使用压缩存储； 不要在压缩文件系统使用压缩存储； 压缩表建议统一使用 zlib 压缩算法，压缩级别为 6 (appendonly=true, compresstype=zlib, compresslevel=6);，此压缩设置满足大多数的使 用场景。 建议对数据仓库中的记录数超过 1 亿的事实表、历史数据表采用压缩存 储； 所有历史数据表、备份表

19、、归档表统一使用压缩存储； 2.3.6索引设计索引设计 在分布式数据库 GPDB 中，应尽量避免使用索引。GPDB 中大部分应用场 景是使用顺序扫描。与传统的 OLTP 数据库不同的是，Greenplum 中数据表的 数据是分布在多个节点上的。这意味着每个节点都扫描全部数据的一小部分来 查找结果。如果使用了表分区，扫描的数据可能更少。通常，这种情况下使用 索引未必能提升性能。 索引更易于改善 OLTP 类型的工作负载，因其返回很少量的数据，当情况 合适时查询优化器会把索引作为获取数据的选择，而不是一味的全表扫描。添 加索引会带来一些数据库开销，其必定占用相当的存储空间，并且表更新时需 维护索引

20、。需确保索引的创建在查询工作负载中真正被使用到。同时，需要检 查索引的确对于查询性能有显著的改善(与顺序扫描的性能相比)。 Greenplum 支持 B-tree 索引和位图（Bitmap）索引。因此，使用索引时， 需要综合考虑以下问题： 1、查询工作负载类型：索引更适合于 OLTP 类型的工作负载，其返回很 少量的数据，对于 OLAP 类型的查询负载，在 GPDB 中索引通常作用不大； 2、压缩表：在查询少量数据的情况下，索引能够改善 AO 表上的查询性能， 当情况合适时查询优化器会把索引作为获取数据的选择，而不是一味的全表扫 互联网络 1010 描。对于压缩数据来说，索引访问数据的方法是解

21、压需要的记录而不是全部解 压； 3、避免在频繁更新的列上使用索引。在频繁更新的列上创建索引，当该列 被更新时，需要消耗大量的写磁盘资源和 CPU 计算资源； 4、在高选择性的列适合使用 B-tree 索引，选择性指的是列中 DISTINCT 值的数量除以表中的记录.例如，如果一张表中有 1000 行记录且有 800 个 DISTINCT 值，选择性指数为 0.8，这被认为是良好的。唯一索引总是具备 1.0 的选择比，这是最好的情况； 5、低选择性的列适合使用 bitmap 索引； 6、索引列用于关联。经常关联(JOIN)的 COLUMN(比如外键)上建立索引 或许可以改善 JOIN 的性能，因

22、为其可以帮助查询规划器使用其他的关联方法； 7、索引列经常用在查询条件中。对于大表来说，查询语句 WHERE 条件 中经常用到的列，可以考虑使用索引。 综合以上情况，结合 Greenplum 平台的特点，索引设计的规范如下： 原则上，数据仓库中的数据表不建立索引。只有提供给外部用户访问的 表，才考虑按用户访问特性，针对常用查询字段建立索引； 对于跑批的中间表和临时表，不允许创建索引； 对于记录数在百万级别以下的小表，建议不使用索引； 创建组合索引时，必须将经常作为查询条件且可选择性最大的列设置为 索引的首列； 不允许创建冗余索引； 对于区别度高的索引，应使用 B-tree 索引，例如账号、合同

23、号等等； 对于区别度低的索引，应使用 Bitmap 索引，例如机构、产品类型等等； 创建组合索引时，建议列数不要超过 5 列； 每张数据表的索引数，建议不超过 5 个； 互联网络 1111 在创建和更新索引后，必须执行 Analyze 操作，更新索引的统计信息； 在对大表进行数据加载的时候，如果存在索引，建议先删除索引，待数 据加载完成，再重新创建索引； 对频繁更新的数据表，应定期对其执行 reindex 操作，以重建索引； 如果在分区表中使用了索引，不允许在子表上单独创建和修改索引；通 常，删除顶级分区的索引，系统会自动删除相关子表的索引，但如果 子表的索引有缺失，将不能自动删除子表的索引，

24、需要一一手动删除。 不再使用的索引必须删除； 2.4 其他数据库对象设计其他数据库对象设计 2.4.1schema 模式(Schema)是在 DB 内组织对象的一种逻辑结构。模式可以允许用户在 一个 DB 内不同的模式之间使用相同 Name 的对象(比如 Table)。Schema 命名 不允许出现中文字。Schema 的规划与创建建议由系统管理员或应用设计人员 统一规划和设计。 不允许在系统的 Schema 下创建用户表；Greenplum 的系统 Schema 如下： 序号Schema 名称说明 1.gp_toolkit 提供系统管理方面的视图 2.Information_schema 提

25、供元数据信息的视图 3.pg_catalog 系统对象元数据表 4.pg_aoseg Append only 表的辅助元数据表 5.pg_toast 大对象存储 6.pg_bitmapindex 位图索引对象存储 2.4.2视图视图 互联网络 1212 视图的设计规范建议如下： 视图命名不允许使用双引号包括视图名，视图名称不允许出现中文字； 在视图中，不允许使用 ORDER BY 语句； 对频繁访问，具有多个大表关联，并含有复杂计算或排序的视图，建议 修改为物理表； 2.4.3临时表和中间表临时表和中间表 临时表使用规范如下： 对于每天定期执行的后台数据处理作业，建议不要使用临时表，因为使 用

26、临时表，会造成每天都进行大量的数据表的创建和删除，引起系统 元数据表的急剧膨胀，导致需要频繁的进行系统表的 Vacuum 操作， 从而影响系统的使用和稳定性。 临时表和中间表定义时必须显示指定分布键。 临时表和中间表，评估表数据量，建议大表统一采用压缩表。 互联网络 1313 第三章第三章SQL 开发规范开发规范 3.1 基本要求基本要求 1、代码行清晰、整齐、层次分明、结构性强，易于阅读； 2、代码中应具备必要的注释以增强代码的可读性和可维护性； 3、代码应充分考虑执行效率，保证代码的高效性； 3.2 WHERE 条件条件 1、在 Where 条件过滤中，应尽量将函数处理放在等式的右边，以提

27、高查 询性能； 2、对于日期（date、timestamp 等）类型的字段判断，条件值可直接使用 字符串，GP 会自动进行转换。无需过多的使用类型转换函数，如：to_date 使用： WHERE call_dt = 2015-01-01; 不需要写成： WHERE call_dt = to_date(2015-01-01,YYYY-MM-DD); 3、在条件过滤中使用函数，不需要写 select 关键字。否则会影响执行计 划的准确性： 错误示例： WHERE t.z_day = (select to_char(current_timestamp - interval 1 minute, dd)

28、 ) and t.z_hours = (select to_char(current_timestamp - interval 1 minute, HH24) ) 4、系统中很多采用日期分区的表，分区字段类型为数值型（integer） 。等 式的左边不要使用数值运算，否则会影响执行计划对分区使用的准确性。 问题示例： WHERE statis_date/100 = masadw.fn_get_l1m_yyyymm(20150423) 可改写为： WHERE statis_date between 20150401 and 20150430; 互联网络 1414 WHERE statis_dat

29、e = 20150401 and statis_date = 20150430; 5、在 WHERE 条件中错误的添加 11 的判断，会导致执行计划混乱。 问题语句： SELECT 20141130:INT as static_date, B.DVLPER_CODE, A.CNTY_ID,SUM(A.CALL_DUR)/60.0 AS CALL_DUR FROM masamk.LS_GSM_TOL_D A,masamk.IU_USR_D B WHERE 11 and A.statis_date = 20141130 AND A.USR_ID=B.USR_ID GROUP BY B.DVLPER

30、_CODE,A.CNTY_ID 3.3 分区字段使用分区字段使用 如上述章节提到的分区表的使用原则，使用分期表是为了降低每次表扫描 涉及的数据量，已达到提升 SQL 处理效率的目的。如果 SQL 语句中没有准确 的使用分区字段就会导致遍历所有分区，导致 SQL 执行效率低下。 特别在多个分区表关联时，每个分区表都需要制定分区字段的条件。除非 业务上有特殊要求必须要遍历所有的（或大部分的）子分区。 3.4 表关联表关联 1、表连接中的每个表应指定缩写的别名，别名的命名尽量清晰可辨别； 2、多表关联的时候，建议所有的关联写成 JOIN 的形式，例如： 而不允许写成如下形式： 互联网络 1515 3

31、、建议一个 SQL 语句中多表关联的关联表不要超过 10 张表； 4、几个大小差不多的表做关联时，过滤性较强的优先做 aJOIN； 5、在大/大/小三个表内关联时，避免先把两个大表进行 JOIN，除非过滤 性非常强；例如：pg_namespace 为小表，其他 2 个表为大表 6、在大/小/小三个表内联时，优先把两个小表进行 JOIN： 7、在关联大表的时候，左右两个连接表的关联字段不能同时存在高重复值 的情况，以免因重复记录关联产生巨大的中间结果，造成磁盘占用比例的大幅 增长；例如：如果一个 100 万的重复记录表和一个 1 万的重复记录表关联，结 果会高达 100 万*1 万=100 亿条

32、记录； 8、在使用小表 LEFT JOIN 超大表（记录数过亿）时，强烈建议把 LEFT JOIN 修改为先 INNER JOIN，再 LEFT JION 的方式实现。这样既可以提高 性能，也能避免 Greenplum 产生大量的临时文件；因为在 Greenplum 数据库 SELECT * FROM (smalltableA AS A INNER JOIN smalltableB AS B ON A.key=B.key) INNER JOIN bigtable AS C ON C.key=A.key 互联网络 1616 中，对于 LEFT JOIN 语句，服务器会固定使用右表的记录，构造 H

33、ash 表，然 后用 Hash Join 的方式实现关联；如果右表非常大，会导致 Hash 表需要占用 大量的内存，如果内存超出限制，系统会把 Hash 表的内容，写入到文件系统 的临时文件中，如果右表是一个超大表，可能在执行此语句的时候，系统会写 入大量临时文件，造成系统占用空间大幅增加； 如果是 INNER JOIN 语句，系统会自动选择用小表建立 Hash 表。 例如：如下 LEFT JOIN 语句： 其执行计划如下： 从执行计划可以看出，系统会扫描右表aoddc_cicifci0_h ,对其所有数据 建立一个 Hash 表； 如果 aoddc_cicifci0_h 是一个超大表，那么

34、LEFT JOIN 可以改写如下 ： 互联网络 1717 9、表通过分布键关联时，不要使用表达式字段的方式进行关联，否则会导 致数据重分布，举例如下： -错误的关联方式,导致数据重分布 Select * from base_fs.aoddc_ciccrcc0_h AS A LEFT JOIN temp_result AS B ON trim(A.ci_cust_no)=B.ci_cust_no -正确的关联方式 Select * from base_fs.aoddc_ciccrcc0_h AS A LEFT JOIN temp_result AS B ON A.ci_cust_no=B.ci_

35、cust_no 3.5 排序语句排序语句 1、不要在视图中使用 Order By 排序语句，在视图中，排序语句会被忽略； 2、ORDER BY 语句执行成本很高，建议尽量避免使用； 3、不要在大的数据结果集上执行排序操作； 4、Partition By 、Union 内部实现需要对数据排序，在数据量在千万级别 下，差别不大，但如果数据量在亿级别上，建议尽量使用 group by 实现，尽 量避免 order by 操作，举例如下： Select cust_no,cust_name from BigTableA Union Select cust_no,cust_name from BigTab

36、leB 互联网络 1818 建议改为 group by 实现： Select cust_no,cust_name from ( Select cust_no,cust_name from BigTableA Union ALL Select cust_no,cust_name from BigTableB ) AS P Group by cust_no,cust_name 3.6 嵌套子查询嵌套子查询 建议子查询嵌套的层次不要超过 4 层；如果查询过于复杂，应对查询进行 拆分，分为多个较简单的执行语句配合临时表来实现； 3.7 UNION / UNION ALL 1、UNION 操作，如果不需

37、要去重，请用 UNION ALL 替代。 例如，如下语句： 可替换为： 互联网络 1919 从执行计划的差异上，可看出，UNION ALL 具有更好的性能，所以，如 果不需要去重，仅仅是合并数据集，应使用 UNION ALL； 2、不建议过多的使用 UNION ALL。除了简单的少量记录的 UNION ALL 操作，对于很多复杂的子查询，不建议超过 5 个子句进行 UNION ALL。如果大 量结果集需要 UNION ALL，可把所有结果集都插入到临时表。这样的效率比大 量的 UNION ALL 高。 3.8 高效高效 SQL 写法的建议写法的建议 1、在 SQL 语句的执行计划中，应通过优化

38、执行语句，尽量避免数据重分 布操作，可使用 Explain 命令检查 SQL 语句是否存在 redistributed ，broadcast 等操作，并检查操作是否合理； 例如：两张表 base_fs.aoddc_ciccrcc0_h 和 base_fs.aoddc_cicifci0_h ,它 们的分布键一致，定义如下： 互联网络 2020 SQL 语句 1 写法如下： 其执行计划如下： 在执行计划中，包含了 Redistribute Motion 操作，就需要在节点之间重分 布数据；可将 SQL 语句优化，改写如下，把分布键包含进关联字段，可比较数 据重分布，改善性能： 其执行计划如下： 2、在关联字段中，尽量包含分布键作为关联条件，避免数据重分布； 3、在 Where 条件中，尽量保证每个节点的过滤后的结果集是均匀的，避 免数据倾斜； 4、对于大表的 UNION 操作，如果不需要去重，请用 UNION ALL 替代； 互联网络 2121 5、对于大表的 UNION 操作，如果需要去重，请用 UNION ALL 加上 GROUP BY 替代，因为 UNION 操作需要执行 SORT 操作，执行成本更高； 例子如下： 可改写如下: 6、尽量避免对大表进行的 UPDATE 操作，建议用 DELETE + INSERT