1、第一章前言 錯誤!未指定書簽1.1 文檔目的 錯誤!未指定書簽1.2 預期讀者 錯誤!未指定書簽1.3 參考資料 錯誤!未指定書簽第二章設計規范 錯誤！未指定書簽2.1 數據庫對象數量 錯誤!未指定書簽2.2 表創建規范錯誤!未指定書簽2.3 表結構設計 錯誤!未指定書簽2.3.1 字段命名 錯誤!未指定書簽2.3.2 數據類型 錯誤!未指定書簽2.3.3 數據分布 錯誤!未指定書簽2.3.4 分區錯誤!未指定書簽2.3.5 壓縮存儲 錯誤!未指定書簽2.3.6 索引設計錯誤!未指定書簽24其他數據庫對象設計 錯誤!未指定書簽2.4.1 schema 錯誤!未指定書簽2.4.2 視圖 錯誤!未

2、指定書簽2.4.3 臨時表和中間表 錯誤!未指定書簽第三章SQL開發規范 錯誤!未指定書簽3_1基本要求 錯誤!未指定書簽32 WHERE條件錯誤!未指定書簽33 分區字段使用 錯誤!未指定書簽34 表關聯 錯誤!未指定書簽35 排序語句 錯誤!未指定書簽36 嵌套子杳詢 錯誤!未指定書簽37 UNION/UNION ALL 錯誤!未指定書簽38 高交上SQL寫法的建議 錯誤!未指定書簽第一章前言1.1 文檔目的隨著Greenplum 數據庫的正式上線使用。為了保證Greenplum 數據倉庫系統平臺的平穩運行，保證系統的可靠性、穩定性、可維護性和高性能。特制定 本開發規范，以規范基于 Gre

3、enplum數據庫平臺的相關應用開發，提高開發質 量。1.2 預期讀者Greenplum數據倉庫平臺應用的設計與開發人員；Greenplum數據倉庫平臺的系統管理人員和數據庫管理員；Greenplum 數據倉庫平臺的運行維護人員；1.3 參考資料參考Greenplum4.3.x版本官方指引：GPDB43AdminGuide.pdf »GPDB43RefGuide.pdf »GPDB43UtilityGuide.pdf »第二章設計規范2.1 數據庫對象數量數據庫對象類型包括數據表、視圖、 函數、序列、索引等等，在Greenplum 數據庫中，系統元數據同時保存在

4、Master服務器和Segment服務器上，過多 的數據庫對象會造成系統元數據的膨脹，而過多的系統元數據造成系統運行逐步 變慢；同時，類似數據庫的備份、恢復、擴容等較大型的操作都導致效率變慢。 因此，依據GreenplumDB產品的最佳時間，單個數據庫的對象數量，應控制在 10萬以內。GP數據庫的對象包括：表、視圖、索引、分區子表、外部表等。如果數據表的數量太多，建議按應用域進行分庫，盡量將單個數據庫的表數 量控制在10萬以內，可以在一個集群中創建多個數據庫。【備注】：在Greenplum數據庫中，一張分區表，在數據庫中存儲為一張父 表、每張分區子表都是一張獨立的庫表； 例如：一張按月進行分區

5、的存儲一年數 據的表，如果含默認分區，共14張表。2.2 表創建規范為了避免數據庫表數量太多，避免單個數據表的數據量過大，給系統的運行 和使用帶來困難，在Greenplum數據庫中需遵循如下的表創建規范：1、GP系統表中保存的表名稱都是以小寫保存。通常 SQL語句中表名對大 小寫不敏感。但不允許在建表語句中使用雙引號（“"）包括表名，這樣會影響系 統表中存儲的名稱，使得表名存在大小寫或特殊字符。 表命名也不允許出現中文 字。2、單個數據庫的數據表數量建議不要超過 10萬張；3、禁止使用二級分區表，因為二級分區表會造成表對象數量的急劇膨脹；4、由于過多的數據文件會導致操作系統對文件的操

