本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
驗證哪些語句使用 parallel 查詢 Aurora My SQL
在一般操作中，您不需要執行任何特殊動作即可善用平行查詢。在查詢符合平行查詢的必要需求之後，查詢最佳化器會自動決定是否要針對每個特定查詢使用平行查詢。
如果您在開發或測試環境中執行實驗，則可能發現並未使用平行查詢，因為資料表的資料列數目太小或整個資料量太少。資料表的資料也可能完整在緩衝集區中，尤其是您最近建立來執行實驗的資料表。
監控或調整叢集效能時，您需要決定是否要在適當內容中使用平行查詢。您可以調整資料庫結構描述、設定、SQL查詢，甚至是叢集拓撲和應用程式連線設定，以利用此功能。
若要檢查查詢是否使用 parallel 查詢，請執行陳述式來檢查查詢計畫 (也稱為「說EXPLAINEXPLAIN輸出的範例，請參閱SQL構造在 Aurora 我的 parallel 查詢 SQL。
以下範例示範傳統查詢計畫與平行查詢計劃之間的差異。這個說明計劃來自 TPC-H 基準測試的查詢 3。本節中的許多範例查詢都使用 TPC-H 資料集中的資料表。您可以從 TPC-h 網站獲取表定義，查詢和生成示例數據的dbgen
EXPLAIN SELECT l_orderkey, sum(l_extendedprice * (1 - l_discount)) AS revenue, o_orderdate, o_shippriority FROM customer, orders, lineitem WHERE c_mktsegment = 'AUTOMOBILE' AND c_custkey = o_custkey AND l_orderkey = o_orderkey AND o_orderdate < date '1995-03-13' AND l_shipdate > date '1995-03-13' GROUP BY l_orderkey, o_orderdate, o_shippriority ORDER BY revenue DESC, o_orderdate LIMIT 10;
根據預設，查詢可能具有如下所示的計畫。如果查詢計劃中沒有看到雜湊聯結使用，請確定先開啟最佳化。
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
| 1 | SIMPLE | customer | NULL | ALL | NULL | NULL | NULL | NULL | 1480234 | 10.00 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | orders | NULL | ALL | NULL | NULL | NULL | NULL | 14875240 | 3.33 | Using where; Using join buffer (Block Nested Loop) |
| 1 | SIMPLE | lineitem | NULL | ALL | NULL | NULL | NULL | NULL | 59270573 | 3.33 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
對於 Aurora 我的SQL版本 3，您可以透過發出下列陳述式在工作階段層級開啟雜湊聯結。
SET optimizer_switch='block_nested_loop=on';
對於 Aurora 我的SQL版本 2.09 及更高版本，您可以將aurora_disable_hash_join資料庫參數或資料庫叢集參數設定為 0 (關閉)。若關閉 aurora_disable_hash_join，optimizer_switch 的值將為 hash_join=on。
開啟雜湊聯結之後，請嘗試再次執行 EXPLAIN 陳述式。如需如何有效使用雜湊聯結的相關資訊，請參閱使用雜湊聯結，將大型 Aurora MySQL 聯結查詢最佳化。
開啟雜湊聯結但關閉平行查詢時，查詢具備的計劃可能如下所示；該計劃會使用雜湊聯結，但不會使用平行查詢。
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
| id | select_type | table |...| rows | Extra |
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
| 1 | SIMPLE | customer |...| 5798330 | Using where; Using index; Using temporary; Using filesort |
| 1 | SIMPLE | orders |...| 154545408 | Using where; Using join buffer (Hash Join Outer table orders) |
| 1 | SIMPLE | lineitem |...| 606119300 | Using where; Using join buffer (Hash Join Outer table lineitem) |
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
在開啟平行查詢之後，此解釋計劃中的兩個步驟可以使用平行查詢最佳化，如 Extra 輸出中的 EXPLAIN 資料欄下所示。這些步驟的 I/O 密集CPU型和密集型處理會向下推送至儲存層。
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
| id |...| Extra |
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
| 1 |...| Using where; Using index; Using temporary; Using filesort |
| 1 |...| Using where; Using join buffer (Hash Join Outer table orders); Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra) |
| 1 |...| Using where; Using join buffer (Hash Join Outer table lineitem); Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra) |
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
如需有關如何解譯 parallel 查詢的EXPLAIN輸出，以及 parallel 查詢可套用之SQL陳述式部分的資訊，請參閱SQL構造在 Aurora 我的 parallel 查詢 SQL。
以下範例輸出顯示在具有冷緩衝集區的 db.r4.2xlarge 執行個體上執行平行查詢的結果。使用平行查詢時，查詢的執行速度會變得相當快。
注意
因為時機取決於許多環境因素，所以您的結果可能有所不同。一律進行您自己的效能測試，以利用自己的環境、工作負載等等來確認結果。
-- Without parallel query
+------------+-------------+-------------+----------------+
| l_orderkey | revenue | o_orderdate | o_shippriority |
+------------+-------------+-------------+----------------+
| 92511430 | 514726.4896 | 1995-03-06 | 0 |
.
.
| 28840519 | 454748.2485 | 1995-03-08 | 0 |
+------------+-------------+-------------+----------------+
10 rows in set (24 min 49.99 sec)
-- With parallel query
+------------+-------------+-------------+----------------+
| l_orderkey | revenue | o_orderdate | o_shippriority |
+------------+-------------+-------------+----------------+
| 92511430 | 514726.4896 | 1995-03-06 | 0 |
.
.
| 28840519 | 454748.2485 | 1995-03-08 | 0 |
+------------+-------------+-------------+----------------+
10 rows in set (1 min 49.91 sec)
本節中的許多範例查詢都使用此 TPC-H 資料集中的資料表，尤其是具有 2000 萬列資料列的資料PART表，以及下列定義。
+---------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------+------+-----+---------+-------+
| p_partkey | int(11) | NO | PRI | NULL | |
| p_name | varchar(55) | NO | | NULL | |
| p_mfgr | char(25) | NO | | NULL | |
| p_brand | char(10) | NO | | NULL | |
| p_type | varchar(25) | NO | | NULL | |
| p_size | int(11) | NO | | NULL | |
| p_container | char(10) | NO | | NULL | |
| p_retailprice | decimal(15,2) | NO | | NULL | |
| p_comment | varchar(23) | NO | | NULL | |
+---------------+---------------+------+-----+---------+-------+
試驗您的工作負載，以瞭解個別SQL陳述式是否可以利用 parallel 查詢。然後，使用下列監控技術來協助驗證平行查詢在一段時間內用於真正工作負載的頻率。對於真正的工作負載，會套用並行限制之類的額外因素。
