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.

Schreib-Workloads optimieren

Durch die Implementierung eines Load Balancer und die Freigabe der Writer-Instance kann Ihr Schreib-Workload bei hohen Leistungsspitzen besser ausgeführt werden. Folgen Sie diesen zusätzlichen Schritten, um bei hoher Parallelität eine bessere Schreibleistung zu erzielen.

Verschieben der referenziellen Integrität in die Anwendungsebene

Obwohl Prüfungen der referenziellen Integrität wichtig sind, können sie sich bei Hyperscaling nachteilig auf Ihre Auslastung auswirken. Für jeden Schreibvorgang müssen zusätzliche Scans durchgeführt werden, bevor der Schreibvorgang selbst ausgeführt wird, was zu einer schlechten Leistung führt. Wenn für Ihre Anwendung strenge Integritätsprüfungen erforderlich sind, bauen Sie diese in die Anwendungsebene ein, um zu verhindern, dass sie Ihre Schreibvorgänge drosseln.

Vermeiden der Verwendung schwerer Primärschlüssel

Sorgen Sie dafür, dass Ihre Primärschlüssel leicht sind. Die InnoDB-Speicher-Engine hängt den Primärschlüssel an jeden anderen Index an, den Sie in Ihrer Tabelle erstellen. Wenn Ihr Primärschlüssel groß ist, wirkt sich dies auf die Größe des Index aus. Das Speichern und Abrufen von Datenseiten wird langsamer, wenn der Primärschlüssel ziemlich groß ist. Ein gängiges Beispiel ist die Verwendung von universell eindeutigen Identifikatoren als Primärschlüssel. Dies ist kein guter Ansatz, wenn Sie die Leistung in einer hyperskalierten Umgebung anstreben.

Verwenden von Partition Exchange, um Daten in partitionierte Tabellen zu laden

Wenn Sie große Datenmengen in partitionierte Tabellen schreiben, kann die Kombination von DATEN VON S3 LADEN und Partition Exchange die Leistung verbessern, da für die Einfügungen nicht auf die Haupttabelle zugegriffen wird. Beim Partition Exchange wird eine Datendefinitionssprache (DDL) verwendet, und Ihre Tabelle wird mit einer Metadatensperre versehen. Stellen Sie sicher, dass dies geschieht, wenn nur wenige oder gar keine Abfragen für die Tabelle ausgeführt werden, sodass die Partition-Exchange-DDL die Metadatensperre ohne Wartezeiten erhalten kann. Der Austausch selbst dauert nur Millisekunden.

Entferne nicht verwendete Indizes

InnoDB optimiert seine Abfragepläne auf der Grundlage des Wachstums Ihrer Daten, und es ist eine gute Idee, nach ungenutzten Indizes in Ihrer Datenbank zu suchen und diese zu entfernen. Unbenutzte Indizes verbrauchen I/O, wenn die Anwendung Daten in eine Tabelle schreibt. Überprüfen Sie die Liste der ungenutzten Indizes und stellen Sie sicher, dass es sich nicht um Indizes handelt, die in seltenen Situationen verwendet werden, z. B. in Quartalsberichten. Beachten Sie außerdem, dass einige Indizes verwendet werden, um Eindeutigkeit oder Reihenfolge zu erzwingen, und dass sie ebenfalls berücksichtigt werden müssen.

Sicherstellen, dass alte Zeilenversionen effizient gelöscht werden

In der InnoDB-Implementierung von Multiversion Concurrency Control (MVCC) wird bei der Änderung eines Datensatzes die aktuelle (alte) Version der geänderten Daten zunächst als undo record in ein Undo-Protokoll geschrieben. Ein HLL-Wert (Growing History List Length) weist darauf hin, dass die InnoDB-Garbage-Collection-Threads (Purge-Threads) nicht mit dem Schreib-Workload Schritt halten oder dass das Löschen durch eine lang andauernde Abfrage oder Transaktion blockiert wird. Wenn Garbage Collection blockiert oder verzögert wird, kann es in der Datenbank zu einer erheblichen Verzögerung beim Löschen kommen, was sich negativ auf die Abfrageleistung auswirken kann. Sie können die folgenden Empfehlungen zur Optimierung des Löschvorgangs verwenden.

Stellen Sie sicher, dass die Protokollierung keine zusätzlichen Konflikte verursacht

Das allgemeine Abfrageprotokoll zeichnet die Verbindungen und Verbindungsabbrüche der Clients sowie alle vom Server empfangenen Anweisungen in der Reihenfolge auf, in der sie empfangen wurden. Wenn diese Option aktiviert ist, erfolgt die Protokollierung synchron, was auf einem ausgelasteten System zu erheblichen Leistungseinbußen führen kann. Sofern nicht erforderlich, empfehlen wir, das allgemeine Protokoll zu deaktivieren.

Das Slow Query Log zeichnet Anweisungen auf, die länger gedauert haben als die long_query_time-Anzahl der Sekunden, die ausgeführt werden sollen, mit der Standardeinstellung von 10 Sekunden. Wenn die Einstellung auf 0 gesetzt ist, werden alle Anweisungen synchron protokolliert, was bei stark frequentierten Datenbanken zu Leistungseinbußen führen kann.