6、作效率降低，直接影響 到數據庫的管理效率。如果數據文件數量過多，建議增加多個表空間，把數據表 均勻分布到不同的表空間。每個表空間目錄下的數據文件數量，應控制在 80萬 以內。文件數統計可以直接到某個 Segment實例目錄下指定的表空間目錄下統 計。5、創建數據表(DDL)的時候(不含臨時表和程序中使用的中間表)，必須 使用tablespace子句指定用于存儲的表空間，而不是把所有表都存儲在默認表 空間；例如：Create table employee ( id int,name varchar)TABLESPACE tpc data 01 distributed by (id);6、對于數據

7、量超過 仃B的大表，需從應用設計方面，考慮對大表進行優化， 例如是否可劃分為歷史數據表和當前數據表，并分開存放；是否應采用壓縮存儲節省空間；是否合理分區；是否應定期清理數據等等。2.3 表結構設計2.3.1 字段命名表字段的命名，與表名類似。在GP系統表中保存的表名稱都是以小寫保存。 通常SQL語句中字段名稱對大小寫不敏感。但 不允許在建表語句中使用雙引號 (“”)包括字段名，這樣會影響系統表中存儲的名稱， 使得表名存在大小寫或特 殊字符。字段命名也不允許出現中文字。2.3.2 數據類型數據類型的定義與相關數據的加載和使用緊密相關，數據類型的定義決定了 數據所占用的空間大小，因此，必須慎重設計

8、GP數據倉庫數據表的字段類型。數據倉庫的數據來自于多個異構的業務應用系統，通常情況下，業務應用系 統的字段類型選擇較為隨意，不同的業務系統數據類型定義存在多樣化，彼此之間差異較大；因此，在數據倉庫中，需在參考源系統字段類型定義的情況下，結 合Greenplum數據倉庫平臺的特點和要求，對字段數據類型進行設計。Greenplum數據庫的數據類型定義需遵循以下原則：1、在滿足業務需求的條件下，盡可能選擇空間占用最小的數據類型；以節 省數據存儲空間；2、在GP系統中，CHAR、VARCHAR和TEXT之間不存在性能差異，在 其他的DB系統中，可能CHAR會表現出最好的性能，但在 GPDB中是不存在

9、這種性能優勢的。在多數情況下，應該選擇使用 VARCHAR而不是CHAR;3、定長字符串類型使用varchar,而不使用char.4、對于數值類型來說，應該盡量選擇更小的數據類型來適應數據；比如， 選才? BIGINT類型來存儲SMALLINT類型范圍內的數值，會造成空間的大量浪 費。5、用來做Table Join的Column來說，應該考慮選擇相同的數據類型。如 果做Join的Column具有相同的數據類型（比如主鍵 PrimaryKey 與外鍵 ForeignKey）,其工作效率會更高。6、一般情況下，應盡量使用上述規范數據類型，避免出現諸如：Address,INET , ARRAY等特殊

10、類型字段。2.3.3 數據分布基于Greenplum數據倉庫平臺的特點，每張數據表都必須指定分布鍵 DK, Greenplum 數據庫根據數據分布鍵（Distributed Key,簡稱DK,后同）值來決定 記錄存儲在哪一個segment上，DK不僅決定了數據在集群節點上的分布，還 嚴重影響數據查詢和處理操作的執行效率，需要非常慎重的選擇數據表的分布 鍵。對于Greenplum 數據倉庫平臺，DK的選擇需要遵循以下原則：1、數據均勻分布原則為了盡可能達到最好的性能，所有的Instance應該盡量儲存等量的數據。若數據的分布不平衡或傾斜，那些儲存了較多數據的 Instance在處理自己那部 分數

11、據時將需要耗費更多的工作量。 為了實現數據的平坦分布，可以考慮選擇具 有唯一性的DK,如主鍵。2、本地操作原則在處理查詢時，很多處理如關聯、排序、聚合等若能夠在Instance本地完成，其效率將遠高于跨越系統級別（需在Instance之間交叉傳輸數據）的操作。當 不同的Table使用相同的DK時，在DK上的關聯或者排序操作將會以最高效的 方式把絕大部分工作在Instance本地完成。3、均衡的查詢負載原則在一個查詢正被處理時，我們希望所有的 Instance都能夠處理等量的工作 負載，從而盡可能達到最好的性能。通過合理的 DK設計，盡量使得查詢處理的 負載均勻分布在每個節點上，并且盡量保證 w

