Übersicht über Parallel Query Planen eines Parallel Query-Clusters Erstellen eines Parallel Query-Clusters Aktivieren und Deaktivieren von parallelen Abfragen Aktualisieren eines Parallelabfrageclusters Leistungsoptimierung Erstellen von Schema-Objekten Überprüfen der Parallel Query-Nutzung Überwachung Parallel Query und SQL-Konstrukte

Arbeiten mit Parallel Query für Amazon Aurora MySQL

Dieses Thema beschreibt, wie Sie Amazon-Aurora-MySQL-kompatible Edition Parallel Query optimal nutzen. Diese Funktion verwendet für bestimmte datenintensive Abfragen einen speziellen Verarbeitungspfad. Dabei kommt zum Tragen, dass die Architektur von Aurora verschiedene Speicherquellen nutzt. Parallel Query ist am wirkungsvollsten in Verbindung mit Aurora MySQL DB-Clustern, deren Tabellen Millionen Zeilen und analytische Abfragen unterstützen, deren Abarbeitung Minuten oder Stunden dauert.

Inhalt

Übersicht über Parallel Query für Aurora MySQL

Aurora MySQL Parallel Query ist eine Optimierung, die bei der Verarbeitung datenintensiver Abfragen einen Teil der I/O-Operationen und Berechnungen parallelisiert. Die parallelisierten Vorgänge beinhalten das Abrufen von Zeilen aus dem Speicher, das Extrahieren von Spaltenwerten und das Bestimmen der Zeilen, die den Bedingungen der WHERE-Klausel und der JOIN-Klauseln entsprechen. Diese datenintensive Arbeit wird auf der Ebene des verteilten Speichers von Aurora an mehrere Knoten in der verteilten Speicherschicht delegiert (aus Datenbanksicht herabgestuft). Ohne eine Parallelabfrage leitet jede Abfrage die gescannten Daten zu einem einzigen Knoten innerhalb des Aurora MySQL-Clusters (Hauptknoten) und die Verarbeitung jeglicher Abfragen erfolgt dort.

Tipp

Die PostgreSQL-Datenbank-Engine hat auch eine Funktion, die auch „parallel query bzw. Paralleabfragen“ genannt wird. Diese Funktion steht in keinem Zusammenhang mit der parallelen Abfrage von Aurora.

Wenn die Funktion für parallele Abfragen aktiviert ist, bestimmt die Aurora-MySQL-Engine automatisch, wann Abfragen von Nutzen sein können, ohne dass SQL-Änderungen wie Hinweise oder Tabellenattribute erforderlich sind. In den folgenden Abschnitten lesen Sie, in welchen Fällen Abfragen parallelisiert werden. Dabei erfahren Sie auch, wie Parallelabfragen nur dann eingesetzt werden, wenn sie den größten Nutzen bringen.

Anmerkung

Die Funktion für die Optimierung der parallelen Abfrageausführung ist besonders bei Abfragen sinnvoll, die mehrere Minuten oder Stunden in Anspruch nehmen. Aurora MySQL führt in der Regel keine parallele Abfrageoptimierung für kostengünstige Abfragen durch. Es führt auch im Allgemeinen keine parallele Abfrageoptimierung durch, wenn ein anderes Optimierungsverfahren geeigneter wäre (z. B. Abfrage-Caching, Caching im Bufferpool oder Index-Lookups). Wenn Sie der Meinung sind, dass die parallele Abfrageausführung anders als erwartet angewendet wird, lesen Sie den Abschnitt Überprüfen, welche Anweisungen Parallel Query verwenden.

Vorteile

Mit parallelen Abfragen können Sie datenintensive analytische Abfragen für Aurora MySQL-Tabellen ausführen. In vielen Fällen verbessert sich die Leistung im Vergleich mit herkömmlichen Verfahren, in denen Abfragen arbeitsteilig verarbeitet werden, um mehrere Größenordnungen.

Vorteile der parallelen Abfrageausführung:

Höhere I/O-Leistung, weil physische Leseanforderungen auf mehrere Speicherknoten parallelisiert werden.
Reduzierter Netzwerkverkehr. Aurora überträgt nicht komplette Datenseiten von den Speicherknoten zum Hauptknoten, um dort überflüssige Zeilen und Spalten herauszufiltern. Aurora überträgt stattdessen kompakte Tupel, die nur die Spaltenwerte enthalten, die für den Ergebnissatz erforderlich sind.
Niedrigere CPU-Last im Hauptknoten, weil die Funktionsverarbeitung, Zeilenfilterung und Spaltenprojektion für die WHERE-Klausel herabgestuft werden.
Weniger Speicherdruck im Bufferpool. Die von der parallelen Abfrage verarbeiteten Seiten werden dem Bufferpool nicht hinzugefügt. Dieser Ansatz reduziert die Wahrscheinlichkeit, dass ein datenintensiver Scan häufig verwendete Daten aus dem Bufferpool entfernt.
Möglicherweise weniger Datenduplikate in der ETL-Pipeline (Extract, Transform, Load), weil langwierige analytische Abfragen auf Bestandsdaten ausgeführt werden können.

Architektur

Parallele Abfragen machen sich die maßgeblichen Architekturprinzipien von Aurora MySQL zunutze: Entkopplung zwischen Datenbank-Engine und Speichersubsystem und weniger Netzwerkdatenverkehr durch Optimierung von Kommunikationsprotokollen. Aurora MySQL verwendet diese Techniken, um schreibintensive Operationen wie Redo-Protokoll-Verarbeitung zu beschleunigen. Parallel Query wendet die gleichen Prinzipien auf Leseoperationen an.

Anmerkung

Die Architektur von Aurora MySQL Parallel Query ist anders als die ähnlich benannter Funktionen in anderen Datenbanksystemen. Aurora MySQL Parallel Query ist kein symmetrisches Multiprocessing (SMP) und ist daher nicht von der CPU-Kapazität des Datenbankservers abhängig. Die Parallelverarbeitung erfolgt auf der Speicherschicht, völlig losgelöst vom Aurora MySQL-Server, der als Abfragekoordinator fungiert.

Ohne eine Parallelabfrage beinhaltet die Verarbeitung einer Aurora-Abfrage standardmäßig die Übertragung von Rohdaten an einen Einzelknoten innerhalb des Aurora-Clusters (dem Hauptknoten). Aurora führt dann die gesamte weitere Verarbeitung für diese Abfrage in einem einzigen Thread auf diesem einzelnen Knoten durch. Parallel Query delegiert einen Großteil dieser I/O- und CPU-intensiven Arbeit an Knoten aus der Speicherschicht. Nur die kompakten Zeilen aus dem Ergebnissatz werden an den Hauptknoten zurück übertragen. Die Zeilen sind dann bereits gefiltert und die Spaltenwerte bereits extrahiert und umgewandelt. Der Leistungsvorteil ergibt sich aus dem reduzierten Netzwerkdatenverkehr, einer niedrigeren CPU-Last im Hauptknoten und der Parallelisierung der I/O-Vorgänge aller Speicherknoten. Wie viele E/A-Vorgänge, Filterungen und Projektionen parallel ablaufen, ist unabhängig von der Anzahl der DB-Instances im Aurora-Cluster, der die Abfrage ausführt.

Voraussetzungen

Um alle Funktionen der parallelen Abfrage verwenden zu können, wird ein Aurora MySQL-DB-Cluster benötigt, auf dem Version 2.09 und höher ausgeführt wird. Wenn Sie bereits einen Cluster haben, den Sie mit der parallelen Abfrage verwenden möchten, können Sie ihn auf eine kompatible Version aktualisieren und anschließend die parallele Abfrage einschalten. Stellen Sie in diesem Fall sicher, dass Sie das Upgrade-Verfahren unter Wichtige Punkte bei einem Upgrade für parallele Abfragen befolgen, da die Namen der Konfigurationseinstellungen und Standardwerte in diesen neueren Versionen unterschiedlich sind.

Die DB-Instances in Ihrem Cluster müssen die db.r*-Instance-Klassen verwenden.

Stellen Sie sicher, dass die Hash-Join-Optimierung für Ihren Cluster aktiviert ist. Um zu erfahren wie dies geht, vgl. Hash-Join für parallele Abfrage-Cluster aktivieren.

Zum Anpassen von Parametern wie aurora_parallel_query und aurora_disable_hash_join benötigen Sie eine benutzerdefinierte Parametergruppe, die Sie mit dem Cluster verwenden. Sie können diese Parameter für jede DB-Instance einzeln angeben, indem Sie eine DB-Parametergruppe verwenden. Es wird jedoch empfohlen, sie in einer DB-Cluster-Parametergruppe anzugeben. Auf diese Weise übernehmen alle DB-Instances in Ihrem Cluster die gleichen Einstellungen für diese Parameter.

Einschränkungen

Parallele Abfragen unterliegen folgenden Einschränkungen:

Parallelabfragen werden mit der DB-Cluster-Speicherkonfiguration Aurora I/O-Optimized nicht unterstützt.
Sie können eine parallele Abfrage nicht mit den Instance-Klassen db.t2 oder db.t3 verwenden. Diese Einschränkung gilt auch dann, wenn Sie eine Parallelabfrage mit dem SQL-Hinweis aurora_pq_force anfordern.
Die parallele Abfrage gilt nicht für Tabellen, die das Zeilenformat COMPRESSED oder REDUNDANT verwenden. Verwenden Sie die Zeilenformate COMPACT oder DYNAMIC für Tabellen, die Sie mit der parallelen Abfrage verwenden möchten.
Aurora verwendet einen kostenbasierten Algorithmus, um zu bestimmen, ob der parallele Abfragemechanismus für jede SQL-Anweisung verwendet werden soll. Die Verwendung bestimmter SQL-Konstrukte in einer Anweisung kann eine parallele Abfrage verhindern oder eine parallele Abfrage für diese Anweisung unwahrscheinlich machen. Hinweise zur Kompatibilität von SQL-Konstrukten mit parallelen Abfragen finden Sie unter Zusammenwirken von Parallel Query und SQL-Konstrukten.
Jede Aurora-DB-Instance kann nur eine bestimmte Anzahl Parallelabfrage-Sitzungen gleichzeitig leisten. In Abfragen, die mehrere Komponenten mit paralleler Abfrageausführung enthalten (z. B. Unterabfragen, Join-Abfragen oder UNION-Operatoren), werden diese Phasen nacheinander ausgeführt. Die Anweisung zählt stets nur als einzelne Parallelabfrage-Sitzung. Wenn Sie überwachen möchten, wie viele Sitzungen derzeit geöffnet sind, verwenden Sie die Parallel-Query-Statusvariablen. Um herauszufinden, wie viele gleichzeitige Sitzungen eine DB-Instance maximal zulässt, fragen Sie die Statusvariable a Aurora_pq_max_concurrent_requests.
Die parallele Abfrage ist in allen anderen AWS-Regionen verfügbar, die Aurora unterstützt. Für die meisten AWS-Regionen ist die mindestens erforderliche Aurora-MySQL-Version für die Verwendung der parallelen Abfrage 2.09.
Parallelabfragen wurden entwickelt, um die Leistung datenintensiver Abfragen zu verbessern. Diese Funktion ist nicht für einfache Abfragen konzipiert.
Wir empfehlen, Leserknoten für SELECT-Anweisungen zu verwenden, insbesondere für datenintensive Anweisungen.

I/O-Kosten bei Parallelabfragen

Wenn Ihr Aurora MySQL Cluster eine parallele Abfrage verwendet, erfolgt möglicherweise eine Zunahme der VolumeReadIOPS-Werte. Parallel Query verwendet den Bufferpool nicht. Obwohl die Abfragen schnell sind, kann diese optimierte Verarbeitung zu einem Anstieg der Lesevorgänge und der damit verbundenen Gebühren führen.

Die I/O-Kosten für parallele Abfragen werden für Ihre Abfrage auf der Speicherebene gemessen und sind gleich oder höher, wenn die parallele Abfrage aktiviert ist. Ihr Vorteil ist die Verbesserung der Abfrageleistung. Es gibt zwei Gründe für potenziell höhere I/O-Kosten bei parallelen Abfragen:

Selbst wenn sich einige Daten in einer Tabelle im Pufferpool befinden, müssen bei der parallelen Abfrage alle Daten auf der Speicherebene gescannt werden, was I/O-Kosten verursacht.
Das Ausführen einer parallelen Abfrage führt nicht zu einem Aufwärmvorgang des Pufferpools. Folglich fallen bei aufeinanderfolgenden Läufen derselben parallelen Abfrage die vollen I/O-Kosten an.

Planen eines Parallel Query-Clusters

Bei der Planung eines DB-Clusters mit aktivierter paralleler Abfrage müssen einige Entscheidungen getroffen werden. Dazu gehören das Ausführen von Einrichtungsschritten (das Erstellen oder Wiederherstellen eines vollständigen Aurora MySQL-Clusters) und die Entscheidung, wie weit in Ihrem DB-Cluster die parallele Abfrage eingeschaltet werden sollen.

Berücksichtigen Sie bei der Planung Folgendes:

Wenn Sie Aurora MySQL verwenden, das mit MySQL 5.7 kompatibel ist, müssen Sie Aurora MySQL 2.09 oder höher auswählen. In diesem Fall erstellen Sie immer einen bereitgestellten Cluster. Anschließend aktivieren Sie die parallele Abfrage mit dem Parameter aurora_parallel_query.

Wenn Sie einen vorhandenen Aurora MySQL-Cluster haben, auf dem Version 2.09 oder höher ausgeführt wird, müssen Sie keinen neuen Cluster erstellen, um die parallele Abfrage verwenden zu können. Sie können Ihren Cluster oder bestimmte DB-Instances im Cluster einer Parametergruppe zuordnen, bei der der Parameter aurora_parallel_query aktiviert ist. Dadurch können Sie die Zeit und den Aufwand für die Einrichtung der relevanten Daten für die parallele Abfrage reduzieren.
Planen Sie alle großen Tabellen, die neu organisiert werden müssen, damit Sie die parallele Abfrage verwenden können, wenn Sie auf diese zugreifen. Möglicherweise müssen Sie neue Versionen einiger großer Tabellen erstellen, bei denen die parallele Abfrage nützlich ist. Beispielsweise müssen Sie möglicherweise Volltextsuchindizes entfernen. Details hierzu finden Sie unter Erstellen von Schema-Objekten, mit denen die Vorteile von Parallel Query genutzt werden können.

Überprüfen der Versionskompatibilität von Aurora MySQL für Parallel Query

Um zu überprüfen, welche Aurora-MySQL-Versionen mit parallelen Abfrage-Clustern kompatibel sind, verwenden Sie den AWS CLI-Befehl describe-db-engine-versions und überprüfen Sie den Wert des Feldes SupportsParallelQuery. Das folgende Codebeispiel zeigt, wie Sie überprüfen können, welche Kombinationen für Cluster für parallele Abfragen in einer bestimmten AWS-Region verfügbar sind. Stellen Sie sicher, dass Sie die vollständige --query-Parameterzeichenfolge in einer einzigen Zeile angeben.


aws rds describe-db-engine-versions --region us-east-1 --engine aurora-mysql \
--query '*[]|[?SupportsParallelQuery == `true`].[EngineVersion]' --output text

Die vorhergehenden Befehle erzeugen eine Ausgabe, die der folgenden ähnelt: Die Ausgabe hängt davon ab, welche Aurora-MySQL-Versionen in der angegebenen AWS-Region verfügbar sind.


5.7.mysql_aurora.2.11.1
8.0.mysql_aurora.3.01.0
8.0.mysql_aurora.3.01.1
8.0.mysql_aurora.3.02.0
8.0.mysql_aurora.3.02.1
8.0.mysql_aurora.3.02.2
8.0.mysql_aurora.3.03.0

Nachdem Sie angefangen haben, die parallele Abfrage mit einem Cluster zu verwenden, können Sie die Leistung überwachen und Hindernisse bei der Nutzung der parallelen Abfrage beseitigen. Diese Anweisungen finden Sie unter Optimierung der Abfrageleistung fürParallel Query.

Erstellen eines DB-Clusters für Parallel Query

Um einen für Parallel Query geeigneten Aurora MySQL-Cluster anzulegen, ihm neue Instances hinzuzufügen oder andere administrative Aufgaben zu erledigen, verwenden Sie die gleichen AWS Management Console- und AWS CLI-Techniken wie für andere Aurora-MySQL-Cluster. Sie können einen neuen Cluster erstellen, auf dem Sie parallele Abfragen ausführen können. Sie können auch einen für parallele Abfragen geeigneten DB-Cluster erstellen, indem Sie diesen aus einem Snapshot eines MySQL-kompatiblen Aurora-DB-Clusters wiederherstellen. Wenn Sie sich nicht sicher sind, wie ein neuer Aurora MySQL-Cluster erstellt wird, finden Sie unter diesem Link die erforderlichen Hintergrundinformationen und Anforderungen: Erstellen eines Amazon Aurora-DB Clusters.

Wenn Sie sich für eine Version einer Aurora MySQL-Engine entscheiden, empfehlen wir Ihnen, die neueste verfügbare Engine auszuwählen. Derzeit unterstützen die AuroraMySQL-Versionen 2.09 und höher die parallele Abfrage. Wenn Sie Aurora MySQL 2.09 und höher verwenden, haben Sie mehr Flexibilität, die parallele Abfrage zu aktivieren und zu deaktivieren, oder die parallele Abfragen mit vorhandenen Clustern zu verwenden.

Unabhängig davon, ob Sie einen neuen Cluster erstellen oder aus einem Snapshot wiederherstellen, gilt: Sie fügen neue DB-Instances genauso hinzu wie bei anderen Aurora MySQL-Clustern.

Erstellen eines Parallel Query-Clusters über die Konsole

Sie können wie folgt über die Konsole einen neuen Parallelabfragecluster erstellen.

So erstellen Sie über die -Konsole einen Parallelabfragecluste AWS Management Console

Gehen Sie vor, wie im allgemeinen AWS Management Console-Verfahren auf der Seite Erstellen eines Amazon Aurora-DB Clusters beschrieben.
Wählen Sie auf dem Bildschirm Engine auswählen die Option Aurora MySQL.

Wählen Sie für Engine-Version, die Option Aurora MySQL 2.09 oder höher aus. Bei diesen Versionen haben Sie die geringsten Einschränkungen für die Verwendung der parallelen Abfrage. Diese Versionen haben auch die größte Flexibilität, um die parallele Abfrage jederzeit ein- oder auszuschalten.

Wenn es nicht praktikabel ist, eine aktuelle Aurora MySQL-Version für diesen Cluster zu verwenden, wählen Sie Show versions that support the parallel query Funktion (Versionen anzeigen, die die parallele Abfrage unterstützen). Dadurch wird das Menü Version so gefiltert, dass nur die spezifischen Aurora MySQL-Versionen angezeigt werden, die mit der parallelen Abfrage kompatibel sind.
Wählen Sie unter Zusätzliche Konfiguration eine Parametergruppe aus, die Sie für die DB-Cluster-Parametergruppe erstellt haben. Die Verwendung einer solchen benutzerdefinierten Parametergruppe ist für Aurora MySQL 2.09 und höher erforderlich. Geben Sie in Ihrer DB-Cluster-Parametergruppe die Parametereinstellungen aurora_parallel_query=ON und aurora_disable_hash_join=OFF an. Dadurch wird die parallele Abfrage für den Cluster und die Hash-Join-Optimierung aktiviert, die in Kombination mit der parallelen Abfrage funktioniert.

So kontrollieren Sie, ob ein neuer Cluster parallelabfragefähig ist:

Erstellen Sie einen Cluster, wie vorhergehend beschrieben.

(Für Aurora MySQL Version 2 oder 3): Prüfen Sie, ob auf die Konfigurationseinstellung aurora_parallel_query die Bedingung „true“ zutrifft.


mysql> select @@aurora_parallel_query;
+-------------------------+
| @@aurora_parallel_query |
+-------------------------+
|                       1 |
+-------------------------+

(Für Aurora-MySQL-Version 2) Überprüfen Sie, ob die aurora_disable_hash_join-Einstellung „false“ ist.


mysql> select @@aurora_disable_hash_join;
+----------------------------+
| @@aurora_disable_hash_join |
+----------------------------+
|                          0 |
+----------------------------+

Überprüfen Sie bei einigen großen Tabellen und datenintensiven Abfragen die Abfragepläne, um zu bestätigen, dass einige Ihrer Abfragen die Optimierung für die parallele Abfrage verwenden. Eine Schritt-für-Schritt-Anleitung hierzu finden Sie unter Überprüfen, welche Anweisungen Parallel Query verwenden.

Erstellen eines Parallel Query-Clusters mit der CLI

Sie können wie folgt mit der CLI einen neuen Parallelabfragecluster erstellen.

So erstellen Sie über die -Konsole einen Parallelabfragecluste AWS CLI

(Optional) Überprüfen Sie, welche Aurora MySQL-Versionen mit parallelen Abfrage-Clustern kompatibel sind. Verwenden Sie dazu den Befehl describe-db-engine-versions und überprüfen Sie den Wert des Feldes SupportsParallelQuery. Ein Beispiel finden Sie unter Überprüfen der Versionskompatibilität von Aurora MySQL für Parallel Query.
(Optional) Erstellen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe mit den Einstellungen aurora_parallel_query=ON und aurora_disable_hash_join=OFF. Verwenden Sie Befehle wie die folgenden.
```
aws rds create-db-cluster-parameter-group --db-parameter-group-family aurora-mysql5.7 --db-cluster-parameter-group-name pq-enabled-57-compatible
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name pq-enabled-57-compatible \
  --parameters ParameterName=aurora_parallel_query,ParameterValue=ON,ApplyMethod=pending-reboot
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name pq-enabled-57-compatible \
  --parameters ParameterName=aurora_disable_hash_join,ParameterValue=OFF,ApplyMethod=pending-reboot
```
Wenn Sie diesen Schritt ausführen, geben Sie die Option --db-cluster-parameter-group-name my_cluster_parameter_group in der nachfolgenden create-db-cluster-Anweisung an. Geben Sie den Namen Ihrer eigenen Parametergruppe an. Wenn Sie diesen Schritt auslassen, erstellen Sie die Parametergruppe und ordnen sie später dem Cluster zu, wie unter beschriebe Aktivieren und Deaktivieren der parallelen Abfragen.
Gehen Sie vor, wie im allgemeinen AWS CLI-Verfahren auf der Seite Erstellen eines Amazon Aurora-DB Clusters beschrieben.
Geben Sie die folgenden Optionen an:
- Verwenden Sie für die Option --engine den Wert aurora-mysql. Diese Werte erzeugen parallele Abfrage-Cluster, die mit MySQL 5.7 oder 8.0 kompatibel sind.
- Geben Sie für die Option --db-cluster-parameter-group-name den Namen einer DB-Cluster-Parametergruppe an, die Sie erstellt und für die Sie den Parameterwert aurora_parallel_query=ON zugewiesen haben. Wenn Sie diese Option auslassen, können Sie den Cluster mit einer Standardparametergruppe erstellen und ihn später so ändern, dass er eine solche benutzerdefinierte Parametergruppe verwendet.
- Verwenden Sie für die Option --engine-version eine Aurora MySQL-Version, die mit der parallelen Abfrage kompatibel ist. Verwenden Sie das Verfahren aus Planen eines Parallel Query-Clusters, um bei Bedarf eine Liste der Versionen abzurufen. Verwenden Sie mindestens Version 2.09.0. Diese und alle höheren Versionen enthalten wesentliche Verbesserungen für parallelen Abfragen.
  
  Wie das aussehen kann, sehen Sie am nachfolgenden Beispielcode. Ersetzen Sie Ihren eigenen Wert für jede der Umgebungsvariablen wie $CLUSTER_ID. In diesem Beispiel wird auch die Option --manage-master-user-password zum Generieren des Hauptbenutzerpassworts und zum Verwalten dieses Passworts in Secrets Manager angegeben. Weitere Informationen finden Sie unter Passwortverwaltung mit , Amazon Aurora und AWS Secrets Manager. Alternativ können Sie die Option --master-password verwenden, um das Passwort selbst festzulegen und zu verwalten.
