背景信息

您在創建表時，可以定義一個或多個列為排序鍵，當有數據寫入到表中，可以對該表按照排序鍵進行排序重組。

表排序后可以加速范圍過濾查詢，數據庫會對每固定行記錄每一列的min、max值。如果在查詢時使用范圍過濾條件，AnalyticDB PostgreSQL版的查詢引擎可以根據min、max值在對表進行掃描（SCAN）時跳過不滿足過濾條件的數據塊（Block）。

例如，一張表存儲了7年的數據，這張表的數據按照時間字段排序存儲。如果您需要查詢一個月的數據，那么只需要掃描 1/(7*12) 的數據，有98.8%的數據塊在掃描時可以被過濾。但如果數據沒有按照時間排序的話，可能所有磁盤上的數據塊都要被掃描。

AnalyticDB PostgreSQL版支持兩種排序方式：

• 組合排序（SORT）：適用于過濾條件是排序鍵的前綴子集，例如查詢過濾條件包含首列排序鍵的場景。

• 多維排序（Multisort）：給每一個排序鍵分配相同的權重，更適合于查詢條件包含任意過濾條件子集的場景。

如何選擇排序鍵

• 當您的查詢SQL的等值條件或范圍條件經常包含幾個固定列，可以考慮將這些列作為排序鍵，從而利用數據排序結合粗糙索引，加速這類SQL的查詢速度。一般情況下應該考慮使用組合排序。

• 當您的查詢SQL包含的過濾條件不是固定的列，可以使用多維排序來加速查詢。由于多維排序在排序過程中還需要進行一些額外的數據組織工作，所以一般情況下多維排序的耗時會比組合排序的耗時更久。

  說明

  多維排序最多支持8列。

• 當您的查詢SQL經常使用固定的列作為JOIN條件，可以將JOIN列同時設置為分布鍵和排序鍵，從而使用MergeJoin代替HashJoin，由于底層數據已經按照JOIN列排序，可以跳過MergeJoin耗時較高的排序階段。

組合排序和多維排序的性能對比

以下內容將對同樣的兩張表分別進行組合排序和多維排序，比較兩種排序方式在不同場景下對不同查詢的性能影響。

1. 創建兩張測試表并設置表的排序鍵，表中包含4列，分別為id、num1、num2、value，其中id、num1、num2為排序鍵。語句如下：

   CREATE TABLE test(id int, num1 int, num2 int, value varchar) 
   with(APPENDONLY=TRUE, ORIENTATION=column)
   DISTRIBUTED BY(id)
   ORDER BY(id, num1, num2);
   
   CREATE TABLE test_multi(id int, num1 int, num2 int, value varchar) 
   with(APPENDONLY=TRUE, ORIENTATION=column)
   DISTRIBUTED BY(id)
   ORDER BY(id, num1, num2);

2. 插入一千萬行測試數據，語句如下：

   INSERT INTO test(id, num1, num2, value) select g,
   (random()*10000000)::int,
   (random()*10000000)::int,
   (array['foo', 'bar', 'baz', 'quux', 'boy', 'girl', 'mouse', 'child', 'phone'])[floor(random() * 10 +1)]
   FROM generate_series(1, 10000000) as g;
   
   INSERT INTO test_multi SELECT * FROM test;

   查詢兩張表中數據的總行數：

   • SELECT count(*) FROM test;

     返回信息如下：

       count
     ----------
      10000000
     (1 row)

   • SELECT count(*) FROM test_multi;

     返回信息如下：

       count
     ----------
      10000000
     (1 row)

3. 對兩張表分別進行組合排序和多維排序。

   對test表進行組合排序：

   SORT test;

   對test_multi表進行多維排序：

   MULTISORT test_multi;

4. 等值查詢性能對比如下：

   • Q1查詢：過濾條件為首列排序鍵。

     SELECT * FROM test WHERE id = 100000;
     SELECT * FROM test_multi WHERE id = 100000;

   • Q2查詢：過濾條件為第二列排序鍵。

     SELECT * FROM test WHERE num1 = 8766963;
     SELECT * FROM test_multi WHERE num1 = 8766963;

   • Q3查詢：過濾條件為第二三列排序鍵。

     SELECT * FROM test WHERE num1 = 100000 AND num2=2904114;
     SELECT * FROM test_multi WHERE num1 = 100000 AND num2=2904114;

   性能對比結果如下：

   排序模式	Q1	Q2	Q3
   組合排序	0.026s	3.95s	4.21s
   多維排序	0.55s	0.42s	0.071s

5. 范圍查詢性能對比如下：

   • Q1查詢：過濾條件為首列排序鍵。

     SELECT count(*) FROM test WHERE id>5000 AND id < 100000;
     SELECT count(*) FROM test_multi WHERE id>5000 AND id < 100000;

   • Q2查詢：過濾條件為第二列排序鍵。

     SELECT count(*) FROM test WHERE num1 >5000 AND num1 <100000;
     SELECT count(*) FROM test_multi WHERE num1 >5000 AND num1 <100000;

   • Q3查詢：過濾條件為第二三列排序鍵。

     SELECT count(*) FROM test WHERE num1 >5000 AND num1 <100000 AND num2 < 100000;
     SELECT count(*) FROM test_multi WHERE num1 >5000 AND num1 <100000 AND num2 < 100000;

   性能對比結果：

   排序方式	Q1	Q2	Q3
   組合排序	0.07s	3.35s	3.64s
   多維排序	0.44s	0.28s	0.047s

結論如下：

• 對于Q1查詢場景，由于包含排序鍵的首列，所以組合排序的效果較好，而多維排序則會相對性能弱一些。

• 對于Q2查詢場景，由于不包含排序鍵的首列，組合排序基本上失效了，而多維排序依然能維持比較穩定的性能提升。

• 對于Q3查詢場景，由于不包含排序鍵的首列，組合排序依然起不到很好的效果，并且由于比較條件的增加，需要額外的比較開銷，時間更長。而多維排序表現出更好的性能，這是因為在查詢時，過濾條件包含的多維排序鍵越多，性能越好。

排序加速計算

當您執行SORT <tablename>后，系統會對表數據進行排序，當數據完成排序后，AnalyticDB PostgreSQL版即可利用數據的物理順序，將SORT算子下推到存儲層進行計算加速。如果您的SQL可以利用底層的數據順序，則會從中獲得加速收益，該特性可以基于排序鍵加速SORT、AGG、JOIN算子。

以下示例將在測試表far中執行同樣的查詢語句，對比排序加速前與排序加速后查詢時間的差距。

1. 創建測試表far，語句如下：

   CREATE TABLE far(a int,  b int)
   WITH (APPENDONLY=TRUE, COMPRESSTYPE=ZSTD, COMPRESSLEVEL=5)
   DISTRIBUTED BY (a)  --分布鍵
   ORDER BY (a);       --排序鍵

2. 寫入一百萬行數據，語句如下：

   INSERT INTO far VALUES(generate_series(0, 1000000), 1);

3. 數據導入完成后，對數據進行排序，語句如下：

   SORT far;

查詢性能對比如下：

• ORDER BY加速

  • 排序加速前（未排序）

  • 排序加速后

• GROUP BY加速

  • 排序加速前（未排序）

  • 排序加速后

• JOIN加速

  • 排序加速前（未排序）

  • 排序加速后

    說明

    JOIN排序加速需要關閉ORCA功能，打開mergejoin功能，語句如下：

    SET enable_mergejoin TO on;
    SET optimizer TO off;