12、here條件產生的結果集在各個節 點上也是均勻的。4、關聯一致原則當表于表之間存在關聯時，各表應選擇相同字段作為DK ,并且做關聯查詢時，使用DK作為連接字段，盡可能使連接包含全部 DK字段；5、DK 一致原則總分父子表的DK應保持一致；中間過程表、臨時表的 DK應盡可能保持和 源表的DK 一致；6、DK精簡原則DK字段不宜過多，DK字段越少越好。基于以上原則，Greenplum數據倉庫平臺的數據表DK設計規范如下：?每個數據表必須通過Distribiuted子句顯式指定分布鍵，不允許使用默認 DK的方式創建數據表；?分布鍵字段原則上為1個，應盡量不要超過3個；?分區的父子表的分布鍵應完全一致

13、；?中間過程表、臨時表、派生表的 DK應盡可能保持和源表一致；?具有關聯關系的數據表，應盡可能使用關聯字段作為分布鍵；?分布鍵字段不可執行Update操作；?為了保證數據分布均勻，在沒有合適字段作為分布鍵的情況下，應選擇 數據表的主鍵作為分布鍵；?對于沒有邏輯主鍵，又沒有其他合適字段作為分布鍵的數據表，才建議 設置其分布策略為Distributed Randomly ,這只應該為最后的選擇；?隨機分布的適合使用場景：查詢時不需要和其它表關聯、或只與小表關 聯的數據表，使用隨機分布策略。2.3.4 分區表分區用以解決特別大的表的問題， 分區表在執行給定的查詢語句時，掃描 相關的部分數據而不是全表

14、的數據從而提高查詢性能。分區表對于數據庫的管理 也有幫助。并不是任何數據表都適合做分區，應從如下幾個方面判斷是否應進行 分區：1、表是否足夠大只有非常大的事實表才適合做表分區。 若在一張表中有數億條記錄，從邏輯 上把表分成較小的分區將可以改善性能。而對于只有數萬條或者更少記錄的表， 對分區預先進行的管理開銷將遠大于可以獲得的性能改善。2、對目前的性能不滿意作為一種調優方案，應該在查詢性能低于預期時再考慮表分區。3、查詢條件是否能匹配分區條件檢查查詢語句的 WHERE條件是否與考慮分區的COLUMN 一致。例如，如 果大部分的查詢使用日期條件，那么按照月或者周的日期分區設計也許很有用， 而如果查

15、詢條件更多的是使用地區條件，可以考慮使用地區將表做列表類型的分 區。4、按照某個規則數據是否可以被均勻的分拆應該選擇盡量把數據均勻分拆的規則。 若每個分區儲存的數據量相當，那么 查詢性能的改善將與分區的數量相關。例如，把一張表分為 10個分區，命中單 個分區條件的查詢掃表性能將比未分區的情況下高 10倍。如果以上幾個方面的回答都是Yes,這樣的表可以通過分區策略來提高查詢 性能。如上面章節所述，在 Greenplum中，每個分區子表都對應一張獨立的數 據表，系統通過父子表之間的繼承關系來維護分區定義信息。如果過多的數據表進行了分區，會造成表對象數量過多，系統元數據急劇膨脹，給系統的運行和維 護

16、帶來很大負擔。因此，還要綜合考慮系統的表數據量情況， 才可決定是否對數 據表進行分區。基于以上原則，Greenplum 數據庫數據分區的使用規范如下：?在性能可以滿足的情況下，盡量不使用數據分區；?因會造成表對象數量過多，增加執行計劃生成的復雜性，禁止使用二級分區;?數據量在億級別以下，建議不要使用分區；?表的數據在單個實例的數據量在100萬級別以下，不需要分區；? 分區字段不可以UPDATE ,需要用delete + insert或者truncate + insert 替代實現。2.3.5 壓縮存儲Greenplum 數據表分兩種類型：heap 表和 AO 表(Append-optimize

17、d )。 在Greenplum數據庫中，需要對數據進行壓縮，數據表則需要設置為AO表。對數據表進行壓縮，可以減少磁盤占用空間，同時也減少了對IO資源的開銷(以 CPU資源換IO資源)。特別是在目前IO資源不足的硬件環境下，數據庫設計應 該盡可能多的使用AO表。建議在選擇壓縮儲存模式時，最好根據比較測試的結 果來確定。綜合以上考慮，數據表壓縮的設計規范如下：?數據量在百萬級以下的小表，不建議使用壓縮存儲；?不要在壓縮文件系統使用壓縮存儲；? 壓縮表建議統一使用 zlib壓縮算法，壓縮級別為 6 (appendonly=true, compresstype=zlib, compresslevel=

18、6);,此壓縮設置滿足大多數的使用 場景。?建議對數據倉庫中的記錄數超過 1億的事實表、歷史數據表采用壓縮存 儲；?所有歷史數據表、備份表、歸檔表統一使用壓縮存儲；2.3.6 索引設計在分布式數據庫GPDB中，應盡量避免使用索引。GPDB中大部分應用場 景是使用順序掃描。與傳統的 OLTP數據庫不同的是，Greenplum中數據表的 數據是分布在多個節點上的。這意味著每個節點都掃描全部數據的一小部分來查 找結果。如果使用了表分區，掃描的數據可能更少。通常，這種情況下使用索引 未必能提升性能。索引更易于改善OLTP類型的工作負載，因其返回很少量的數據，當情況合 適時查詢優化器會把索引作為獲取數據