```
aws rds create-db-cluster --db-cluster-identifier $CLUSTER_ID \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --master-username $MASTER_USER_ID --manage-master-user-password \
  --db-cluster-parameter-group-name $CUSTOM_CLUSTER_PARAM_GROUP

aws rds create-db-instance --db-instance-identifier ${INSTANCE_ID}-1 \
  --engine same_value_as_in_create_cluster_command \
  --db-cluster-identifier $CLUSTER_ID --db-instance-class $INSTANCE_CLASS
```
Überprüfen Sie, ob ein von Ihnen erstellter oder wiederhergestellter Cluster parallelabfragefähig ist.

Prüfen Sie, ob auf die Konfigurationseinstellung aurora_parallel_query vorhanden ist. Wenn diese Einstellung den Wert „1“ hat, können Sie die parallele Abfrage verwenden. Wenn diese Einstellung den Wert „0“ hat, müssen Sie ihn auf „1“ festlegen, bevor Sie die parallele Abfrage verwenden können. In jedem Fall ist der Cluster in der Lage, die parallele Abfrage durchzuführen.
```
mysql> select @@aurora_parallel_query;
+------------------------+
| @@aurora_parallel_query|
+------------------------+
|                      1 |
+------------------------+
```

Stellen Sie einen Snapshot in einem parallelen Abfragecluster mit dem AWS CLI wie folgt wieder her:

Überprüfen Sie, welche Aurora MySQL-Versionen mit parallelen Abfrage-Clustern kompatibel sind. Verwenden Sie dazu den Befehl describe-db-engine-versions und überprüfen Sie den Wert des Feldes SupportsParallelQuery. Ein Beispiel finden Sie unter Überprüfen der Versionskompatibilität von Aurora MySQL für Parallel Query. Entscheiden Sie, welche Version für den wiederhergestellten Cluster verwendet werden soll. Wählen Sie Aurora MySQL 2.09.0 oder höher für einen mit MySQL 5.7 kompatiblen Cluster.
Suchen Sie einen Aurora MySQL-kompatiblen Cluster-Snapshot.

Gehen Sie vor, wie im allgemeinen AWS CLI-Verfahren auf der Seite Wiederherstellen aus einem DB-Cluster-Snapshot beschrieben.


aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier mynewdbcluster \
  --snapshot-identifier mydbclustersnapshot \
  --engine aurora-mysql

Überprüfen Sie, ob ein von Ihnen erstellter oder wiederhergestellter Cluster parallelabfragefähig ist. Verwenden Sie das gleiche Verifizierungsverfahren wie in Erstellen eines Parallel Query-Clusters mit der CLI.

Aktivieren und Deaktivieren der parallelen Abfragen

Wenn die parallele Abfrage aktiviert ist, bestimmt Aurora MySQL, ob sie zur Laufzeit für jede Abfrage verwendet wird. Werden Join-Abfragen, Union-Abfragen, Unterabfragen usw. durchgeführt, entscheidet Aurora MySQL bei jedem Abfrageblock, ob zur Laufzeit parallel abgefragt werden soll. Details dazu finden Sie unter Überprüfen, welche Anweisungen Parallel Query verwenden und Zusammenwirken von Parallel Query und SQL-Konstrukten.

Sie können parallele Abfragen sowohl auf globaler als auch auf Sitzungsebene für eine DB-Instance dynamisch ein- und ausschalten, indem Sie die Option aurora_parallel_query verwenden. Sie können die Einstellung aurora_parallel_query in Ihrer DB-Clustergruppe so ändern, dass die parallele Abfrage standardmäßig aktiviert oder deaktiviert wird.


mysql> select @@aurora_parallel_query;
+------------------------+
| @@aurora_parallel_query|
+------------------------+
|                      1 |
+------------------------+

Um de Parameter aurora_parallel_query auf Sitzungsebene zu aktivieren und zu deaktivieren, verwenden Sie die Standardmethoden zum Anpassen von Client-Konfigurationseinstellungen. Sie können dies beispielsweise über die mysql-Befehlszeile oder in einer JDBC- oder ODBC-Anwendung tun. Der Befehl für den Standard-MySQL-Client lautet set session aurora_parallel_query = {'ON'/'OFF'}. Sie können den Parameter auf Sitzungsebene auch der JDBC-Konfiguration oder innerhalb Ihres Anwendungscodes hinzufügen, um parallele Abfragen dynamisch ein- oder auszuschalten.

Sie können die Einstellung für den Parameter aurora_parallel_query dauerhaft ändern, entweder für eine bestimmte DB-Instance oder für den gesamten Cluster. Wenn Sie den Parameterwert in einer DB-Parametergruppe angeben, gilt dieser Wert nur für bestimmte DB-Instances in Ihrem Cluster. Wenn Sie den Parameterwert in einer DB-Cluster-Parametergruppe angeben, erben alle DB-Instances im Cluster dieselbe Einstellung. Um den Parameter aurora_parallel_query umzuschalten, wenden Sie die Methoden an, die Sie auch für Parametergruppen verwenden, siehe Arbeiten mit Parametergruppen. Dazu gehen Sie wie folgt vor:

Erstellen Sie eine benutzerdefinierte Cluster-Parametergruppe (empfohlen) oder eine benutzerdefinierte DB-Parametergruppe.
Aktualisieren Sie in dieser Parametergruppe parallel_query auf den gewünschten Wert.
Abhängig davon, ob Sie eine DB-Cluster-Parametergruppe oder eine DB-Parametergruppe erstellt haben, hängen Sie die Parametergruppe Ihrem Aurora-Cluster oder den spezifischen DB-Instances an, in denen Sie die Parallelabfrage-Funktion verwenden möchten.

Tipp
Da es sich bei aurora_parallel_query um einen dynamischen Parameter handelt, ist ein Neustart des Clusters nach dem Ändern dieser Einstellung nicht erforderlich. Alle Verbindungen, die vor dem Umschalten der Option eine parallele Abfrage verwendeten, setzen diesen Vorgang fort, bis die Verbindung geschlossen oder die Instance neu gestartet wird.

Sie können den Parallelabfrageparameter nachträglich anpassen. Verwenden Sie dazu die API-Operationen ModifyDBClusterParameterGroup oder ModifyDBParameterGroup oder die AWS Management Console.

Hash-Join für parallele Abfrage-Cluster aktivieren

Parallele Abfragen werden typischerweise für ressourcenintensive Abfragen verwendet, die von der Hash-Join-Optimierung profitieren. Daher ist es hilfreich sicherzustellen, dass Hash-Joins für Cluster aktiviert sind, in denen Sie parallele Abfragen verwenden möchten. Informationen zur effektiven Verwendung von Hash-Joins finden Sie unter Optimierung von großen Aurora-MySQL-Join-Abfragen mit Hash-Joins.

Ein- und Ausschalten der parallelen Abfrage mit der Konsole

Sie können die parallele Abfrage auf DB-Instance-Ebene oder DB-Cluster-Ebene aktivieren oder deaktivieren, indem Sie mit Parametergruppen arbeiten.

So aktivieren oder deaktivieren Sie die parallele Abfrage für einen DB-Cluster mit der AWS Management Console

Erstellen Sie eine benutzerdefinierte Parametergruppe, wie in Arbeiten mit Parametergruppen beschrieben.
Aktualisieren Sie aurora_parallel_query zu 1 (aktiviert) oder 0 (deaktiviert). Für Cluster, in denen die parallele Abfragefunktion verfügbar ist, ist aurora_parallel_query standardmäßig deaktiviert.
Wenn Sie eine benutzerdefinierte Cluster-Parametergruppe verwenden, fügen Sie sie dem Aurora-DB-Cluster zu, in dem Sie die parallele Abfrage verwenden möchten. Wenn Sie eine benutzerdefinierte DB-Parametergruppe verwenden, fügen Sie sie einer oder mehreren DB-Instances im Cluster zu. Wir empfehlen die Verwendung einer Cluster-Parametergruppe. Dadurch wird sichergestellt, dass alle DB-Instances im Cluster die gleichen Einstellungen für die parallele Abfrage und zugehörige Funktionen wie Hash-Join haben.

Ein- und Ausschalten der parallelen Abfrage mit der CLI

Sie können den Parallelabfrageparameter nachträglich anpassen. Verwenden Sie dazu den Befehl modify-db-cluster-parameter-group oder modify-db-parameter-group. Wählen Sie den entsprechenden Befehl, je nachdem, ob Sie den Wert von aurora_parallel_query über eine DB-Cluster-Parametergruppe oder eine DB-Parametergruppe angeben.

So aktivieren oder deaktivieren Sie die parallele Abfrage für einen DB-Cluster mit der CLI

Passen Sie den Parallelabfrageparameter nachträglich an. Verwenden Sie dazu den Befehl modify-db-cluster-parameter-group. Verwenden Sie einen Befehl wie den folgenden. Ersetzen Sie den entsprechenden Namen mit Ihrer eigenen benutzerdefinierten Parametergruppe. Setzen Sie entweder ON oder OFF ein in den ParameterValue-Teil der Option --parameters.



$ aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name cluster_param_group_name \
  --parameters ParameterName=aurora_parallel_query,ParameterValue=ON,ApplyMethod=pending-reboot
{
    "DBClusterParameterGroupName": "cluster_param_group_name"
}

aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name cluster_param_group_name \
  --parameters ParameterName=aurora_pq,ParameterValue=ON,ApplyMethod=pending-reboot

Sie können parallele Abfragen auch auf Sitzungsebene aktivieren oder deaktivieren, beispielsweise über die Befehlszeile mysql oder in einer JDBC- oder ODBC-Anwendung. Verwenden Sie dafür die Standardmethoden zum Anpassen von Client-Konfigurationseinstellungen. Beispielsweise lautet der Befehl für den Standard-MySQL-Client set session aurora_parallel_query = {'ON'/'OFF'} für Aurora MySQL.

Sie können den Parameter auf Sitzungsebene auch der JDBC-Konfiguration oder innerhalb Ihres Anwendungscodes hinzufügen, um parallele Abfragen dynamisch ein- oder auszuschalten.

Überschreiben des Parallelabfrageoptimierers

Sie können die Sitzungsvariable aurora_pq_force verwenden, um den Parallelabfrageoptimierer zu überschreiben und für jede Abfrage eine Parallelabfrage anzufordern. Wir empfehlen diese Vorgehensweise nur zu Testzwecken. Das folgende Beispiel zeigt, wie Sie aurora_pq_force in einer Sitzung verwenden.


set SESSION aurora_parallel_query = ON;
set SESSION aurora_pq_force = ON;

Gehen Sie wie folgt vor, um die Überschreibung zu deaktivieren:


set SESSION aurora_pq_force = OFF;

Wichtige Punkte bei einem Upgrade für parallele Abfragen

Abhängig von der Original- und Zielversionen beim Upgrade eines parallelen Abfrage-Clusters finden Sie möglicherweise Verbesserungen bei den Abfragetypen, die parallele Abfragen optimieren können. Möglicherweise müssen Sie auch feststellen, dass Sie keinen speziellen Engine-Modusparameter für parallele Abfragen angeben müssen. In den folgenden Abschnitten werden die Überlegungen beim Upgrade eines Clusters erläutert, bei dem die parallele Abfrage aktiviert ist.

Upgrade paralleler Abfrage-Cluster auf Aurora-MySQL-Version 3

Mehrere SQL-Anweisungen, Klauseln und Datentypen haben ab Aurora-MySQL-Version 3 neuen oder verbesserten Support für parallele Abfragen. Prüfen Sie beim Upgrade von einer Version, die vor Version 3 liegt, ob zusätzliche Abfragen von parallelen Abfrageoptimierungen profitieren können. Informationen zu diesen Erweiterungen für parallele Abfragen finden Sie unter Spaltendatentypen, Partitionierte Tabellen und Aggregationsfunktionen, GROUP BY-Klauseln und HAVING-Klauseln.

Wenn Sie einen Parallelabfragecluster von Aurora MySQL 2.08 oder niedriger aktualisieren, informieren Sie sich auch über Änderungen beim Einschalten der parallelen Abfrage. Lesen Sie dazu Upgrade auf Aurora MySQL 2.09 und höher.

