本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 確認哪些陳述式使用平行查詢 在一般操作中，您不需要執行任何特殊動作即可善用平行查詢。在查詢符合平行查詢的必要需求之後，查詢最佳化器會自動決定是否要針對每個特定查詢使用平行查詢。 如果您在開發或測試環境中執行實驗，則可能發現並未使用平行查詢，因為資料表的資料列數目太小或整個資料量太少。資料表的資料也可能完整在緩衝集區中，尤其是您最近建立來執行實驗的資料表。 監控或調整叢集效能時，您需要決定是否要在適當內容中使用平行查詢。您可能需要調整資料庫結構描述、設定、SQL 查詢，甚至是叢集拓撲和應用程式連線設定，才能完善利用此功能。 若要檢查查詢是否使用平行查詢，請執行 [EXPLAIN](https://dev.mysql.com/doc/refman/5.7/en/execution-plan-information.html) 陳述式，以檢查查詢執行計畫 (又稱為「explain plan (解釋計畫)」)。如需 SQL 陳述式、子句和運算式如何影響平行查詢 `EXPLAIN` 輸出的範例，請參閱[Aurora MySQL 中平行查詢的 SQL 建構](aurora-mysql-parallel-query-sql.md)。 以下範例示範傳統查詢計畫與平行查詢計劃之間的差異。這個解釋計畫來自 TPC-H 基準測試的查詢 3。本節中的許多查詢範例都是使用來自 TPC-H 資料集的資料表。您可以從 [TPC-H 網站](http://www.tpc.org/tpch/)取得資料表定義、查詢和產生範例資料的 `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 MySQL 第 3 版，您可以透過發出以下陳述式在工作階段層級開啟雜湊聯結。 ``` SET optimizer_switch='block_nested_loop=on'; ``` 針對 Aurora MySQL 2.09 及更高版本，您可以將 `aurora_disable_hash_join` 資料庫參數或資料庫叢集參數設定為 `0` (關閉)。若關閉 `aurora_disable_hash_join`，`optimizer_switch` 的值將為 `hash_join=on`。 開啟雜湊聯結之後，請嘗試再次執行 `EXPLAIN` 陳述式。如需如何有效使用雜湊聯結的相關資訊，請參閱[使用雜湊聯結，將大型 Aurora MySQL 聯結查詢最佳化](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin)。 開啟雜湊聯結但關閉平行查詢時，查詢具備的計劃可能如下所示；該計劃會使用雜湊聯結，但不會使用平行查詢。 ``` +----+-------------+----------+...+-----------+-----------------------------------------------------------------+ | 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` 資料欄下所示。系統會將這些步驟的輸入/輸出密集和 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) | +----+...+--------------------------------------------------------------------------------------------------------------------------------+ ``` 如需如何解譯平行查詢之 `EXPLAIN` 輸出的相關資訊，以及平行查詢可以套用至 SQL 陳述的哪些部分，請參閱[Aurora MySQL 中平行查詢的 SQL 建構](aurora-mysql-parallel-query-sql.md)。 以下範例輸出顯示在具有冷緩衝集區的 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 資料集的資料表，尤其是 `PART` 資料表，其具有 2 千萬個資料列和下列定義。 ``` +---------------+---------------+------+-----+---------+-------+ | 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 陳述式是否可以善用平行查詢。然後，使用下列監控技術來協助驗證平行查詢在一段時間內用於真正工作負載的頻率。對於真正的工作負載，會套用並行限制之類的額外因素。