19、的選擇， 而不是一味的全表掃描。添加索 引會帶來一些數據庫開銷，其必定占用相當的存儲空間，并且表更新時需維護索 引。需確保索引的創建在查詢工作負載中真正被使用到。 同時，需要檢查索引的 確對于查詢性能有顯著的改善（與順序掃描的性能相比）。Greenplum 支持B-tree索引和位圖（Bitmap）索引。因此，使用索引時， 需要綜合考慮以下問題：1、查詢工作負載類型：索引更適合于 OLTP類型的工作負載，其返回很少 量的數據，對于OLAP類型的查詢負載，在GPDB中索引通常作用不大；2、壓縮表：在查詢少量數據的情況下，索引能夠改善AO表上的查詢性能， 當情況合適時查詢優化器會把索引作為獲取數據

20、的選擇，而不是一味的全表掃 描。對于壓縮數據來說，索引訪問數據的方法是解壓需要的記錄而不是全部解壓；3、避免在頻繁更新的列上使用索引。在頻繁更新的列上創建索引，當該列被更新時，需要消耗大量的寫磁盤資源和 CPU計算資源；4、在高選擇性的列適合使用B-tree索引，選擇性指白是列中DISTINCT值 的數量除以表中的記錄 .例如，如果一張表中有 1000行記錄且有 800個 DISTINCT值，選擇性指數為0.8,這被認為是良好的。唯一索引總是具備 1.0 的選擇比，這是最好的情況；5、低選擇性的列適合使用bitmap索引；6、索引列用于關聯。經常關聯（JOIN）的COLUMN（比如外鍵）上建立

21、索引或 許可以改善JOIN的性能，因為其可以幫助查詢規劃器使用其他的關聯方法；7、索引列經常用在查詢條件中。對于大表來說，查詢語句 WHERE條件中 經常用到的列，可以考慮使用索引。綜合以上情況，結合Greenplum平臺的特點，索引設計的規范如下：?原則上，數據倉庫中的數據表不建立索引。只有提供給外部用戶訪問的 表，才考慮按用戶訪問特性，針對常用查詢字段建立索引；?對于跑批的中間表和臨時表，不允許創建索引；?對于記錄數在百萬級別以下的小表，建議不使用索引；?創建組合索引時，必須將經常作為查詢條件且可選擇性最大的列設置為索引的首列;?不允許創建冗余索引；?對于區別度高的索引，應使用 B-tre

22、e索引，例如賬號、合同號等等；對 于區別度低的索引，應使用 Bitmap索引，例如機構、產品類型等等；?創建組合索引時，建議列數不要超過 5歹1；?每張數據表的索引數，建議不超過 5個；?在創建和更新索引后，必須執行 Analyze操作，更新索引的統計信息；?在對大表進行數據加載的時候，如果存在索引，建議先刪除索引，待數 據加載完成，再重新創建索引；?對頻繁更新的數據表，應定期對其執行 reindex操作，以重建索引；?如果在分區表中使用了索引，不允許在子表上單獨創建和修改索引；通 常，刪除頂級分區的索引，系統會自動刪除相關子表的索引，但如果子 表的索引有缺失，將不能自動刪除子表的索引，需要一