In Aurora-MySQL-Version 3 ist die Hash-Join-Optimierung standardmäßig aktiviert. Die Konfigurationsoption aurora_disable_hash_join aus früheren Versionen wird nicht verwendet.

Upgrade auf Aurora MySQL 2.09 und höher

In Aurora MySQL 2.09 und höher funktioniert die parallele Abfrage für bereitgestellte Cluster und erfordert keinen parallelquery-Engine-Modus-Parameter. Daher müssen Sie keinen neuen Cluster erstellen oder aus einem vorhandenen Snapshot wiederherstellen, um die parallele Abfrage mit diesen Versionen verwenden zu können. Sie können die unter Upgrade der Nebenversion oder der Patch-Ebene eines Aurora MySQL-DB-Clusters beschriebenen Upgrade-Verfahren verwenden, um den Cluster auf eine solche Version zu aktualisieren. Sie können einen älteren Cluster aktualisieren, unabhängig davon, ob es sich um einen Parallelabfragecluster oder um einen bereitgestellten Cluster handelte. Um die Anzahl der Optionen im Menü Engine-Version zu reduzieren, können Sie Versionen anzeigen, die die parallele Abfrage unterstützen auswählen, um die Einträge in diesem Menü zu filtern. Wählen Sie dann Aurora MySQL 2.09 oder höher aus.

Nachdem Sie einen früheren Parallelabfragecluster auf Aurora MySQL 2.09 oder höher aktualisiert haben, aktivieren Sie die parallele Abfrage im aktualisierten Cluster. Die parallele Abfrage ist in diesen Versionen standardmäßig deaktiviert, und die Vorgehensweise zum Aktivieren ist anders. Die Hash-Join-Optimierung ist ebenfalls standardmäßig deaktiviert und muss separat aktiviert werden. Stellen Sie daher sicher, dass Sie diese Einstellungen nach dem Upgrade wieder aktivieren. Anweisungen dazu finden Sie unter Aktivieren und Deaktivieren der parallelen Abfragen und Hash-Join für parallele Abfrage-Cluster aktivieren.

Insbesondere schalten Sie die parallele Abfrage mithilfe der Konfigurationsparameter aurora_parallel_query=ON und aurora_disable_hash_join=OFF anstelle von aurora_pq_supported und aurora_pq ein. Die Parameter aurora_pq_supported und aurora_pq sind in den neueren Aurora MySQL-Versionen veraltet.

Im aktualisierten Cluster weist das Attribut EngineMode den Wert provisioned anstelle von parallelquery auf. Um zu prüfen, ob die parallele Abfrage für eine angegebene Engine-Version verfügbar ist, überprüfen Sie nun den Wert des Feldes SupportsParallelQuery in der Ausgabe des describe-db-engine-versions-Befehls AWS CLI. In früheren Aurora MySQL-Versionen haben Sie überprüft, ob parallelquery in der Liste SupportedEngineModes vorhanden ist.

Nach dem Upgrade auf Aurora MySQL 2.09 oder höher können Sie die folgenden Funktionen nutzen. Diese Funktionen sind nicht für Parallelabfragecluster verfügbar, auf denen ältere Aurora MySQL-Versionen ausgeführt werden.

Performance-Insights. Weitere Informationen finden Sie unter Überwachung mit Performance Insights auf .
Rückverfolgung. Weitere Informationen finden Sie unter Rückverfolgen eines Aurora-DB-Clusters.
Stoppen und Starten des Clusters. Weitere Informationen finden Sie unter Stoppen und Starten eines Amazon Aurora-DB-Clusters.

Optimierung der Abfrageleistung fürParallel Query

Um mit Parallel Query die Abarbeitung einer Workload beeinflussen zu können, müssen Sie überlegen, wie Sie Parallel Query für die Abfragen einsetzen, bei denen diese Optimierung den größten Effekt hat.

Gehen Sie dazu wie folgt vor:

Stellen Sie sicher, dass Ihre größten Tabellen mit der parallelen Abfrage kompatibel sind. Sie können Tabelleneigenschaften ändern oder einige Tabellen neu erstellen, damit Abfragen für diese Tabellen die Optimierung für die parallele Abfrage nutzen können. Um zu erfahren wie, siehe Erstellen von Schema-Objekten, mit denen die Vorteile von Parallel Query genutzt werden können.
Überwachen Sie, welche Abfragen mit Parallel Query ausgeführt werden. Um zu erfahren wie, siehe Überwachen von Parallel Query.
Stellen Sie sicher, dass die parallele Abfrage für die datenintensivsten und am längsten laufenden Abfragen und mit der richtigen Parallelität für Ihren Workload verwendet wird. Um zu erfahren wie, siehe Überprüfen, welche Anweisungen Parallel Query verwenden.
Optimieren Sie Ihren SQL-Code, um die parallele Abfrage zu aktivieren, um sie auf die erwarteten Abfragen anzuwenden. Um zu erfahren wie, siehe Zusammenwirken von Parallel Query und SQL-Konstrukten.

Erstellen von Schema-Objekten, mit denen die Vorteile von Parallel Query genutzt werden können

Bevor Sie Tabellen erstellen oder ändern, die Sie für die parallele Abfrage verwenden möchten, sollten Sie sich mit den unter Voraussetzungen und Einschränkungen beschriebenen Anforderungen vertraut machen.

Wenn Sie Parallelabfragen starten, müssen Tabellen die Einstellungen ROW_FORMAT=Compact oder ROW_FORMAT=Dynamic verwenden. Öffnen Sie deshalb die Konfigurationseinstellungen von Aurora und prüfen Sie, ob an der Konfigurationsoption INNODB_FILE_FORMAT Änderungen vorgenommen wurden. Geben Sie die Anweisung SHOW TABLE STATUS aus, um das Zeilenformat aller Tabellen einer Datenbank zu bestätigen.

Bevor Sie Ihr Schema ändern, um die parallele Abfrage zu aktivieren, um mit mehr Tabellen zu arbeiten, stellen Sie sicher, dass Sie es testen. Ihre Tests sollten bestätigen, ob die parallele Abfrage zu einer besseren Nettoleistung für diese Tabellen führt. Stellen Sie außerdem sicher, dass die Schema-Anforderungen an Parallel Query mit Ihren Zielen vereinbar sind.

Zum Beispiel: Prüfen Sie vor der Umstellung von ROW_FORMAT=Compressed auf ROW_FORMAT=Compact oder ROW_FORMAT=Dynamic die Leistung von Workloads anhand der ursprünglichen und der neuen Tabellen. Berücksichtigen Sie außerdem eventuelle sonstige Effekte (z. B. erhöhtes Datenvolumen).

Überprüfen, welche Anweisungen Parallel Query 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: Zusammenwirken von Parallel Query und SQL-Konstrukten

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 Zusammenwirken von Parallel Query und SQL-Konstrukten.

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

Überwachen von Parallel Query

Wenn Ihr Aurora MySQL Cluster eine parallele Abfrage verwendet, wird möglicherweise eine Zunahme der VolumeReadIOPS-Werte. Parallel Query verwendet den Bufferpool nicht. Obwohl die Abfragen schnell sind, kann diese optimierte Verarbeitung zu einem Anstieg der Lesevorgänge und damit verbundenen Gebühren führen.

Neben den Amazon CloudWatch-Metriken (siehe Anzeigen von Metriken in der Amazon-RDS-Konsole) enthält Aurora auch verschiedene Statusvariable. Sie können diese globalen Statusvariablen verwenden, um die parallele Abfrageausführung zu überwachen. Sie können Ihnen Einblicke in die Gründe geben, warum der Optimierer die parallele Abfrage in einer bestimmten Situation verwendet oder nicht verwendet. Sie können diese Variablen mit dem Befehl SHOW GLOBAL STATUS abrufen. Eine Liste der Variablen finden Sie auch nachfolgend auf dieser Seite.

Eine parallele Abfragesitzung ist nicht notwendigerweise eine 1:1-Zuweisung mit den von der Datenbank durchgeführten Abfragen. Angenommen, Ihr Abfrageplan enthält zwei Schritte, die Parallel Query verwenden. In diesem Fall besteht die Abfrage aus zwei parallelen Sitzungen. Die Zähler für Aufrufversuche und erfolgreiche Aufrufe werden inkrementell jeweils um zwei erhöht.

Wenn Sie mit Parallel Query experimentieren und dabei EXPLAIN-Anweisungen herausgeben, kann sein, dass Zähleranstiege als "nicht ausgewählt" bezeichnet sind, obwohl die Abfragen nicht ausgeführt werden. Wenn Sie Parallel Query in einer Produktionsumgebung einsetzen, können Sie nachprüfen, ob die Meldung "nicht ausgewählt" schneller als erwartet zunimmt. An diesem Punkt können Sie sie so anpassen, dass die parallele Abfrage für die erwarteten Abfragen ausgeführt wird. Dazu können Sie Ihre Clustereinstellungen, den Abfragemix, DB-Instances, bei denen die parallele Abfrage aktiviert ist, usw. ändern.

Die Aktionen werden auf DB-Instance-Ebene nachverfolgt. Wenn Sie eine Verbindung zu einem anderen Endpunkt herstellen, könnten sich andere Metriken ergeben, weil jede DB-Instance ihre eigenen Parallelabfragen ausführt. Unterschiedliche Metriken können sich auch dann ergeben, wenn sich der Leserendpunkt in jeder Sitzung mit einer anderen DB-Instance verbindet.

