# Aurora MySQL の並列クエリを使用しているステートメントの確認 一般的な操作では、パラレルクエリを利用するために特別なアクションを実行する必要はありません。クエリがパラレルクエリの必須要件を満たした後、クエリオプティマイザは、特定のクエリごとにパラレルクエリを使用するかどうかを自動的に決定します。 開発環境やテスト環境で実験を行うと、テーブルの行数や全体のデータ量が少ないためにパラレルクエリが使用されないことがあります。特に実験を実行するために最近作成したテーブルの場合、テーブルのデータも完全にバッファプールにある可能性があります。 クラスターのパフォーマンスをモニタリングまたは調整する場合は、パラレルクエリが適切な状況で使用されているかどうかを確認する必要があります。この機能を利用するには、データベースのスキーマ、設定、SQL クエリ、またはクラスタートポロジとアプリケーションの接続設定を調整する必要があります。 クエリでパラレルクエリが使用されているかどうかを確認するには、[EXPLAIN](https://dev.mysql.com/doc/refman/5.7/en/execution-plan-information.html) ステートメントを実行してクエリプラン (explain プラン) を確認します。パラレルクエリの `EXPLAIN` 出力に SQL ステートメント、句および表現がどのように影響するかの例は、「[Aurora MySQL の並列クエリ用の SQL コンストラクト](aurora-mysql-parallel-query-sql.md)」を参照してください。 次の例は、従来のクエリプランとパラレルクエリプランの違いを示しています。この explain プランは、TPC-H ベンチマークのクエリ 3 のものです。このセクションのサンプルクエリの多くは、TPC-H データセットのテーブルを使用しています。テーブル定義、クエリ、サンプルデータを生成する `dbgen` プログラムは、[TPC-H のウェブサイト](http://www.tpc.org/tpch/)から入手できます。 ``` 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` DB パラメーターまたは DB クラスターパラメータを `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) | +----+-------------+----------+...+-----------+-----------------------------------------------------------------+ ``` パラレルクエリが有効になると、`EXPLAIN` 出力の `Extra` カラムに表示されるように、このクエリプランの 2 つのステップでパラレルクエリの最適化が使用できます。これらのステップに対する 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) | +----+...+--------------------------------------------------------------------------------------------------------------------------------+ ``` パラレルクエリの出力およびパラレルクエリが適用できる SQL ステートメントの部分の `EXPLAIN` 出力を解釈する方法については、「[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 データセットのテーブル、特に 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 ステートメントがパラレルクエリを利用できるかどうかを理解してください。次に、以下のモニタリング方法を使用して、実際のワークロードでパラレルクエリが使用される頻度を時間をかけて確認します。実際のワークロードでは、同時実行制限などの追加の要素が適用されます。