Greenplum数据库设计开发规范

Greenplum数据库设计开发Greenplum数据库设计开发规范Greenplum数据库设计开发规范目录第一章前言.................................................................21.1文档目的...............................................................21.2预期读者...............................................................21.3参照资料...............................................................2第二章设计规范.............................................................32.1数据库对象数目.........................................................32.2表创立规范.............................................................32.3表构造设计.............................................................4字段命名.............................................................4数据种类.............................................................4数据分布.............................................................5分区.................................................................7压缩储蓄.............................................................8索引设计.............................................................82.4其余数据库对象设计....................................................10schema..............................................................10视图................................................................11暂时表和中间表......................................................11第三章SQL开发规范.........................................................123.1基本要求..............................................................123.2WHERE条件...............................................................123.3分区字段使用..........................................................133.4表关系................................................................133.5排序语句..............................................................163.6嵌套子盘问............................................................163.7UNION/UNIONALL........................................................163.8高效SQL写法的建议....................................................18精选文档。1精选文档第一章前言1.1文档目的跟着Greenplum数据库的正式上线使用。为了保证Greenplum数据库房系统平台的安稳运转，保证系统的靠谱性、坚固性、可保护性和高性能。特拟订本开发规范，以规范基于Greenplum数据库平台的相关应用开发，提高开发质量。1.2预期读者Greenplum数据库房平台应用的设计与开发人员；Greenplum数据库房平台的系统管理人员和数据库管理员；Greenplum数据库房平台的运转保护人员；1.3参照资料参照版本官方引导：《GPDB43AdminGuide.pdf》GPDB43RefGuide.pdf》GPDB43UtilityGuide.pdf》。2精选文档第二章设计规范2.1数据库对象数目数据库对象种类包含数据表、视图、函数、序列、索引等等，在Greenplum数据库中，系统元数据同时保存在Master服务器和Segment服务器上，过多的数据库对象会造成系统元数据的膨胀，而过多的系统元数据造成系统运转逐渐变慢；同时，近似数据库的备份、恢复、扩容等较大型的操作都以致效率变慢。因此，依据GreenplumDB产品的最正确时间，单个数据库的对象数目，应控制在10万之内。GP数据库的对象包含：表、视图、索引、分区子表、外面表等。假如数据表的数目太多，建议按应用域进行分库，尽量将单个数据库的表数目控制在10万之内，可以在一个集群中创立多个数据库。【备注】：在Greenplum数据库中，一张分区表，在数据库中储蓄为一张父表、每张分区子表都是一张独立的库表；比方：一张按月进行分区的储蓄一年数据的表，假如含默认分区，共14张表。2.2表创立规范为了防备数据库表数目太多，防备单个数据表的数据量过大，给系统的运转和使用带来困难，在Greenplum数据库中需依据以下的表创立规范：1、GP系统表中保存的表名称都是以小写保存。平时SQL语句中表名对大小写不敏感。但不相赞成在建表语句中使用双引号（“”）包含表名，这样会影响系统表中储蓄的名称，使得表名存在大小写或特别字符。表命名也不相赞成出现中文字。2、单个数据库的数据表数目建议不要超出10万张；3、严禁使用二级分区表，因为二级分区表会造成表对象数目的急剧膨胀；4、因为过多的数据文件会以致操作系统对文件的操作效率降低，直接影响到数据库的管理效率。假如数据文件数目过多，建议增加多个表空间，把数据表。3精选文档平均分布到不同样的表空间。每个表空间目录下的数据文件数目，应控制在80万之内。文件数统计可以直接到某个Segment实例目录下指定的表空间目录下统计。5、创立数据表（DDL）的时候（不含暂时表和程序中使用的中间表），必然使用tablespace子句指定用于储蓄的表空间，而不是把所有表都储蓄在默认表空间；比方：Createtableemployee(idint,namevarchar)TABLESPACEtpc_data_01distributedby(id);6、对于数据量超出1TB的大表,需从应用设计方面，考虑对大表进行优化，比方能否可划分为历史数据表和当前数据表，并分开存放；能否应采纳压缩储蓄节约空间；能否合理分区；能否应按期清理数据等等。2.3表构造设计字段命名表字段的命名，与表名近似。在GP系统表中保存的表名称都是以小写保存。平时SQL语句中字段名称对大小写不敏感。但不相赞成在建表语句中使用双引号（“”）包含字段名，这样会影响系统表中储蓄的名称，使得表名存在大小写或特殊字符。字段命名也不相赞成出现中文字。数据种类数据种类的定义与相关数据的加载和使用亲近相关，数据种类的定义决定了数据所占用的空间大小，所以，必然谨慎设计GP数据库房数据表的字段种类。数据库房的数据来自于多个异构的业务应用系统，平时状况下，业务应用系统的字段种类选择较为随意，不同样的业务系统数据种类定义存在多样化，相互之间差异较大；所以，在数据库房中，需在参照源系统字段种类定义的状况下，结Greenplum数据库房平台的特色和要求，对字段数据种类进行设计。Greenplum数据库的数据种类定义需依据以下原则：1、在满足业务需求的条件下，尽可能选择空间占用最小的数据种类；以节。4精选文档省数据储蓄空间；2、在GP系统中，CHAR、VARCHAR和TEXT之间不存在性能差异，在其余的DB系统中，可能CHAR会表现出最好的性能，但在GPDB中是不存在这类性能优势的。在多数状况下，应入选择使用VARCHAR而不是CHAR；3、定长字符串种类使用varchar,而不使用char.4、对于数值种类来说，应该尽量选择更小的数据种类来适应数据；比方，选择BIGINT种类来储蓄SMALLINT种类范围内的数值，会造成空间的大批浪费。5、用来做TableJoin的Column来说，应该考虑选择同样的数据种类。如果做Join的Column拥有同样的数据种类(比方主键PrimaryKey与外键ForeignKey)，其工作效率会更高。6、一般状况下，应尽量使用上述规范数据种类，防备出现诸如：Address，INET，ARRAY等特别种类字段。数据分布基于Greenplum数据库房平台的特色，每张数据表都必然指定分布键DK，Greenplum数据库依据数据分布键（DistributedKey,简称DK，后同）值来决定储蓄在哪一个segment上，DK不仅决定了数据在集群节点上的分布，还严重影响数据盘问和办理操作的执行效率，需要特别谨慎的选择数据表的分布键。对于Greenplum数据库房平台，DK的选择需要依据以下原则：1、数据平均分布原则为了尽可能达到最好的性能，所有的Instance应该尽量存储等量的数据。若数据的分布不均衡或倾斜，那些存储了好多数据的Instance在办理自己那部分数据时将需要耗费更多的工作量。为了实现数据的平展分布，可以考虑选择拥有独一性的DK，如主键。2、当地操作原则在办理盘问时，好多办理如关系、排序、聚合等若可以在Instance当地完成，其效率将远高于超越系统级别(需在Instance之间交错传输数据)的操作。当不同样的Table使用同样的DK时，在DK上的关系也许排序操作将会以最高效的。5精选文档方式把绝大多数工作在Instance当地完成。3、均衡的盘问负载原则在一个盘问正被办理时，我们希望所有的Instance都可以办理等量的工作负载，从而尽可能达到最好的性能。经过合理的DK设计，尽量使得盘问办理的负载平均分布在每个节点上，而且尽量保证where条件产生的结果集在各个节点上也是平均的。4、关系一致原则当表于表之间存在关系时，各表应选择同样字段作为DK，而且做关系盘问时，使用DK作为连接字段，尽可能使连接包含所有DK字段；5、DK一致原则总分父子表的DK应保持一致；中间过程表、暂时表的DK应尽可能保持和源表的DK一致；6、DK精简原则DK字段不宜过多，DK字段越少越好。基于以上原则，Greenplum数据库房平台的数据表DK设计规范以下：?每个数据表必然经过Distribiuted子句显式指定分布键，不相赞成使用默认DK的方式创立数据表；分布键字段原则上为1个，应尽量不要超出3个；分区的父子表的分布键应完满一致；中间过程表、暂时表、派生表的DK应尽可能保持和源表一致；具相关系关系的数据表，应尽可能使用关系字段作为分布键；分布键字段不可以执行Update操作；为了保证数据分布平均，在没有适合字段作为分布键的状况下，应选择数据表的主键作为分布键；对于没有逻辑主键，又没有其余适合字段作为分布键的数据表，才建议设置其分布策略为DistributedRandomly，这只应该为最后的选择；随机分布的适合使用途景：盘问时不需要和其余表关系、或只与小表关系的数据表，使用随机分布策略。。6精选文档分区表分区用以解决特别大的表的问题，分区表在执行给定的盘问语句时，扫描相关的部分数据而不是全表的数据从而提高盘问性能。分区表对于数据库的管理也有帮助。其实不是任何数据表都适合做分区，应从以下几个方面判断能否应进行分区：1、表能否足够大？只有特别大的事实表才适合做表分区。若在一张表中有数亿条记录，从逻辑上把表分成较小的分区将可以改进性能。而对于只有数万条也许更少记录的表，对分区开初进行的管理开支将远大于可以获取的性能改进。2、对当前的性能不满意？作为一种调优，应该在盘问性能低于预期时再考虑表分区。3、盘问条件能否能般配分区条件？检查盘问语句的WHERE条件能否与考虑分区的COLUMN一致。比方，假如大部分的盘问使用日期条件，那么依据月也许周的日期分区设计也许很合用，而如果盘问条件更多的是使用地区条件，可以考虑使用地区将表做列表种类的分区。4、依据某个规则数据能否可以被平均的分拆？应入选择尽量把数据平均分拆的规则。若每个分区存储的数据量相当，那么盘问性能的改进将与分区的数目相关。比方，把一张表分为10个分区，命中单个分区条件的盘问扫表性能将比未分区的状况下高10倍。假如以上几个方面的回答都是Yes，这样的表可以经过分区策略来提高盘问性能。如上边章节所述，在Greenplum中，每个分区子表都对应一张独立的数据表，系统经过父子表之间的继承关系来保护分区定义信息。假如过多的数据表进行了分区，会造成表对象数目过多，系统元数据急剧膨胀，给系统的运转和保护带来很大负担。所以，还要综合考虑系统的表数据量状况，才可决定能否对数据表进行分区。基于以上原则，Greenplum数据库数据分区的使用规范以下：。7精选文档在性能可以满足的状况下，尽量不使用数据分区；因会造成表对象数目过多，增加执行生成的复杂性，严禁使用二级分区；数据量在亿级别以下，建议不要使用分区；表的数据在单个实例的数据量在100万级别以下，不需要分区；?分区字段不可以以UPDATE，需要用delete+insert也许truncate+insert代替实现。压缩储蓄Greenplum数据表分两各种类：heap表和AO表（Append-optimized）。在Greenplum数据库中，需要对数据进行压缩，数据表则需要设置为AO表。对数据表进行压缩，可以减少磁盘占用空间，同时也减少了对IO资源的开支（以CPU资源换IO资源）。特别是在当前IO资源不足的硬件环境下，数据库设计应该尽可能多的使用AO表。建议在选择压缩存储模式时，最好依据比较测试的结果来确立。综合以上考虑，数据表压缩的设计规范以下：数据量在百万级以下的小表，不建议使用压缩储蓄；不要在压缩文件系统使用压缩储蓄；压缩表建议一以致用zlib压缩算法，压缩级别为6(appendonly=true,compresstype=zlib,compresslevel=6);，此压缩设置满足大多数的使用途景。建议对数据库房中的记录数超出1亿的事实表、历史数据表采纳压缩储蓄；所有历史数据表、备份表、归档表一以致用压缩储蓄；索引设计。8精选文档在分布式数据库GPDB中，应尽量防备使用索引。GPDB中大多数应用途景是使用序次扫描。与传统的OLTP数据库不同样的是，Greenplum中数据表的数据是分布在多个节点上的。这意味着每个节点都扫描所有数据的一小部分来查找结果。假如使用了表分区，扫描的数据可能更少。平时，这类状况下使用索引未必能提高性能。索引更易于改进OLTP种类的工作负载，因其返回极少许的数据，当状况合合时盘问优化器会把索引作为获取数据的选择，而不是一味的全表扫描。增加索引会带来一些数据库开支，其必然占用相当的储蓄空间，而且表更新时需保护索引。需保证索引的创立在盘问工作负载中真切被使用到。同时，需要检查索引的确对于盘问性能有明显的改进(与序次扫描的性能比较)。Greenplum支持B-tree索引和位图（Bitmap）索引。所以，使用索引时，需要综合考虑以下问题：1、盘问工作负载种类：索引更适合于OLTP种类的工作负载，其返回极少许的数据，对于OLAP种类的盘问负载，在GPDB中索引平时作用不大；2、压缩表：在盘问少许数据的状况下，索引可以改进AO表上的盘问性能，当状况合合时盘问优化器会把索引作为获取数据的选择，而不是一味的全表扫描。对于压缩数据来说，索引接见数据的方法是解压需要的记录而不是所有解压；3、防备在屡次更新的列上使用索引。在屡次更新的列上创立索引，当该列被更新时，需要耗费大批的写磁盘资源和CPU计算资源；4、在高选择性的列适合使用B-tree索引，选择性指的是列中DISTINCT值的数目除以表中的记录.比方，假如一张表中有1000行记录且有800个DISTINCT值，选择性指数为0.8，这被以为是优异的。独一索引老是具备1.0的选择比，这是最好的状况；5、低选择性的列适合使用bitmap索引；6、索引列用于关系。常常关系(JOIN)的COLUMN(比方外键)上建立索引也许可以改进JOIN的性能，因为其可以帮助盘问规划器使用其余的关系方法；7、索引列常常用在盘问条件中。对于大表来说，盘问语句WHERE条件中经常用到的列，可以考虑使用索引。。9精选文档综合以上状况，联合Greenplum平台的特色，索引设计的规范以下：原则上，数据库房中的数据表不建立索引。只有供应给外面用户接见的表，才考虑按用户接见特色，针对常用盘问字段建立索引；对于跑批的中间表和暂时表，不相赞成创立索引；对于记录数在百万级别以下的小表，建议不使用索引；创立组合索引时，必然将常常作为盘问条件且可选择性最大的列设置为索引的首列；不相赞成创立冗余索引；对于差异度高的索引，应使用B-tree索引，比方账号、号等等；对于差异度低的索引，应使用Bitmap索引，比方机构、产品种类等等；创立组合索引时，建议列数不要超出5列；每张数据表的索引数，建议不超出5个；在创立和更新索引后，必然执行Analyze操作，更新索引的统计信息；在对大表进行数据加载的时候，假如存在索引，建议先删除索引，待数据加载完成，再重新创立索引；对屡次更新的数据表，应按期对其执行reindex操作，以重修索引；假如在分区表中使用了索引，不相赞成在子表上单独创立和更正索引；平时，删除顶级分区的索引，系统会自动删除相关子表的索引，但假如子表的索引出缺失，将不可以自动删除子表的索引，需要一一手动删除。不再使用的索引必然删除；2.4其余数据库对象设计schema模式(Schema)是在DB内组织对象的一种逻辑构造。模式可以赞成用户在一DB内不同样的模式之间使用同样Name的对象(比方Table)。Schema命名不相赞成出现中文字。Schema的规划与创立建议由系统管理员或应用设计人员一致规划和设计。。10精选文档不相赞成在系统的Schema下创立用户表；Greenplum的系统Schema以下：序号Schema名称说明1.gp_toolkit供应系统管理方面的视图2.Information_schema供应元数据信息的视图3.pg_catalog系统对象元数据表4.pg_aosegAppendonly表的辅助元数据表5.pg_toast大对象储蓄6.pg_bitmapindex位图索引对象储蓄视图视图的设计规范建议以下：视图命名不相赞成使用双引号包含视图名，视图名称不相赞成出现中文字；在视图中，不相赞成使用ORDERBY语句；对屡次接见，拥有多个大表关系，并含有复杂计算或排序的视图，建议更正为物理表；暂时表和中间表暂时表使用规范以下：对于每天按期执行的后台数据办理作业，建议不要使用暂时表，因为使用暂时表，会造成每天都进行大批的数据表的创立和删除，引起系统元数据表的急剧膨胀，以致需要屡次的进行系统表的Vacuum操作，从而影响系统的使用和坚固性。暂时表和中间表定义时必然显示指定分布键。暂时表和中间表，评估表数据量，建议大表一致采纳压缩表。。11精选文档第三章SQL开发规范3.1基本要求1、代码行清楚、整齐、井井有条、构造性强，易于阅读；2、代码中应具备必需的说明以加强代码的可读性和可保护性；3、代码应充分考虑执行效率，保证代码的高效性；3.2WHERE条件1、在Where条件过滤中，应尽量将函数办理放在等式的右侧，以提高盘问性能；2、对于日期（date、timestamp等）种类的字段判断，条件值可直接使用字符串，GP会自动进行变换。无需过多的使用种类变换函数，如：to_date使用：WHEREcall_dt='2015-01-01';不需要写成：WHEREcall_dt=to_date('2015-01-01','YYYY-MM-DD');3、在条件过滤中使用函数，不需要写select要点字。不然会影响执行计划的正确性：错误示例：WHEREt.z_day=(selectto_char(current_timestamp-interval'1minute','dd'))andt.z_hours=(selectto_char(current_timestamp-interval'1minute','HH24'))4、系统中好多采纳日期分区的表，分区字段种类为数值型（integer）。等式的左侧不要使用数值运算，不然会影响执行计划对分区使用的正确性。问题示例：WHEREstatis_date/100=masadw.fn_get_l1m_yyyymm(20150423)可改写为：WHEREstatis_datebetween20150401and20150430;WHEREstatis_date>=20150401andstatis_date<=20150430;5、在WHERE条件中错误的增加1<>1的判断，会以致执行计划纷杂。。12精选文档问题语句：SELECT'20141130'::INTasstatic_date,B.DVLPER_CODE,A.CNTY_ID,SUM(A.CALL_DUR)/60.0ASCALL_DURFROMmasamk.LS_GSM_TOL_DA,masamk.IU_USR_DBWHERE1<>1andA.statis_date=20141130ANDA.USR_ID=B.USR_IDGROUPBYB.DVLPER_CODE,A.CNTY_ID3.3分区字段使用如上述章节提到的分区表的使用原则，使用分期表是为了降低每次表扫描涉及的数据量，已达到提高SQL办理效率的目的。假如SQL语句中没有正确的使用分区字段就会以致遍历所有分区，以致SQL执行效率低下。特别在多个分区表关系时，每个分区表都需要拟订分区字段的条件。除非业务上有特别要求必然要遍历所有的（或大多数的）子分区。3.4表关系1、表连接中的每个表应指定缩写的别名，别名的命名尽量清楚可鉴识；2、多表关系的时候，建议所有的关系写成JOIN的形式，比方：而不相赞成写成以下形式：3、建议一个SQL语句中多表关系的关系表不要超出10张表；。13精选文档4、几个大小差不多的表做关系时，过滤性较强的优先做aJOIN；5、在大/大/小三个表内关系时，防备先把两个大表进行JOIN，除非过滤性特别强；比方：pg_namespace为小表，其余2个表为大表6、在大/小/小三个表内联时，优先把两个小表进行JOIN：SELECT*FROM(smalltableAASAINNERJOINsmalltableBASBONA.key=B.key)INNERJOINbigtableASCONC.key=A.key7、在关系大表的时候，左右两个连接表的关系字段不可以同时存在高重复值的状况，省得因重复记录关系产生巨大的中间结果，造成磁盘占用比率的大幅增长；比方：假如一个100万的重复记录表和一个1万的重复记录表关系，结果会高达100万*1万=100亿条记录；8、在使用小表LEFTJOIN超大表（记录数过亿）时，激烈建议把LEFTJOIN更正为先INNERJOIN，再LEFTJION的方式实现。这样既可以提高性能，也能防备Greenplum产生大批的暂时文件；因为在Greenplum数据库中，对于LEFTJOIN语句，服务器会固定使用右表的记录，构造Hash表，此后用HashJoin的方式实现关系；假如右表特别大，会以致Hash表需要占用大批的内存，假如内存超出限制，系统会把Hash表的内容，写入到文件系统的暂时文件中，假如右表是一个超大表，可能在执行此语句的时候，系统会写入大批暂时文件，造成系统占用空间大幅增加；假如是INNERJOIN语句，系统会自动选择用小表建立Hash表。比方：以下LEFTJOIN语句：。14精选文档其执行计划以下：从执行计划可以看出，系统会扫描右表aoddc_cicifci0_h,对其所有数据建立一个Hash表；假如aoddc_cicifci0_h是一个超大表，那么LEFTJOIN可以改写以下：9、表经过分布键关系时，不要使用表达式字段的方式进行关系，不然会导致数据重分布，举比方下：错误的关系方式,以致数据重分布Select*frombase_fs.aoddc_ciccrcc0_hASA。15精选文档LEFTJOINtemp_resultASBONtrim(A.ci_cust_no)=B.ci_cust_no正确的关系方式Select*frombase_fs.aoddc_ciccrcc0_hASALEFTJOINtemp_resultASBONA.ci_cust_no=B.ci_cust_no3.5排序语句1、不要在视图中使用OrderBy排序语句，在视图中，排序语句会被忽视；2、ORDERBY语句执行成本很高，建议尽量防备使用；3、不要在大的数据结果集上执行排序操作；4、PartitionBy、Union内部实现需要对数据排序，在数据量在千万级别下，差异不大，但假如数据量在亿级别上，建议尽量使用groupby实现，尽量防备orderby操作，举比方下：Selectcust_no,cust_namefromBigTableAUnionSelectcust_no,cust_namefromBigTableB建议改为groupby实现：Selectcust_no,cust_namefrom(Selectcust_no,cust_namefromBigTableAUnionALLSelectcust_no,cust_namefromBigTableB)ASPGroupbycust_no,cust_name3.6嵌套子盘问建议子盘问嵌套的层次不要超出4层；假如盘问过于复杂，对付盘问进行拆分，分为多个较简单的执行语句配合暂时表来实现；3.7UNION/UNIONALL1、UNION操作，假如不需要去重，请用UNIONALL代替。。16精选文档比方，以下语句：可代替为：从执行计划的差异上，可看出，UNIONALL拥有更好的性能，所以，假如不需要去重，但是是合并数据集，应使用UNIONALL；2、不建议过多的使用UNIONALL。除了简单的少许记录的UNIONALL操作，对于好多复杂的子盘问，不建议超出5个子句进行UNIONALL。假如大批结果集需要UNIONALL，可把所有结果集都插入来暂时表。这样的效率比大批的UNIONALL高。。17精选文档3.8高效SQL写法的建议1、在SQL语句的执行计划中，应经过优化执行语句，尽量防备数据重分布操作，可使用Explain命令检查SQL语句能否存在redistributed，broadcast等操作，并检查操作能否合理；比方：两张表base_fs.aoddc_ciccrcc0_h和base_fs.aoddc_cicifci0_h,它们的分布键一致，定义以下：SQL语句1写法以下：其执行计划以下：在执行计划中，包含了RedistributeMotion操作，就需要在节点之间重分布数据；可将SQL语句优化，改写以下，把分布键包含进关系字段，可比较数据重分布，改进性能：其执行计划以下：。18精选文档2、在关系字段中，尽量包含分布键作为关系条件，防备数据重分布；3、在Where条件中，尽量保证每个节点的过滤后的结果集是平均的，防备数据倾斜；4、对于大表的UNION操作，假如不需要去重，请用UNIONALL代替；5、对于大表的UNION操作，假如需要去重，请用UNIONALL加上GROUPBY代替，因为UNION操作需要执行SORT操作，执行成本更高；例子以下：可改写以下:。19精选文档6、尽量防备对大表进行的UPDATE操作，建议用DELETE+INSERT的方式进行代替；比方，base_fs.uoddc_saacntxn_a_test和base_fs.uoddc_saacntxn_a_test_tmp的表构造一致；分布键：sa_acct_no,sa_ddp_acct_no_det_n逻辑主键：sa_acct_no假如需要用base_fs.uoddc_saacntxn_a_test_tmp的数据去更新目标表base_fs.uoddc_saacntxn_a_test的数据，平时目标表为一个大表；暂时表base_fs.uoddc_saacntxn_a_test_tmp为相对小的数据表；Update语句以下：这样的功能，可改写为DELETE+INSERT的方式实现，例子以下：7、清空数据表，应使用TRUNCATE操作，不要使用无条件的DELETE操作，。20精选文档防备VACUUM办理；比方：DELETEFROMTablexxxx;应更正为:TRUNCATETABLETablexxxx;8、应尽量将嵌套子盘问，变换为等价的外连接方式实现，减少嵌套层次；9、对NotIN，NotExist操作，建议使用LEFTJOIN的方式实现，而且使用DK作为关系条件，防备broadcast.比方：外连接SELECTcount(*)FROMbase_fs.uoddc_saacntxn_a_test_tmpWHERE(sa_acct_no,sa_ddp_acct_no_det_n)NOTIN(SELECTsa_acct_no,sa_ddp_acct_no_det_nFROMbase_fs.uoddc_saacntxn_a_test)其执行计划以下：从执行计划可以看出，包含broadcast操作，执行成本很高，可更正为使用LEFTJOIN形式进行优化，以下：SELECTcount(*)FROMbase_fs.uoddc_saacntxn_a_test_tmpASALEFTJOINbase_fs.uoddc_saacntxn_a_testASBONA.sa_acct_no=B.sa_acct_noANDA.sa_ddp_acct_no_det_n=B.sa_ddp_acct_no_det_nWHEREB.sa_acct_noISNULL;。21精选文档其执行计划以下：后边一种实现方式，性能比NOTIN的方式改进好多；。22精选文档欢迎您的下载，资料仅供参照！致力为企业和个人供应合同协议，策划案计划书，学习资料等等打造全网一站式需求。23