Name	Beschreibung
`Aurora_pq_bytes_returned`	Die Anzahl der Bytes, die in Zusammenhang mit Tupel-Datenstrukturen während der Parallelabfragen an den Hauptknoten übertragen wurden. Für den Abgleich mit durch 16 348 teile `Aurora_pq_pages_pushed_down`.
`Aurora_pq_max_concurrent_requests`	Die Höchstanzahl der Parallel Query-Sitzungen, die auf dieser Aurora-DB-Instance gleichzeitig ausgeführt werden können. Diese Zahl ist festgelegt und hängt von der AWS-DB-Instance-Klasse ab.
`Aurora_pq_pages_pushed_down`	Die Anzahl der Datenseiten (jeweils fix 16 KiB groß), auf denen Parallel Query eine netzwerkgebundene Übertragung an den Hauptknoten verhindert hat.
`Aurora_pq_request_attempted`	Die Anzahl der angeforderten Parallel Query-Sitzungen. Hinter diesem Wert können pro Abfrage mehrere Sitzungen stehen. Ausschlaggebend sind SQL-Konstrukte wie Unterabfragen und Join-Abfragen.
`Aurora_pq_request_executed`	Die Anzahl der erfolgreich ausgeführten Parallel Query-Sitzungen.
`Aurora_pq_request_failed`	Die Anzahl der Parallel Query-Sitzungen, die dem Client einen Fehler zurückgaben. Es kann vorkommen, dass eine angeforderte Parallelabfrage fehlschlägt – z. B. wegen eines Problems auf der Speicherschicht. In diesen Fällen wird der fehlgeschlagene Abfrageteil wiederholt. Dafür kommt der nicht-parallele Abfragemechanismus zum Einsatz. Wenn auch die wiederholte Abfrage fehlschlägt, wird dem Client ein Fehler zurückgegeben. Die Zähleranzeige erhöht sich.
`Aurora_pq_request_in_progress`	Die Anzahl der derzeit in Ausführung befindlichen Parallel Query-Sitzungen. Die Zahl bezieht sich auf die angeschlossene Aurora-DB-Instance, mit der Sie verbunden sind, nicht auf das gesamte Aurora-DB-Cluster. Sie können prüfen, ob eine DB-Instance die Obergrenze für gleichzeitige Abfragen annähernd erreicht hat. Gleichen Sie dazu diesen Wert mit a `Aurora_pq_max_concurrent_requests`.
`Aurora_pq_request_not_chosen`	Die Anzahl der Situationen, in denen Parallel Query nicht für die Abarbeitung einer Abfrage genutzt wurde. Dieser Wert setzt sich aus den Beiträgen mehrerer Zähler mit höherer Granularität zusammen. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird.
`Aurora_pq_request_not_chosen_below_min_rows`	Die Anzahl der Situationen, in denen die Anzahl der Tabellenzeilen der Grund für den Nichteinsatz von Parallel Query war. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird.
`Aurora_pq_request_not_chosen_column_bit`	Die Anzahl der Parallelabfrageanforderungen, die aufgrund eines nicht unterstützten Datentyps in der Liste der projizierten Spalten den nicht-parallelen Abfrageverarbeitungspfad nutzen.
`Aurora_pq_request_not_chosen_column_geometry`	Die Anzahl der Parallelabfrageanforderungen, die den nicht-parallelen Abfrageverarbeitungspfad nutzen, da die Tabelle Spalten mit dem Datentyp `GEOMETRY` enthält. Informationen zu Aurora-MySQL-Versionen, die diese Einschränkung aufheben, finden Sie unter Upgrade paralleler Abfrage-Cluster auf Aurora-MySQL-Version 3.
`Aurora_pq_request_not_chosen_column_lob`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle Spalten mit einem `LOB`-Datentyp enthält oder `VARCHAR`- Spalten, die aufgrund der deklarierten Länge extern gespeichert werden. Informationen zu Aurora-MySQL-Versionen, die diese Einschränkung aufheben, finden Sie unter Upgrade paralleler Abfrage-Cluster auf Aurora-MySQL-Version 3.
`Aurora_pq_request_not_chosen_column_virtual`	Die Anzahl der Parallelabfrageanforderungen, die den nicht-parallelen Abfrageverarbeitungspfad nutzen, da die Tabelle eine virtuelle Spalte enthält.
`Aurora_pq_request_not_chosen_custom_charset`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle Spalten mit einem benutzerdefinierten Zeichensatz enthält.
`Aurora_pq_request_not_chosen_fast_ddl`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle zurzeit durch eine schnelle `ALTER`-DDL-Anweisung geändert wird.
`Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool`	Die Anzahl der Situationen, in denen Parallel Query nicht genutzt wurde, obwohl weniger als 95 Prozent der Tabellendaten im Bufferpool waren. Grund: Es gab zu wenig nicht gepufferte Tabellendaten. Eine Parallelabfrage lohnte sich deshalb nicht.
`Aurora_pq_request_not_chosen_full_text_index`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle Volltextindizes enthält.
`Aurora_pq_request_not_chosen_high_buffer_pool_pct`	Die Anzahl der Situationen, in denen Parallel Query nicht genutzt wurde, weil ein hoher Anteil der Tabellendaten (derzeit >95 Prozent) bereits im Bufferpool war. In diesen Fällen entscheidet der Optimierer, dass das Lesen der Daten aus dem Bufferpool effizienter ist. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird.
`Aurora_pq_request_not_chosen_index_hint`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage einen Indexhinweis enthält.
`Aurora_pq_request_not_chosen_innodb_table_format`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle ein nicht unterstütztes InnoDB-Zeilenformat verwendet. Die parallele Aurora-Abfrage gilt nur für die `COMPACT`-, `REDUNDANT`- und `DYNAMIC`-Zeilenformate.
`Aurora_pq_request_not_chosen_long_trx`	Die Anzahl der Parallelabfrageanforderungen, die den nicht-parallelen Abfrageverarbeitungspfad nutzten, weil die Abfrage in einer lang laufenden Transaktion gestartet wurde. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird.
`Aurora_pq_request_not_chosen_no_where_clause`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage keine `WHERE`-Klausel enthält.
`Aurora_pq_request_not_chosen_range_scan`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage einen Bereichsscan für einen Index verwendet.
`Aurora_pq_request_not_chosen_row_length_too_long`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Gesamtlänge aller Spalten zu groß ist.
`Aurora_pq_request_not_chosen_small_table`	Die Anzahl der Situationen, in denen die Gesamtgröße der Tabelle (Zeilenanzahl und durchschnittliche Zeilenlänge) der Grund für den Nichteinsatz von Parallel Query war. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird.
`Aurora_pq_request_not_chosen_temporary_table`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage auf temporäre Tabellen verweist, die die nicht unterstützten Tabellentypen `MyISAM` oder `memory` verwenden.
`Aurora_pq_request_not_chosen_tx_isolation`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage eine nicht unterstützte Transaktionsisolationsstufe verwendet. Bei DB-Leser-Instances wird die parallele Abfrage nur auf die Isolationsstufen `REPEATABLE READ` und `READ COMMITTED` angewendet.
`Aurora_pq_request_not_chosen_update_delete_stmts`	Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage Teil einer `UPDATE`- oder `DELETE`-Anweisung ist.
`Aurora_pq_request_not_chosen_unsupported_access`	Die Anzahl der Parallelabfrageanforderungen, die den nicht-parallelen Abfrageverarbeitungspfad nutzen, weil die `WHERE`-Klausel nicht den Kriterien einer Parallelabfrage gerecht wird. Dieses Ergebnis kann eintreten, wenn für die Abfrage kein datenintensiver Scan erforderlich ist oder wenn es sich bei der Abfrage um eine `DELETE`- oder `UPDATE`-Anweisung handelt.
`Aurora_pq_request_not_chosen_unsupported_storage_type`	Die Anzahl der Parallelabfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da der DB-Cluster von Aurora MySQL keine unterstützte Aurora-Cluster-Speicherkonfiguration verwendet. Dieser Parameter ist in Aurora-MySQL-Version 3.04 und höher verfügbar. Weitere Informationen finden Sie unter Einschränkungen.
`Aurora_pq_request_throttled`	Die Anzahl der Situationen, in denen Parallel Query nicht genutzt wurde, weil die Höchstmenge gleichzeitiger Parallelabfragen bereits auf einer bestimmten Aurora-DB-Instance ausgeführt wird.

Zusammenwirken von Parallel Query und SQL-Konstrukten

Im folgenden Abschnitt finden Sie weitere Details dazu, warum bestimmte SQL-Anweisungen parallele Abfragen verwenden oder nicht verwenden. In diesem Abschnitt wird auch beschrieben, wie Aurora MySQL-Funktionen mit Parallel Query interagieren. Mit Hilfe dieser Informationen können Sie Leistungsprobleme in Clustern diagnostizieren, die Parallel Query verwenden. Außerdem können Sie nachvollziehen, wie Parallel Query auf Ihren spezifischen Workload angewendet wird.

Die Entscheidung für Parallel Query hängt von vielen Faktoren ab, die zu dem Zeitpunkt wirken, an dem die Anweisung ausgeführt wird. Es kann also sein, dass Parallel Query für bestimmte Abfragen immer, nie oder nur unter bestimmten Bedingungen zum Einsatz kommt.

Tipp

Wenn Sie diese Beispiele in HTML anzeigen, können Sie das Widget Copy (Kopieren) in der oben rechts in jeder Codeverzeichnis verwenden, um den SQL-Code zu kopieren und es selbst zu versuchen. Durch die Verwendung des Widgets Copy (Kopieren) wird ein Kopieren der zusätzlichen Zeichen um die Aufforderung mysql> und die Fortsetzungszeilen -> vermieden.

EXPLAIN-Anweisung

Wie aus den Beispielen aus diesem Abschnitt hervorgeht, gibt die EXPLAIN-Anweisung an, ob die jeweilige Stufe einer Abfrage derzeit parallelabfragetauglich ist. Darüber hinaus gibt sie auch an, welche Aspekte einer Abfrage auf die nächste Speicherschicht herabgestuft werden können. Die wichtigsten Bestandteile im Abfrageplan sind folgende:

Wenn in der NULL-Spalte ein anderer Wert als key steht, liegt nahe, dass die Abfrage mit Index-Lookups effizient möglich ist. Der Einsatz von Parallel Query ist unwahrscheinlich.
Wenn in der Spalte rows ein kleiner Wert steht (d. h. nicht im Millionenbereich), kann dies bedeuten, dass für die Abfrage zu wenig Daten verfügbar sind, als dass sich eine Parallelabfrage lohnen würde. Das bedeutet, dass eine parallele Abfrage unwahrscheinlich ist.
Die Spalte Extra zeigt an, ob mit einer Parallelabfrage zu rechnen ist. Die Ausgabe kann in etwa wie im folgenden Beispiel aussehen.
```
Using parallel query (A columns, B filters, C exprs; D extra)
```
Die Zahl vor columns gibt an, wie viele Spalten im Abfrageblock hinterlegt sind.

Die Zahl vor filters gibt an, wie viele WHERE-Prädikate einen einfachen Vergleich zwischen Spaltenwert und einer Konstante darstellen. Es können Größen wie „Gleichheit“ und „Ungleichheit“, aber auch Bereiche verglichen werden. Aurora parallelisiert diese Prädikattypen am effektivsten.

Die Zahl vor exprs gibt die Anzahl der Ausdrücke (z. B. Funktionsaufrufe, Operatoren oder sonstige Ausdrücke) an, die auch parallelisiert werden können – wenn auch nicht so effektiv wie eine Filterbedingung.

Die Zahl vor extra gibt an, wie viele Ausdrücke nicht herabgestuft werden können und deshalb vom Hauptknoten ausgeführt werden.

Betrachten Sie dazu die folgende EXPLAIN-Ausgabe.


mysql> explain select p_name, p_mfgr from part
    -> where p_brand is not null
    -> and upper(p_type) is not null
    -> and round(p_retailprice) is not null;
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+
| id | select_type | table |...| rows     | Extra                                                                      |
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+
|  1 | SIMPLE      | part  |...| 20427936 | Using where; Using parallel query (5 columns, 1 filters, 2 exprs; 0 extra) |
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+

Aus der Extra-Spalte geht hervor, dass aus jeder Zeile fünf Spalten extrahiert werden, mit denen die Abfragebedingungen bewertet und der Ergebnissatz konstruiert werden. Ein WHERE-Prädikat beinhaltet einen Filter – in diesem Fall eine Spalte, die direkt in der WHERE-Klausel getestet wird. Kommen zwei WHERE-Klauseln vor, müssen kompliziertere Ausdrücke bewertet werden (die in diesem Fall Funktionsaufrufe beinhalten). Das Feld 0 extra bestätigt, dass alle Operationen in der WHERE-Klausel im Zuge der Parallelabfrageverarbeitung in die Speicherschicht herabgestuft werden.

Wird Parallel Query nicht ausgewählt, lässt sich der Grund dafür meist aus den anderen Spalten der EXPLAIN-Ausgabe ableiten. So kann möglicherweise sein, dass der rows-Wert zu klein ist oder dass die Spalte possible_keys angibt, dass die Abfrage statt auf einen datenintensiven Scan auf einen Index-Lookup zurückgreift. Das folgende Beispiel zeigt eine Abfrage, bei der der Optimierer schätzen kann, dass die Abfrage nur eine kleine Anzahl von Zeilen durchsucht. Dies erfolgt auf der Basis der Eigenschaften des Primärschlüssels. Eine Parallelabfrage ist deshalb nicht erforderlich.


mysql> explain select count(*) from part where p_partkey between 1 and 100;
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
|  1 | SIMPLE      | part  | range | PRIMARY       | PRIMARY | 4       | NULL |   99 | Using where; Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+

Die Ausgabe mit Auskunft zur Verwendung von Parallel Query berücksichtigt alle Faktoren, die zu dem Zeitpunkt verfügbar waren, als die EXPLAIN-Anweisung ausgeführt wurde. Möglicherweise trifft der Optimierer zum Zeitpunkt der tatsächlichen Abfrageausführung eine andere Auswahl, wenn bis dahin eine andere Ausgangslage herrscht. EXPLAIN könnte beispielsweise melden, dass eine Anweisung Parallel Query verwendet. Wird die Abfrage später dann tatsächlich ausgeführt, könnte sein, dass Parallel Query aufgrund der dann vorliegenden Bedingungen nicht nötig ist. Zu solchen Bedingungen können mehrere weitere parallele Abfragen gehören, die gleichzeitig ausgeführt werden. Es kann sich auch um Zeilen handeln, die aus der Tabelle gelöscht werden, um einen neuen Index, der erstellt wird, um zu viel Zeit, die in einer offenen Transaktion verstreicht, usw.

WHERE-Klausel

Damit die parallele Abfrageausführung genutzt werden kann, muss die Abfrage eine WHERE-Klausel enthalten.

Die parallele Abfrageausführung beschleunigt viele unterschiedliche Ausdrücke, die in der WHERE-Klausel vorkommen:

Einfache Abgleiche zwischen einem Spaltenwert und einer Konstante (Filter). Bei diesen Abgleichen lohnt sich die Herabstufung auf die Speicherschicht am meisten. Wie viele Filterausdrücke in einer Abfrage vorkommen, ist in der EXPLAIN-Ausgabe zusammengefasst.
Wo dies möglich ist, werden auch andere Ausdrücke aus der WHERE-Klausel in die Speicherschicht hinabgestuft. Wie viele solche Ausdrücke in einer Abfrage vorkommen, ist in der EXPLAIN-Ausgabe zusammengefasst. Bei diesen Ausdrücken kann es sich um Funktionsaufrufe, LIKE-Operatoren, CASE-Ausdrücke und Ähnliches handeln.
Bestimmte Funktionen und Operatoren werden von Parallel Query derzeit noch nicht herabgestuft. Wie viele solche Ausdrücke in einer Abfrage vorkommen, wird mit dem extra-Zähler in der EXPLAIN-Ausgabe angegeben. Der Rest der Abfrage verwendet Parallel Query.
Ausdrücke aus der Auswahlliste werden nicht herabgestuft. Für Abfragen mit solchen Funktionen kann es sich aber positiv auswirken, dass die Zwischenergebnisse von Parallelabfragen weniger Netzwerkdatenverkehr verursachen. So können beispielsweise Abfragen, die Aggregationsfunktionen aus der Auswahlliste aufrufen, von Parallelabfragen profitieren, selbst wenn die Aggregationsfunktionen selbst nicht herabgestuft werden.

Die nachfolgend abgebildete Abfrage scannt beispielsweise die gesamte Tabelle und verarbeitet alle Werte aus der P_BRAND-Spalte. Es handelt sich dabei allerdings nicht um eine Parallelabfrage, weil sie keine WHERE-Klausel enthält.


mysql> explain select count(*), p_brand from part group by p_brand;
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows     | Extra                           |
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+
|  1 | SIMPLE      | part  | ALL  | NULL          | NULL | NULL    | NULL | 20427936 | Using temporary; Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+

Die nächste Abfrage enthält hingegen WHERE-Prädikate, die die Ergebnisse filtern. Deshalb ist eine Parallelabfrage möglich:


mysql> explain select count(*), p_brand from part where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000
    -> group by p_brand;
+----+...+----------+-------------------------------------------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                                                       |
+----+...+----------+-------------------------------------------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using temporary; Using filesort; Using parallel query (5 columns, 1 filters, 2 exprs; 0 extra) |
+----+...+----------+-------------------------------------------------------------------------------------------------------------+

Wenn der Optimierer davon ausgeht, dass zu einem Abfrageblock nur wenige Zeilen zurückgegeben werden, wird Parallel Query für diesen Abfrageblock nicht verwendet. Im nachfolgenden Beispiel wird ein Größer-als-Operator in der Primärschlüssel-Spalte auf mehrere Millionen Zeilen angewendet. Das sorgt dafür, dass Parallel Query verwendet wird. Dagegen wird davon ausgegangen, dass die Kleiner-als-Gegenprobe nur auf wenige Zeilen anwendbar ist. Parallel Query kommt nicht zum Einsatz.


mysql> explain select count(*) from part where p_partkey > 10;
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

mysql> explain select count(*) from part where p_partkey < 10;
+----+...+------+--------------------------+
| id |...| rows | Extra                    |
+----+...+------+--------------------------+
|  1 |...|    9 | Using where; Using index |
+----+...+------+--------------------------+

Data Definition Language (DDL)

In Aurora-MySQL-Version 2 ist die parallele Abfrage nur für Tabellen verfügbar, für die keine schnellen DDL-Vorgänge (Data Definition Language) anstehen. In Aurora-MySQL-Version 3 können Sie eine parallele Abfrage für eine Tabelle gleichzeitig mit einem sofortigen DDL-Vorgang verwenden.

Instant DDL in Aurora-MySQL-Version 3 ersetzt die schnelle DDL-Funktion in Aurora-MySQL-Version 2. Informationen zu Instant-DDL finden Sie unter Sofortige DDL (Aurora MySQL Version 3).

Spaltendatentypen

In Aurora-MySQL-Version 3 kann die parallele Abfrage mit Tabellen arbeiten, die Spalten mit den Datentypen TEXT, BLOB, JSON und GEOMETRY enthalten. Es kann auch mit VARCHAR- und CHAR-Spalten mit einer maximalen deklarierten Länge von mehr als 768 Byte arbeiten. Wenn sich Ihre Abfrage auf Spalten bezieht, die so große Objekttypen enthalten, erhöht die zusätzliche Arbeit zum Abrufen der Abfrageverarbeitung einen gewissen Aufwand. Überprüfen Sie in diesem Fall, ob die Abfrage die Verweise auf diese Spalten weglassen kann. Wenn dies nicht der Fall ist, führen Sie Benchmarks aus, um zu bestätigen, ob solche Abfragen schneller sind, wenn die parallele Abfrage aktiviert oder deaktiviert ist.

In Aurora-MySQL-Version 2 hat die parallele Abfrage folgende Einschränkungen für große Objekttypen:

Die Datentypen TEXT, BLOB, JSON und GEOMETRY werden von parallelen Abfragen nicht unterstützt. Eine Abfrage, die sich auf Spalten dieses Typs bezieht, kann keine parallelen Abfragen nutzen.
Spalten unterschiedlicher Länge (Datentypen VARCHAR und CHAR) sind bis zur deklarierten Länge (max. 768 Byte) mit Parallel Query kompatibel. Eine Abfrage, die sich auf Spalten der Typen bezieht, die mit mehr Höchstlänge deklariert sind, kann Parallel Query nicht nutzen. In Spalten, in denen Zeichensätze mit mehreren Byte Länge vorkommen, ist im Byte-Höchstwert die maximale Byte-Anzahl des Zeichensatzes berücksichtigt. Für eine utf8mb4-Spalte mit dem Zeichensatz VARCHAR(192) (maximal 4 Byte Zeichenlänge) kann beispielsweise eine Parallelabfrage gestartet werden, nicht jedoch für eine VARCHAR(193)-Spalte.

Partitionierte Tabellen

In Aurora-MySQL-Version 3 können Sie partitionierte Tabellen mit Parallel Query verwenden. Da partitionierte Tabellen intern als mehrere kleinere Tabellen dargestellt werden, verwendet eine Abfrage, die eine parallele Abfrage für eine nicht partitionierte Tabelle verwendet, möglicherweise keine parallele Abfrage für eine identische partitionierte Tabelle. Aurora MySQL prüft, ob jede Partition groß genug ist, um sich für die parallele Abfrageoptimierung zu qualifizieren, anstatt die Größe der gesamten Tabelle auszuwerten. Prüfen Sie, ob die Statusvariable Aurora_pq_request_not_chosen_small_table inkrementiert wird, wenn eine Abfrage in einer partitionierten Tabelle die parallele Abfrage nicht wie erwartet verwendet.

Betrachten Sie beispielsweise eine Tabelle, die mit PARTITION BY HASH (column) PARTITIONS 2 partitioniert ist, und eine andere Tabelle, die mit PARTITION BY HASH (column) PARTITIONS 10 partitioniert ist. In der Tabelle mit zwei Partititionen sind die Partitionen fünfmal so groß wie die Tabelle mit zehn Partitionen. Daher wird eine parallele Abfrage eher für Abfragen gegen die Tabelle mit weniger Partitionen verwendet. Im folgenden Beispiel hat die Tabelle PART_BIG_PARTITIONS zwei Partitionen und PART_SMALL_PARTITIONS hat zehn Partitionen. Bei identischen Daten wird eine parallele Abfrage eher für die Tabelle mit weniger großen Partitionen verwendet.



mysql> explain select count(*), p_brand from part_big_partitions where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000 group by p_brand;
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+
| id | select_type | table               | partitions | Extra                                                                                                             |
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+
|  1 | SIMPLE      | part_big_partitions | p0,p1      | Using where; Using temporary; Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra; 1 group-bys, 1 aggrs) |
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+

mysql> explain select count(*), p_brand from part_small_partitions where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000 group by p_brand;
+----+-------------+-----------------------+-------------------------------+------------------------------+
| id | select_type | table                 | partitions                    | Extra                        |
+----+-------------+-----------------------+-------------------------------+------------------------------+
|  1 | SIMPLE      | part_small_partitions | p0,p1,p2,p3,p4,p5,p6,p7,p8,p9 | Using where; Using temporary |
+----+-------------+-----------------------+-------------------------------+------------------------------+

Aggregationsfunktionen, GROUP BY-Klauseln und HAVING-Klauseln

In Abfragen mit Aggregationsfunktionen werden große Tabellen mit sehr vielen Zeilen gescannt. Sie eignen sich deshalb oft besonders gut für Parallelabfragen.

In Aurora MySQL 3 kann eine parallele Abfrage Aggregatfunktionsaufrufe in der Auswahlliste und der Klausel HAVING optimieren.

Vor Aurora MySQL 3 werden Aggregatfunktionsaufrufe in der Auswahlliste oder der Klausel HAVING nicht auf die Speicherschicht übertragen. Eine parallele Abfrage kann dennoch die Leistung solcher Abfragen mit Aggregationsfunktionen verbessern – indem sie zuerst auf der Speicherschicht Spaltenwerte aus den Rohdatenseiten parallel extrahiert. Anschließend überträgt Parallel Query diese Werte in einem kompakten Tupelformat an den Hauptknoten zurück und nicht als vollständige Datenseiten. Wie immer muss die Abfrage mindestens 1 WHERE-Prädikat enthalten, das für Parallel Query aktiviert ist.

Die nachfolgenden einfach gehaltenen Beispiele veranschaulichen, welche aggregierte Abfragen von Parallel Query profitieren. Dies gilt zum einen durch Rückgabe unmittelbarer, kompakt gehaltener Ergebnisse an den Hauptknoten und eventuell zusätzlich durch Herausfilterung nicht passender Zeilen aus den Zwischenergebnissen.


mysql> explain select sql_no_cache count(distinct p_brand) from part where p_mfgr = 'Manufacturer#5';
+----+...+----------------------------------------------------------------------------+
| id |...| Extra                                                                      |
+----+...+----------------------------------------------------------------------------+
|  1 |...| Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------------------------------------------------------------------------+

