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

Bewährte Methoden für SQL Leistung und Skalierung von Aurora My

Sie können die folgenden bewährten Methoden anwenden, um die Leistung und Skalierbarkeit Ihrer Aurora SQL My-Cluster zu verbessern.

Verwendung von T-Instance-Klassen für Entwicklung und Tests

Amazon Aurora My SQL Instancesdb.t2, die die Instance-Klassendb.t3,, oder db.t4g DB verwenden, eignen sich am besten für Anwendungen, die über einen längeren Zeitraum keine hohe Arbeitslast unterstützen. Die T-Instanzen sind so konzipiert, dass sie eine mäßige Basisleistung bieten und je nach Workload eine deutlich höhere Leistung erreichen können. Sie sind für Workloads vorgesehen, die nicht CPU oft oder konsistent die volle Kapazität nutzen, aber gelegentlich überlastet werden müssen. Wir empfehlen, die T-DB-Instance-Klassen nur für Entwicklungs- und Testserver oder andere Nicht-Produktionsserver zu verwenden. Weitere Einzelheiten zu den T-Instance-Klassen finden Sie unter Burstable Performance Instances.

Wenn Ihr Aurora-Cluster größer als 40 TB ist, sollten Sie die T-Instance-Klassen nicht verwenden. Wenn Ihre Datenbank ein großes Datenvolumen hat, kann der Speicher-Overhead für die Verwaltung von Schemaobjekten die Kapazität einer T-Instance übersteigen.

Aktivieren Sie das My SQL Performance Schema nicht auf Amazon Aurora My SQL T-Instances. Wenn das Leistungsschema aktiviert ist, geht der Instance möglicherweise der Speicher aus.

Wenn Sie eine T-Instance als DB-Instance in einem Aurora My SQL DB-Cluster verwenden, empfehlen wir Folgendes:

Optimierung von Aurora My SQL indexierten Join-Abfragen mit asynchronem Schlüssel-Prefetch

Aurora My SQL kann die Funktion prefetch (AKP) für asynchrone Schlüssel verwenden, um die Leistung von Abfragen zu verbessern, die Tabellen indexübergreifend verbinden. Diese Funktion verbessert die Leistung, indem sie die Zeilen antizipiert, die für die Ausführung von Abfragen benötigt werden, bei denen eine JOIN Abfrage den Join-Algorithmus Batched Key Access (BKA) und die Optimierungsfunktionen Multi-Range Read () erfordert. MRR Weitere Informationen zu BKA und MRR finden Sie unter Block Nested-Loop und Batched Key Access Joins und Multi-Range-Leseoptimierung in der Dokumentation Meine Dokumentation. SQL

Um diese AKP Funktion nutzen zu können, muss eine Abfrage sowohl als auch verwenden. BKA MRR In der Regel tritt eine solche Abfrage auf, wenn die JOIN Klausel einer Abfrage einen sekundären Index verwendet, aber auch einige Spalten aus dem Primärindex benötigt. Sie können dies beispielsweise verwenden, AKP wenn eine JOIN Klausel ein Äquijoin für Indexwerte zwischen einer kleinen äußeren und einer großen inneren Tabelle darstellt und der Index in der größeren Tabelle sehr selektiv ist. AKParbeitet zusammen mit der Klausel BKA und MRR führt bei der Auswertung der JOIN Klausel eine Suche nach einem Sekundärindex zum Primärindex durch. AKPidentifiziert die Zeilen, die für die Ausführung der Abfrage während der Auswertung der JOIN Klausel erforderlich sind. Anschließend werden die Seiten, die diese Zeilen enthalten, mit einem Hintergrund-Thread asynchron in den Speicher geladen, bevor die Abfrage ausgeführt wird.

AKPist für Aurora My SQL Version 2.10 und höher und Version 3 verfügbar. Weitere Informationen zu Aurora SQL My-Versionen finden Sie unterDatenbank-Engine-Updates für Amazon Aurora My SQL.

Asynchrones Key Prefetch aktivieren

Sie können die AKP Funktion aktivierenaurora_use_key_prefetch, indem Sie eine My SQL Server-Variable auf setzenon. Standardmäßig ist dieser Wert auf on festgelegt. AKPKann jedoch erst aktiviert werden, wenn Sie auch den BKA Join-Algorithmus aktivieren und die kostenbasierte MRR Funktionalität deaktivieren. Dazu müssen Sie die folgenden Werte für optimizer_switch eine SQL Servervariable vom Typ „Mein Server“ festlegen:

Derzeit können Sie diese Werte nur auf Sitzungsebene festlegen. Das folgende Beispiel zeigt, wie Sie diese Werte so einstellen, dass sie AKP für die aktuelle Sitzung aktiviert werden, indem SET Anweisungen ausgeführt werden.

