Überprüfen, welche Anweisungen Parallel Query für Aurora MySQL verwenden - Amazon Aurora

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Überprüfen, welche Anweisungen Parallel Query für Aurora MySQL verwenden

Im normalen Betrieb müssen Sie nichts Besonderes unternehmen, um Parallel Query zu nutzen. Erfüllt eine Abfrage die grundlegenden Anforderungen einer Parallelabfrage, entscheidet der Abfrageoptimierer bei jeder Abfrage automatisch, ob Parallel Query verwendet werden soll.

Wenn parallele Abfragen in Versuchen in einer Entwicklungs- oder Testumgebung nicht verwendet werden, kann dies daran liegen, dass Ihre Tabellen zu klein sind (zu wenige Zeilen oder zu wenig Datenvolumen). Die Daten für die Tabelle können sich auch vollständig im Pufferpool befinden, insbesondere bei Tabellen, die Sie kürzlich erstellt haben, um Experimente durchzuführen.

Während Sie die Cluster-Leistung überwachen oder optimieren, müssen Sie entscheiden, ob parallele Abfragen in den richtigen Kontexten verwendet werden. Sie haben die Möglichkeit, das Datenbankschema, die Einstellungen, die SQL-Abfragen oder sogar die Cluster-Topologie und die Anwendungsverbindungseinstellungen nachzubessern, um die Vorteile der Funktion nutzen zu können.

Um zu prüfen, ob eine Abfrage Parallel Query verwendet, prüfen Sie den Abfrageausführungsplan (auch als „Erläuterungsplan“ bezeichnet), indem Sie die Anweisung EXPLAIN ausführen. Anhand unserer Beispiele können Sie nachvollziehen, wie sich SQL-Anweisungen, SQL-Klauseln und SQL-Ausdrücke auf die EXPLAIN-Ausgabe von Parallel Query auswirken: SQL-Konstrukte für Parallel Query in Aurora MySQL

Das nachfolgende Beispiel verdeutlicht den Unterschied zwischen einem normalen Abfrageplan und einem parallelen Abfrageplan (Parallel Query). Dieser Erläuterungsplan stammt aus Abfrage 3 aus dem TPC-H-Benchmark. Viele der Beispielabfragen aus diesem Abschnitt verwenden die Tabellen aus dem TPC-H-Dataset. Sie können die Tabellendefinitionen, Abfragen und das dbgen-Programm abrufen, das Beispieldaten von der TPC-h-Website generiert. 

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;

Standardmäßig hat die Abfrage möglicherweise einen Plan wie den folgenden. Wenn im Abfrageplan kein Hash-Join verwendet wird, stellen Sie sicher, dass zuerst die Optimierung aktiviert ist. 

+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
| 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) |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+

Sie können bei Aurora MySQL 3 den Hash-Join auf Sitzungsebene aktivieren, indem Sie die folgende Anweisung ausgeben.

SET optimizer_switch='block_nested_loop=on';

Für Aurora MySQL Version 2.09 und höher setzen Sie denaurora_disable_hash_join-DB-Parameter oder DB-Cluster-Parameter auf 0 (aus). Durch Deaktivierung von aurora_disable_hash_join wird der Wert von optimizer_switch auf hash_join=on gesetzt.

Nachdem Sie den Hash-Join aktiviert haben, versuchen Sie erneut, die EXPLAIN-Anweisung auszuführen. Informationen zur effektiven Verwendung von Hash-Joins finden Sie unter Optimierung von großen Aurora-MySQL-Join-Abfragen mit Hash-Joins.

Bei aktiviertem Hash-Join, aber deaktivierter paralleler Abfrage kann die Abfrage einen Plan wie den folgenden haben, der Hash-Join, aber keine parallele Abfrage verwendet. 

+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
| 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) |
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+

Nachdem die parallele Abfrage aktiviert wurde, können zwei Schritte in diesem Abfrageplan die parallele Abfrageoptimierung verwenden, wie unter der Spalte Extra in der Ausgabe EXPLAIN angezeigt. Die I/O-intensive und CPU-intensive Verarbeitung aus diesen Schritten wird in die Speicherschicht hinabgestuft. 

+----+...+--------------------------------------------------------------------------------------------------------------------------------+
| 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) |
+----+...+--------------------------------------------------------------------------------------------------------------------------------+

Hinweise zur Interpretierung der EXPLAIN-Ausgabe einer Parallelabfrage und der Teile von SQL-Anweisungen, für die Parallel Query in Frage kommt, lesen Sie im Beitrag SQL-Konstrukte für Parallel Query in Aurora MySQL.

Aus der nachfolgenden Beispielausgabe geht hervor, welche Ergebnisse zustande kommen, wenn die vorherige Abfrage auf einer db.r4.2xlarge-Instance mit kaltem Bufferpool ausgeführt wird. Die Abfrage wird mit Parallel Query erheblich schneller ausgeführt.

Anmerkung

Weil Durchlaufzeiten von vielen Umgebungsfaktoren abhängen, können Ihre Ergebnisse anders lauten. Führen Sie deshalb stets eigene Leistungstests durch. Damit prüfen Sie die Ergebnisse gegen Ihre eigene Umgebung, Workloads und andere Faktoren. 

-- 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)

In vielen Beispielabfragen aus diesem Abschnitt werden Tabellen aus diesem TPC-H-Dataset verwendet, besonders häufig die PART-Tabelle mit 20 Millionen Zeilen und folgender Definition. 

+---------------+---------------+------+-----+---------+-------+
| 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    |       |
+---------------+---------------+------+-----+---------+-------+

Durch Versuchsläufe mit Ihrer Workload gewinnen Sie ein Gefühl dafür, ob einzelne SQL-Anweisungen von Parallel Query profitieren. Anschließend können Sie mit den folgenden Überwachungstechniken nachprüfen, wie oft Parallel Query im Laufe der Zeit in echten Workloads verwendet wird. Für tatsächliche Workloads gelten zusätzliche Faktoren (z. B. Obergrenzen für gleichzeitige Abfragen).