23、一手動刪除。?不再使用的索引必須刪除；2.4 其他數據庫對象設計2.4.1 schema模式(Schema)是在DB內組織對象的一種邏輯結構。模式可以允許用戶在 一個DB內不同的模式之間使用相同 Name的對象(比如Table)。Schema命名 不允許出現中文字。Schema的規劃與創建建議由系統管理員或應用設計人員統規劃和設計。|不允許在系統的Schema下創建用戶表；Greenplum 的系統Schema如下:序號Schema名稱說明1.gp_toolkit提供系統管理方面的視圖2.Information_schema提供兀數據信息的視圖3.pg_catalog系統對象元數據表4.pg_

24、aosegAppend only 表的輔助兀數據表5.pg_toast大對象存儲6.pg_bitmapindex位圖索引對象存儲2.4.2 視圖視圖的設計規范建議如下：?視圖命名不允許使用雙引號包括視圖名，視圖名稱不允許出現中文字；? 在視圖中，不允許使用 ORDER BY語句；?對頻繁訪問，具有多個大表關聯，并含有復雜計算或排序的視圖，建議 修改為物理表；2.4.3 臨時表和中間表臨時表使用規范如下：?對于每天定期執行的后臺數據處理作業，建議不要使用臨時表，因為使 用臨時表，會造成每天都進行大量的數據表的創建和刪除，引起系統元 數據表的急劇膨脹，導致需要頻繁的進行系統表的 Vacuum操作，

25、從而 影響系統的使用和穩定性。?臨時表和中間表定義時必須顯示指定分布鍵。?臨時表和中間表，評估表數據量，建議大表統一米用壓縮表。第三章 SQL開發規范3.1 基本要求1、代碼行清晰、整齊、層次分明、結構性強，易于閱讀；2、代碼中應具備必要的注釋以增強代碼的可讀性和可維護性；3、代碼應充分考慮執行效率，保證代碼的高效性；3.2 WHERE 條件1、在 Where條件過濾中，應盡量將函數處理放在等式的右邊，以提高查 詢性能；2、對于日期(date、timestamp等)類型的字段判斷，條件值可直接使用字符串，GP會自動進行轉換。無需過多的使用類型轉換函數，如： to_dateWHERE call_

26、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') and t.z hours =(select to char(current timestamp - interva

27、l '1 minute', 'HH24')4、系統中很多采用日期分區的表，分區字段類型為數值型( integer) 式的左邊不要使用數值運算，否則會影響執行計劃對分區使用的準確性。問題示例：WHERE statis_date/100 可改寫為： ;5、在WHERE條件中錯誤的添加1<>1的判斷，會導致執行計劃混亂。 問題語句：SELECTB.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

28、 1<>1GROUP BY B.DVLPER CODE,A.CNTY ID3.3 分區字段使用如上述章節提到的分區表的使用原則，使用分期表是為了降低每次表掃描涉 及的數據量，已達到提升SQL處理效率的目的。如果SQL語句中沒有準確的使 用分區字段就會導致遍歷所有分區，導致 SQL執行效率低下。特別在多個分區表關聯時，每個分區表都需要制定分區字段的條件。除非業 務上有特殊要求必須要遍歷所有的(或大部分的)子分區 。3.4 表關聯1、表連接中的每個表應指定縮寫的別名，別名的命名盡量清晰可辨別；2、多表關聯的時候，建議所有的關聯寫成JOIN的形式，例如：而不允許寫成如下形式：3、建議一個

29、SQL語句中多表關聯的關聯表不要超過10張表；4、幾個大小差不多的表做關聯時，過濾性較強的優先做aJOIN ;5、在大/大/小三個表內關聯時，避免先把兩個大表進行 JOIN,除非過濾性 非常強；例如：pg_namespace為小表，其他2個表為大表6、在大/小/小三個表內聯時，優先把兩個小表進行 JOIN：SELECT *FROM (smalltableA AS A INNER JOIN smalltableB AS B ON A.key=B.key) INNER JOIN bigtable AS C ON C.key=A.key7、在關聯大表的時候，左右兩個連接表的關聯字段不能同時存在高重復