mysql> set @@session.aurora_use_key_prefetch=on;
mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';

In ähnlicher Weise können Sie SET Anweisungen verwenden, um den BKA Join-Algorithmus zu deaktivieren AKP und die kostenbasierte MRR Funktionalität für die aktuelle Sitzung wieder zu aktivieren, wie im folgenden Beispiel gezeigt.

mysql> set @@session.aurora_use_key_prefetch=off;
mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';

Weitere Informationen zu den Optimierer-Switches batched_key_access und mrr_cost_based finden Sie in der Dokumentation Meine Dokumentation unter Switchable Optimizations. SQL

Optimieren von Abfragen für asynchrones Key Prefetch

Sie können überprüfen, AKP ob eine Abfrage die Funktion nutzen kann. Verwenden Sie dazu die EXPLAIN-Anweisung, um die Abfrage vor der Ausführung zu profilieren. Die EXPLAIN-Anweisung stellt Informationen über den Ausführungsplan bereit, der für eine angegebene Abfrage verwendet werden soll.

In der Ausgabe der EXPLAIN-Anweisung beschreibt die Spalte Extra zusätzliche Informationen, die im Ausführungsplan eingeschlossen sind. Wenn die AKP Funktion für eine in der Abfrage verwendete Tabelle gilt, enthält diese Spalte einen der folgenden Werte:

Das folgende Beispiel zeigt die Verwendung vonEXPLAIN, um den Ausführungsplan für eine Abfrage anzuzeigen, die Sie nutzen könnenAKP.

mysql> explain select sql_no_cache
    ->     ps_partkey,
    ->     sum(ps_supplycost * ps_availqty) as value
    -> from
    ->     partsupp,
    ->     supplier,
    ->     nation
    -> where
    ->     ps_suppkey = s_suppkey
    ->     and s_nationkey = n_nationkey
    ->     and n_name = 'ETHIOPIA'
    -> group by
    ->     ps_partkey having
    ->         sum(ps_supplycost * ps_availqty) > (
    ->             select
    ->                 sum(ps_supplycost * ps_availqty) * 0.0000003333
    ->             from
    ->                 partsupp,
    ->                 supplier,
    ->                 nation
    ->             where
    ->                 ps_suppkey = s_suppkey
    ->                 and s_nationkey = n_nationkey
    ->                 and n_name = 'ETHIOPIA'
    ->         )
    -> order by
    ->     value desc;
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| id | select_type | table    | type | possible_keys         | key           | key_len | ref                              | rows | filtered | Extra                                                       |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
|  1 | PRIMARY     | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where; Using temporary; Using filesort                |
|  1 | PRIMARY     | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  1 | PRIMARY     | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
|  2 | SUBQUERY    | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where                                                 |
|  2 | SUBQUERY    | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  2 | SUBQUERY    | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)

Weitere Informationen zum EXPLAIN Ausgabeformat finden Sie unter Erweitertes EXPLAIN Ausgabeformat in der SQL Dokumentation Meine.

Optimierung großer Aurora My SQL Join-Abfragen mit Hash-Joins

Wenn Sie eine große Datenmenge mit Hilfe eines Equijoins verknüpfen müssen, kann ein Hash-Join die Abfrageleistung verbessern. Sie können Hash-Joins für Aurora My aktivierenSQL.

Eine Hash-Join-Spalte kann ein beliebiger komplexer Ausdruck sein. In einer Hash-Join-Spalte haben Sie folgende Möglichkeiten, Datentypen übergreifend zu vergleichen:

Die folgenden Einschränkungen gelten für Hash-Joins für Aurora MySQL:

Aktivieren von Hash-Joins

So aktivieren Sie Hash-Joins:

Hash-Joins sind in Aurora My SQL Version 3 standardmäßig aktiviert und in Aurora My SQL Version 2 standardmäßig deaktiviert. Das folgende Beispiel zeigt, wie Hash-Joins für Aurora My SQL Version 3 aktiviert werden. Sie können zuerst die Anweisung select @@optimizer_switch ausgeben, um zu sehen, welche anderen Einstellungen in der SET-Parameterzeichenfolge vorhanden sind. Das Aktualisieren einer Einstellung im Parameter optimizer_switch löscht oder ändert die anderen Einstellungen nicht.

mysql> SET optimizer_switch='block_nested_loop=on';

Mit dieser Einstellung wählt der Optimierer einen Hash-Join auf der Grundlage von Kosten, Abfragemerkmalen und Ressourcenverfügbarkeit. Wenn die Kalkulation fehlerhaft ist, können Sie den Optimierer zwingen, einen bestimmten Hash-Join zu wählen. Sie tun dieshash_join_cost_based, indem Sie eine My SQL Server-Variable auf setzenoff. Das folgende Beispiel zeigt, wie Sie den Optimierer zwingen können, einen Hash-Join zu wählen.