mysql> explain select sql_no_cache p_mfgr from part where p_retailprice > 1000 group by p_mfgr having count(*) > 100;
+----+...+-------------------------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                                       |
+----+...+-------------------------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using filesort; Using parallel query (3 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+-------------------------------------------------------------------------------------------------------------+

Funktionsaufrufe in WHERE-Klausel

Aurora kann die Optimierung der parallelen Abfrageausführung auf Aufrufe der meisten integrierten Funktionen der WHERE-Klausel anwenden. Durch die Parallelisierung dieser Funktionsaufrufe wird der Hauptknoten entlastet, weil etwas CPU-Arbeitslast entfällt. Die parallel ablaufende Bewertung der Prädikatfunktionen in der ersten Abfragephase ermöglicht es Aurora, die Datenmenge zu minimieren, die im späteren Verlauf übertragen und verarbeitet werden muss.

Aktuell werden nicht alle Funktionsaufrufe aus der Auswahlliste parallelisiert. Diese Funktionen werden vom Hauptknoten auch dann bewertet, wenn in der WHERE-Klausel dieselben Funktionsaufrufe enthalten sind. Die ursprünglichen Werte aus betroffenen Spalten werden in die Tupel aufgenommen, die vom Speicherknoten zum Hauptknoten zurückübertragen werden. Der Hauptknoten führt alle Transformationen aus, z. B. UPPER, CONCATENATE usw., und generiert die endgültigen Werte für den Abfragesatz.

Im folgenden Beispiel parallelisiert Parallel Query den Aufruf von LOWER, da diese Funktion in der WHERE-Klausel enthalten ist. Parallel Query wirkt sich nicht auf die Aufrufe von SUBSTR und UPPER aus, da sie in der Auswahlliste stehen.


mysql> explain select sql_no_cache distinct substr(upper(p_name),1,5) from part
    -> where lower(p_name) like '%cornflower%' or lower(p_name) like '%goldenrod%';
+----+...+---------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                       |
+----+...+---------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+---------------------------------------------------------------------------------------------+

Die gleichen Überlegungen gelten für andere Ausdrücke wie CASE-Ausdrücke oder LIKE-Operatoren. Im der folgenden Beispiel ist beispielsweise zu sehen, dass die parallele Abfrage in der CASE-Klausel den LIKE-Ausdruck und die WHERE-Operatoren evaluiert.


mysql> explain select p_mfgr, p_retailprice from part
    -> where p_retailprice > case p_mfgr
    ->   when 'Manufacturer#1' then 1000
    ->   when 'Manufacturer#2' then 1200
    ->   else 950
    -> end
    -> and p_name like '%vanilla%'
    -> group by p_retailprice;
+----+...+-------------------------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                                       |
+----+...+-------------------------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using filesort; Using parallel query (4 columns, 0 filters, 2 exprs; 0 extra) |
+----+...+-------------------------------------------------------------------------------------------------------------+

LIMIT-Klausel

Derzeit können Abfrageblöcke mit LIMIT-Klausel nicht parallel abgefragt werden. Parallel Query könnte jedoch für frühere Abfragephasen mit GROUP BY, ORDER BY oder Join-Abfragen geeignet sein.

Vergleichsoperatoren

Der Optimierer schätzt ab, wie viele Zeilen gescannt werden müssen, um die Vergleichsoperatoren bewerten zu können, und entscheidet ausgehend von dieser Schätzung, ob Parallel Query verwendet wird.

Das erste Beispiel belegt, dass ein Gleichheitsvergleich gegen die Hauptschlüsselspalte effizient ohne Parallel Query möglich ist. Das zweite Beispiel belegt, dass für einen ähnlichen Vergleich gegen eine nicht indizierte Spalte mehrere Millionen Zeilen gescannt werden müssen. Parallel Query lohnt sich deshalb.


mysql> explain select * from part where p_partkey = 10;
+----+...+------+-------+
| id |...| rows | Extra |
+----+...+------+-------+
|  1 |...|    1 | NULL  |
+----+...+------+-------+

mysql> explain select * from part where p_type = 'LARGE BRUSHED BRASS';
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

Die gleichen Kriterien gelten für "ist ungleich"-Prüfungen und Bereichsvergleiche (z. B. kleiner als, größer als, ist gleich oder BETWEEN. Der Optimierer schätzt ab, wie viele Zeilen zu scannen sind, und entscheidet dann, ob sich eine parallele Abfrage angesichts des E/A-Gesamt-Volumens lohnt.

Joins

Join-Abfragen mit großen Tabellen sind in der Regel datenintensive Operationen, die von der Optimierung der parallelen Abfrageausführung profitieren. Derzeit werden Vergleiche von Spaltenwerten aus mehreren Tabellen (also die Join-Prädikate) nicht parallelisiert. Parallel Query kann allerdings einen Teil der internen Verarbeitung aus anderen Join-Phasen herunterstufen – z. B. die Erstellung des Bloom-Filters während eines Hash-Join. Parallel Query kann auch ohne WHERE-Klausel auf Join-Abfragen angewendet werden. Join-Abfragen sind in dieser Hinsicht Ausnahmen von der Regel, dass Parallelabfragen ohne WHERE-Klausel nicht möglich sind.

Jede Phase der Join-Verarbeitung wird ausgewertet, um festzustellen, ob sie für eine Parallelabfrage in Frage kommt. Falls mehrere Phasen parallelabfragetauglich sind, werden sie nacheinander ausgeführt. Was die Obergrenze für gleichzeitige Abfragen angeht, bedeutet dies, dass jede Join-Abfrage als separate Parallelabfragesitzung zählt.

Wenn eine Join-Abfrage beispielsweise mit WHERE-Prädikaten die Zeilen einer verknüpften Tabelle filtert, kann diese Filteroption Parallel Query verwenden. Ein weiteres Beispiel ist die Verknüpfung einer großen mit einer kleinen Tabelle mittels Hash-Join in einer Join-Abfrage. In diesem Fall kann der Tabellenscan für die Generierung der Datenstruktur des Bloom-Filters Parallel Query möglicherweise verwenden.

Anmerkung

Parallele Abfragen werden typischerweise für ressourcenintensive Abfragen verwendet, die von der Hash-Join-Optimierung profitieren. Die Methode zum Einschalten der Hash-Join-Optimierung hängt von der Aurora-MySQL-Version ab. Einzelheiten zu den einzelnen Versionen finden Sie unter Hash-Join für parallele Abfrage-Cluster aktivieren. Informationen zur effektiven Verwendung von Hash-Joins finden Sie unter Optimierung von großen Aurora-MySQL-Join-Abfragen mit Hash-Joins.


mysql> explain select count(*) from orders join customer where o_custkey = c_custkey;
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+
| id |...| table    | type  | possible_keys | key         |...| rows      | Extra                                                                                                           |
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+
|  1 |...| customer | index | PRIMARY       | c_nationkey |...|  15051972 | Using index                                                                                                     |
|  1 |...| orders   | ALL   | o_custkey     | NULL        |...| 154545408 | Using join buffer (Hash Join Outer table orders); Using parallel query (1 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+

In Join-Abfragen, die mit geschachtelten Schleifen arbeiten, könnte der äußerste geschachtelte Schleifenblock parallele Abfragen verwenden. Die Anwendung von parallelen Abfragen hängt von den gleichen Faktoren wie immer ab, z. B. dem Vorhandensein zusätzlicher Filterbedingungen in der WHERE-Klausel.


mysql> -- Nested loop join with extra filter conditions can use parallel query.
mysql> explain select count(*) from part, partsupp where p_partkey != ps_partkey and p_name is not null and ps_availqty > 0;
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+
| id | select_type | table    |...| rows     | Extra                                                                      |
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+
|  1 | SIMPLE      | part     |...| 20427936 | Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) |
|  1 | SIMPLE      | partsupp |...| 78164450 | Using where; Using join buffer (Block Nested Loop)                         |
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+

Unterabfragen

Der äußere Abfrageblock und der innere Unterabfrageblock können jeweils parallele Abfragen verwenden oder nicht. Ob sie dies tun, ist für jeden Block von den gewöhnlichen Eigenschaften der Tabelle, der WHERE-Klausel usw. abhängig. In der folgenden Abfrage kommt Parallel Query am Unterabfrageblock zum Einsatz, nicht jedoch am Außenblock.


mysql> explain select count(*) from part where
   --> p_partkey < (select max(p_partkey) from part where p_name like '%vanilla%');
+----+-------------+...+----------+----------------------------------------------------------------------------+
| id | select_type |...| rows     | Extra                                                                      |
+----+-------------+...+----------+----------------------------------------------------------------------------+
|  1 | PRIMARY     |...|     NULL | Impossible WHERE noticed after reading const tables                        |
|  2 | SUBQUERY    |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
+----+-------------+...+----------+----------------------------------------------------------------------------+

Für korrelierte Unterabfragen steht die Optimierung der parallelen Abfrageausführung nicht zur Verfügung.

UNION

Jeder Abfrageblock einer UNION-Abfrage kann parallele Abfragen Query nutzen (oder nicht). Ausschlaggebend sind die Tabelleneigenschaften und die WHERE-Klausel usw. des jeweiligen UNION-Teils.


mysql> explain select p_partkey from part where p_name like '%choco_ate%'
    -> union select p_partkey from part where p_name like '%vanil_a%';
+----+----------------+...+----------+----------------------------------------------------------------------------+
| id | select_type    |...| rows     | Extra                                                                      |
+----+----------------+...+----------+----------------------------------------------------------------------------+
|  1 | PRIMARY        |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
|  2 | UNION          |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
| NULL | UNION RESULT | <union1,2> |...|     NULL | Using temporary                                           |
+----+--------------+...+----------+----------------------------------------------------------------------------+

Anmerkung

Die UNION-Klauseln in der Abfrage werden nacheinander ausgeführt. Selbst wenn die Abfrage mehrstufig ist und in jeder Phase Parallel Query zum Einsatz kommt, führt sie Parallel Query jedes Mal separat aus. Deshalb gilt mit Hinblick auf die Höchstzahl gleichzeitig zulässiger Parallelabfragen auch eine komplexe mehrstufige Abfrage nur als 1 Abfrage.

Ansichten

Der Optimierer verwendet beim Umschreiben jeder Abfrage eine Ansicht als längere Abfrage. Dazu werden die zugrunde liegenden Tabellen verwendet. Das bedeutet, dass die Funktionsweise von Parallel Query unabhängig von der Tabellenreferenz (Ansicht oder tatsächliche Tabelle) gleich ist. Für die fertige umgeschriebene Abfrage gelten die gleichen Kriterien hinsichtlich der Verwendung von Parallel Query für eine Abfrage und hinsichtlich der Herabstufung einzelner Teile.

Beispielsweise zeigt der folgende Abfrageplan eine Ansichtsdefinition, die Parallel Query in der Regel nicht verwendet. Erst wenn die Ansicht mit zusätzlichen WHERE-Klauseln abgefragt wird, verwendet Aurora MySQL Parallel Query.


mysql> create view part_view as select * from part;
mysql> explain select count(*) from part_view where p_partkey is not null;
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (1 columns, 0 filters, 0 exprs; 1 extra) |
+----+...+----------+----------------------------------------------------------------------------+

DML-Anweisungen (Data Manipulation Language)

Die INSERT-Anweisung kann Parallel Query für die SELECT-Verarbeitungsphase verwenden, wenn der SELECT-Teil die sonstigen Bedingungen für eine Parallelabfrage erfüllt.


mysql> create table part_subset like part;
mysql> explain insert into part_subset select * from part where p_mfgr = 'Manufacturer#1';
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

Anmerkung

In der Regel liegen die Daten zu den neu eingefügten Zeilen nach der INSERT-Anweisung im Bufferpool. Deshalb kann sein, dass eine Tabelle unmittelbar nach dem Einfügen vieler Zeilen nicht für Parallel Query in Frage kommt. Erst wenn die Daten im normalen Betrieb aus dem Bufferpool entfernt wurden, können in Abfragen gegen die Tabelle wieder Parallelabfragen zum Einsatz kommen.

Die CREATE TABLE AS SELECT-Anweisung greift nicht auf Parallel Query zurück – auch dann nicht, wenn der SELECT-Teil der Anweisung ansonsten parallelabfragefähig ist. Diese Anweisung ist wegen ihres DDL-Anteils nicht für die Parallelabfrageverarbeitung geeignet. Dagegen kann der INSERT ... SELECT-Teil der SELECT-Anweisung Parallel Query verwenden.

Parallel Query wird nie verwendet, wenn DELETE- oder UPDATE-Anweisungen vorliegen. Dies gilt unabhängig von der Größe der Tabelle und der Prädikate aus der WHERE-Klausel.


mysql> explain delete from part where p_name is not null;
+----+-------------+...+----------+-------------+
| id | select_type |...| rows     | Extra       |
+----+-------------+...+----------+-------------+
|  1 | SIMPLE      |...| 20427936 | Using where |
+----+-------------+...+----------+-------------+

Transaktionen und Sperren

Sie können alle Isolationsebenen auf der primären Aurora-Instance verwenden.

Auf Aurora-Reader-DB-Instances gilt die parallele Abfrage für Anweisungen, die unter der REPEATABLE READ-Isolierungsstufe ausgeführt werden. Aurora MySQL-Versionen 2.09 oder höher können die READ COMMITTED-Isolierungsstufe auch auf Reader-DB-Instances verwenden. REPEATABLE READ ist die Standardisolierungsstufe für Aurora-Reader-DB-Instances. Um die Isolierungsstufe READ COMMITTED auf DB-Leser-Instances anzuwenden, muss die Konfigurationsoption aurora_read_replica_read_committed auf Sitzungsebene festgelegt werden. Die Isolierungsstufe READ COMMITTED für Reader-Instances entspricht dem SQL-Standardverhalten. Die Isolierung ist jedoch bei Reader-Instances weniger streng als bei Abfragen, welche die READ COMMITTED-Isolierungsstufe bei der Writer-Instance verwenden.

Weitere Informationen zu Aurora-Isolierungsstufen, insbesondere zu den Unterschieden in READ COMMITTED zwischen Writer- und Reader-Instances, finden Sie unter Aurora MySQL-Isolierungsstufen.

Nach Abschluss einer großen Transaktion kann es sein, dass die Tabellenstatistik veraltet ist. Für solche Statistiken ist möglicherweise eine ANALYZE TABLE-Anweisung erforderlich, damit Aurora die Zeilenzahl zuverlässig schätzen kann. Auch mit Hilfe einer umfangreichen DML-Anweisung könnte ein beträchtlicher Teil der Tabellendaten in den Bufferpool gelangen. Sind diese Daten im Bufferpool kann sein, dass diese Tabelle weniger häufig von Parallel Query abgefragt wird. Dies ändert sich, wenn die Daten aus dem Pool entfernt sind.

Wenn Ihre Sitzung Teil einer langwierigen Transaktion (standardmäßig 10 Minuten) ist, verwenden weitere Abfragen aus dieser Sitzung keine Parallelabfragen. Eine einzelne lang laufende Abfrage kann auch wegen Zeitüberschreitung abgebrochen werden. Dieser Überschreitungsabbruch kann eintreten, wenn die Abfrage länger läuft als zulässig (Höchstdauer derzeit: 10 Minuten), bevor die Parallelverarbeitung der Abfragen beginnt.

Das Risiko, dass lang laufende Transaktionen ungewollt gestartet werden, kann reduziert werden. Legen Sie dazu in autocommit=1-Sitzungen, in denen Sie Ad-hoc-Abfragen durchführen, die Einstellung mysql fest. Selbst eine SELECT-Anweisung gegen eine Tabelle startet eine Transaktion, indem sie eine Leseansicht erstellt. Eine Leseansicht ist ein einheitlicher Datensatz für nachfolgende Abfragen. Dieser bleibt bestehen, bis die Transaktion übernommen wurde. Denken Sie an diese Einschränkung, wenn Aurora für JDBC- oder ODBC-Anwendungen verwendet wird. Solche Anwendungen könnten nämlich auch dann zur Ausführung kommen, wenn die Einstellung autocommit deaktiviert ist.

Im nachfolgenden Beispiel ist zu sehen, wie eine Abfrageausführung gegen eine Tabelle (Einstellung autocommit deaktiviert) eine Leseansicht erzeugt, die implizit eine Transaktion in Gang setzt. Abfragen, die kurz danach gestartet werden, können Parallel Query noch nutzen. Nach mehreren Minuten kommen Abfragen jedoch nicht mehr für Parallel Query in Frage. Wenn Sie ans Ende der Transaktion COMMIT oder ROLLBACK stellen, kann Parallel Query wieder ausgeführt werden.


mysql> set autocommit=0;

mysql> explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+----+...+---------+----------------------------------------------------------------------------+
| id |...| rows    | Extra                                                                      |
+----+...+---------+----------------------------------------------------------------------------+
|  1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+---------+----------------------------------------------------------------------------+

mysql> select sleep(720); explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+------------+
| sleep(720) |
+------------+
|          0 |
+------------+
1 row in set (12 min 0.00 sec)

+----+...+---------+-------------+
| id |...| rows    | Extra       |
+----+...+---------+-------------+
|  1 |...| 2976129 | Using where |
+----+...+---------+-------------+

mysql> commit;

mysql> explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+----+...+---------+----------------------------------------------------------------------------+
| id |...| rows    | Extra                                                                      |
+----+...+---------+----------------------------------------------------------------------------+
|  1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+---------+----------------------------------------------------------------------------+

Um festzustellen, wie oft Abfragen nicht für Parallel Query in Frage kamen, weil sie Teil lang laufender Transaktionen waren, untersuchen Sie die Statusvariable Aurora_pq_request_not_chosen_long_trx.


mysql> show global status like '%pq%trx%';
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| Aurora_pq_request_not_chosen_long_trx | 4     |
+-------------------------------+-------+

SELECT-Anweisungen, die Sperren annehmen (z. B. Syntax SELECT FOR UPDATE oder SELECT LOCK IN SHARE MODE), können Parallel Query nicht verwenden.

Parallel Query kann an Tabellen funktionieren, die mit einer LOCK TABLES-Anweisung gesperrt sind.


mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk = 'Clerk#000095055';
+----+...+-----------+----------------------------------------------------------------------------+
| id |...| rows      | Extra                                                                      |
+----+...+-----------+----------------------------------------------------------------------------+
|  1 |...| 154545408 | Using where; Using parallel query (3 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+-----------+----------------------------------------------------------------------------+

mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk = 'Clerk#000095055' for update;
+----+...+-----------+-------------+
| id |...| rows      | Extra       |
+----+...+-----------+-------------+
|  1 |...| 154545408 | Using where |
+----+...+-----------+-------------+

B-Baum-Indizes

Die von der ANALYZE TABLE-Anweisung erfassten Statistiken unterstützen den Optimierer bei der Entscheidung für Parallelabfragen oder Index-Lookups. Ausschlaggebend sind die Eigenschaften der Daten in den Spalten. Nach DML-Operationen können die Daten einer Tabelle nachhaltig verändert sein. Um die Statistiken auf dem aktuellen Stand zu halten, führen Sie nach der Operation ANALYZE TABLE aus.

Wenn Index-Lookups ausreichen, um eine Abfrage effizient ohne datenintensiven Scan auszuführen, verwendet Aurora möglicherweise Index-Lookups. Dadurch erübrigt sich der Zusatzaufwand der Parallelabfrageverarbeitung. Außerdem regeln Obergrenzen, wie viele Abfragen gleichzeitig in einem Aurora-DB-Cluster zulässig sind. Die Einhaltung bewährter Methoden bei der Indizierung von Tabellen trägt dazu bei, dass in den häufigsten und besonders oft gleichzeitig ausgeführten Abfragen Index-Lookups zur Anwendung kommen.

Volltextsuche (FTS)-Indizes

Zurzeit wird Parallel Query nicht für Tabellen mit Volltextsuchindex verwendet. Dies gilt unabhängig davon, ob sich die Abfrage auf solche indizierten Spalten bezieht oder ob sie den Operator MATCH verwendet.

Virtuelle Spalten

Zurzeit wird Parallel Query nicht für Tabellen verwendet, die eine virtuelle Spalte enthalten. Dies gilt unabhängig davon, ob die Abfrage auf virtuelle Spalten verweist.

Integrierte Caching-Mechanismen

Aurora enthält integrierte Caching-Mechanismen: den Bufferpool und den Abfrage-Cache. Der Aurora-Optimierer entscheidet, ob einer dieser Caching-Mechanismen oder Parallel Query für eine bestimmte Abfrage besser geeignet ist.

Wenn eine Parallelabfrage Zeilen filtert und Spaltenwerte transformiert/extrahiert, werden Daten als Tupel an den Hauptknoten zurückübertragen – nicht als Datenseiten. Das bedeutet also, dass bei Verwendung von Parallel Query dem Bufferpool keine Seiten hinzugefügt werden. Es werden auch keine Seiten entfernt, die bereits im Bufferpool sind.

Aurora überprüft die Anzahl der Tabellendatenseiten, die im Pufferpool vorhanden sind und welchen Anteil der Tabellendaten diese Zahl darstellt. Aurora verwendet diese Informationen, um zu bestimmen, ob es effizienter ist, parallele Abfragen zu verwenden (und die Daten im Pufferpool zu umgehen). Es ist auch möglich, dass Aurora den nicht-parallelen Abfrageverarbeitungspfad verwendet, der auf Daten aus dem Bufferpool zurückgreift. Welche Seiten im Cache abgelegt sind und wie sich datenintensive Abfragen auf das Caching und die Bereinigung auswirken, hängt von den Konfigurationseinstellungen des Bufferpools ab. Es kann deshalb schwierig vorherzusagen sein, ob eine Abfrage mit Parallel Query ausgeführt wird. Dies hängt von den Daten im Bufferpool ab, deren Zusammensetzung sich ständig ändert.

Außerdem begrenzt Aurora, wie viele Parallelabfragen gleichzeitig möglich sind. Parallel Query kommt nicht für jede Abfrage zum Einsatz. Deshalb befinden sich die Daten von Tabellen, die von mehreren Abfragen gleichzeitig genutzt werden, zu einem beträchtlichen Teil im Bufferpool. Dementsprechend nutzt Aurora diese Tabellen nicht oft für Parallelabfragen.

In einer Abfolge nicht-paralleler Abfragen gegen dieselbe Tabelle ist die erste Abfrage möglicherweise langsam, weil die Daten nicht im Bufferpool sind. Die zweite und nachfolgende Abfragen laufen bereits schneller ab, weil der Bufferpool inzwischen sozusagen "warmgelaufen" ist. In der Regel zeigen Parallelabfragen ab der ersten Tabellenabfrage gleichbleibende Leistung Für Leistungstests empfehlen sich Vergleichswerte für einen kalten und einen warmen Bufferpool. In einigen Fällen sind die Ergebnisse des warmen Bufferpools eine gute Vergleichsbasis für Parallelabfragezeiten. Berücksichtigen Sie in diesen Fällen Faktoren wie die Häufigkeit von Abfragen für diese Tabelle. Überlegen Sie auch, ob es sich lohnt, die Daten für diese Tabelle im Pufferpool zu behalten.

Der Abfrage-Cache vermeidet die erneute Ausführung einer Abfrage, wenn eine identische Abfrage abgesendet wird und die zugrunde liegenden Tabellendaten nicht geändert wurden. Mit Parallel Query optimierte Abfragen können im Abfrage-Cache abgelegt werden. Wird die gleiche Abfrage noch einmal gestartet, liegt sofort ein Ergebnis vor.

Anmerkung

Bei Leistungsvergleichen können aufgrund des Abfrage-Cache künstlich niedrige Zeitangaben zustandekommen. Für Benchmark-ähnliche Aufgabenstellungen empfiehlt sich der sql_no_cache-Hinweis. Dieser verhindert, dass das Ergebnis aus dem Abfrage-Cache kommt. Auch dann nicht, wenn die gleiche Abfrage schon einmal ausgeführt wurde. Der Hinweis folgt in der Abfrage unmittelbar nach der SELECT-Anweisung. Viele Beispiele für parallele Abfragen in diesem Thema enthalten diesen Hinweis, um die Abfragezeiten zwischen den Versionen der Abfrage vergleichbar zu machen, für welche die parallele Abfrage aktiviert und deaktiviert ist.

Entfernen Sie diesen Hinweis aus Ihrem Quellcode, bevor Sie parallele Abfragen in einer Produktionsumgebung verwenden.

Optimierungshinweise

Eine andere Möglichkeit, den Optimierer zu steuern, besteht in der Verwendung von Optimierungshinweisen, die in einzelnen Anweisungen angegeben werden können. Sie können beispielsweise eine Optimierung für eine Tabelle in einer Anweisung aktivieren und dann die Optimierung für eine andere Tabelle deaktivieren. Weitere Informationen zu diesen Hinweisen finden Sie unter Optimierungshinweise im MySQL-Referenzhandbuch.

Sie können SQL-Hinweise mit Aurora-MySQL-Abfragen verwenden, um die Leistung zu optimieren. Sie können auch Hinweise verwenden, um zu verhindern, dass Ausführungspläne für wichtige Abfragen aufgrund unvorhersehbarer Bedingungen geändert werden.

Wir haben die Funktion für SQL-Hinweise erweitert, damit Sie die Optimiererauswahl für Ihre Abfragepläne besser kontrollieren können. Diese Hinweise gelten für Abfragen, bei denen die Parallelabfrageoptimierung verwendet wird. Weitere Informationen finden Sie unter Aurora-MySQL-Hinweise.

Temporäre MyISAM-Tabellen

Die parallele Abfrageausführung ist nur möglich, wenn InnoDB-Tabellen vorliegen. Aurora MySQL verwendet MyISAM im Hintergrund für temporäre Tabellen. Interne Abfragephasen mit temporären Tabellen werden nie parallel abgefragt. Diese Abfragephasen erkennen Sie am Code Using temporary in der EXPLAIN-Ausgabe.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Die Datenbank erstellt temporäre Tabellen auf der Festplatte

Advanced Auditing mit Aurora MySQL