30、值 的情況，以免因重復記錄關聯產生巨大的中間結果，造成磁盤占用比例的大幅增長；例如：如果一個100萬的重復記錄表和一個1萬的重復記錄表關聯，結果 會高達100萬*1萬=100億條記錄；8、在使用小表 LEFT JOIN 超大表(記錄數過億)時，強烈建議把LEFT JOIN 修改為先INNER JOIN ,再LEFT JION的方式實現。這樣既可以提高性能，也 能避免Greenplum產生大量的臨時文件；因為在 Greenplum數據庫中，對于 LEFT JOIN語句，服務器會固定使用右表的記錄，構造 Hash表，然后用Hash Join的方式實現關聯；如果右表非常大，會導致 Hash表需要占用

31、大量的內存， 如果內存超出限制，系統會把 Hash表的內容，寫入到文件系統的臨時文件中， 如果右表是一個超大表，可能在執行此語句的時候，系統會寫入大量臨時文件， 造成系統占用空間大幅增加；如果是INNER JOIN 語句，系統會自動選擇用小表建立Hash表。例如：如下LEFT JOIN語句：其執行計劃如下：從執行計劃可以看出，系統會掃描右表aoddc_cicifci0_h ,對其所有數據建立一個Hash表；如果aoddc_cicifci0_h是一個超大表，那么LEFT JOIN可以改寫如下：9、表通過分布鍵關聯時，不要使用表達式字段的方式進行關聯，否則會導 致數據重分布，舉例如下：-錯誤的關聯

32、方式，導致數據重分布Select * from base_fs.aoddc_ciccrcc0_h AS ALEFT JOIN temp_result AS B ON trim(A.ci_cust_no)=B.ci_cust_no-正確的關聯方式Select * from base_fs.aoddc_ciccrcc0_h AS ALEFT JOIN temp result AS B ON A.ci cust no=B.ci cust no3.5 排序語句1、不要在視圖中使用Order By排序語句，在視圖中，排序語句會被忽略；2、ORDER BY語句執行成本很高，建議盡量避免使用；3、不要在大的

33、數據結果集上執行排序操作；4> Partition By、Union內部實現需要對數據排序，在數據量在千萬級別下， 差別不大，但如果數據量在億級別上，建議盡量使用 group by實現，盡量避免 order by操作，舉例如下：Select cust_no,cust_name from BigTableA UnionSelect cust_no,cust_name from BigTableB 建議改為group by實現：Select cust_no,cust_name from (Select cust_no,cust_name from BigTableAUnion ALLSele

34、ct cust_no,cust_name from BigTableB)AS PGroup by cust no,cust name3.6 嵌套子查詢建議子查詢嵌套的層次不要超過 4層；如果查詢過于復雜，應對查詢進行拆 分，分為多個較簡單的執行語句配合臨時表來實現；3.7 UNION / UNION ALL1、UNION操作，如果不需要去重，請用 UNION ALL替代。例如，如下語句：可替換為：從執行計劃的差異上，可看出，UNION ALL具有更好的性能，所以，如果 不需要去重，僅僅是合并數據集，應使用 UNION ALL ;2、不建議過多的使用UNION ALL。除了簡單的少量記錄的UNI

35、ON ALL操 作，對于很多復雜的子查詢，不建議超過 5個子句進行UNION ALL。如果大量 結果集需要UNION ALL ,可把所有結果集都插入到臨時表。這樣的效率比大量 的 UNION ALL 高。3.8 高效SQL寫法的建議1、在SQL語句的執行計劃中，應通過優化執行語句，盡量避免數據重分布 操作，可使用 Explain 命令檢查 SQL語句是否存在redistributed , broadcast 等操作，并檢查操作是否合理；例如：兩張表 base_fs.aoddc_ciccrcc0_h 和 base_fs.aoddc_cicifci0_h , 它 們的分布鍵一致，定義如下：SQL語句1寫法如下：其執行計劃如下：在執行計劃中，包含了 Redistribute Motion操作，就需要在節點之間重分 布數據；可將SQL語句優化，改寫如下，把分布鍵包含進關聯字段，可比較數 據重分布，改善性能：其執行計劃如下：2、在關聯字段中，盡量包含分布鍵作為關聯條件，避免數據重分布；3、在Where條件中，盡量保證每個節點的過濾后的結果集是均勻的，避 免數據傾斜