mysql> SET optimizer_switch='hash_join_cost_based=off';

Optimieren von Abfragen für Hash-Joins

Um herauszufinden, ob eine Abfrage einen Hash-Join nutzen kann, verwenden Sie die EXPLAIN-Anweisung, um die Abfrage zuerst zu profilieren. Die EXPLAIN-Anweisung stellt Informationen über den Ausführungsplan bereit, der für eine angegebene Abfrage verwendet werden soll.

In der Ausgabe der EXPLAIN-Anweisung beschreibt die Spalte Extra zusätzliche Informationen, die im Ausführungsplan eingeschlossen sind. Wenn ein Hash-Join für die in der Abfrage verwendeten Tabellen gilt, enthält diese Spalte Werte, die den folgenden ähnlich sind:

Das folgende Beispiel zeigt die Verwendung vonEXPLAIN, um den Ausführungsplan für eine Hash-Join-Abfrage anzuzeigen.

mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2
    ->     WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra                                                          |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
|  1 | SIMPLE      | hj_small | ALL  | NULL          | NULL | NULL    | NULL |    6 | Using temporary; Using filesort                                |
|  1 | SIMPLE      | hj_big   | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer (Hash Join Outer table hj_big)  |
|  1 | SIMPLE      | hj_big2  | ALL  | NULL          | NULL | NULL    | NULL |   15 | Using where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
3 rows in set (0.04 sec)

In der Ausgabe ist der Hash Join Inner table die Tabelle, die zum Aufbau der Hash-Tabelle verwendet wird, und der Hash Join Outer table ist die Tabelle, die zum Prüfen der Hash-Tabelle verwendet wird.

Weitere Informationen zum erweiterten EXPLAIN Ausgabeformat finden Sie unter Erweitertes EXPLAIN Ausgabeformat in der Dokumentation Mein SQL Produkt.

In Aurora My SQL 2.08 und höher können Sie mithilfe von SQL Hinweisen beeinflussen, ob eine Abfrage einen Hash-Join verwendet oder nicht und welche Tabellen für die Build- und Test-Seite des Joins verwendet werden sollen. Details hierzu finden Sie unter Aurora Meine SQL Tipps.

Verwenden von Amazon Aurora zur Skalierung von Lesevorgängen für Ihre Meine SQL Datenbank

Sie können Amazon Aurora mit Ihrer My SQL DB-Instance verwenden, um die Vorteile der Leseskalierung von Amazon Aurora zu nutzen und den Lese-Workload für Ihre My SQL DB-Instance zu erweitern. Um Aurora für die Leseskalierung Ihrer My SQL DB-Instance zu verwenden, erstellen Sie einen Aurora My SQL DB-Cluster und machen Sie ihn zu einer Read Replica Ihrer My SQL DB-Instance. Stellen Sie dann eine Verbindung zum Aurora SQL My-Cluster her, um die Leseabfragen zu verarbeiten. Bei der Quelldatenbank kann es sich um eine RDS For My SQL DB-Instance oder um eine My SQL Database handeln, die extern zu Amazon läuftRDS. Weitere Informationen finden Sie unter Skalierung von Lesevorgängen für Ihre My SQL Database mit Amazon Aurora.

Optimierung von Zeitstempeloperationen

Wenn der Wert der Systemvariablen auf gesetzt time_zone ist, führt jeder SQL Funktionsaufruf von MySYSTEM, der eine Zeitzonenberechnung erfordert, einen Systembibliotheksaufruf durch. Wenn Sie SQL Anweisungen ausführen, die solche TIMESTAMP Werte zurückgeben oder ändern, bei hoher Parallelität, kann es zu erhöhter Latenz, Sperrkonflikten und CPU erhöhter Auslastung kommen. Weitere Informationen finden Sie unter time_zone in der Dokumentation „Meine“. SQL

Wir empfehlen, den Wert des DB-Cluster-Parameters time_zone in UTC zu ändern, um dieses Verhalten zu vermeiden. Weitere Informationen finden Sie unter Ändern von Parametern in einer DB-Cluster-Parametergruppe in Amazon Aurora.

Der Parameter time_zone ist zwar dynamisch (er erfordert keinen Neustart des Datenbankservers), der neue Wert wird jedoch nur für neue Verbindungen verwendet. Um sicherzustellen, dass alle Verbindungen so aktualisiert werden, dass sie den neuen time_zone-Wert verwenden, empfehlen wir, Ihre Anwendungsverbindungen nach der Aktualisierung des DB-Cluster-Parameters wiederzuverwenden.