Welche Vor- und Nachteile hat MySQL, und wann ist es eine gute Wahl?
MySQL ist ein relationales Datenbankmanagementsystem, das für typische Webdienste und die Online-Transaktionsverarbeitung (OLTP) eingesetzt werden kann, insbesondere mit der InnoDB-Speicher-Engine und ihren Funktionen wie Transaktionen, Sperren auf Zeilenebene und konsistenten Lesevorgängen. Andererseits ist die Lesereplikation standardmäßig asynchron, und Hochverfügbarkeitskonfigurationen, komplexe Abfragen sowie die Partitionierung unterliegen Design- und Betriebsbeschränkungen. Vorteile werden nur dann zu echten Vorteilen, wenn sie zur Arbeitslast und zu den betrieblichen Fähigkeiten des Teams passen. dev.mysql.com dev.mysql.com
Bei der Bewertung von MySQL ist es treffender zu betrachten, wie Daten gelesen und geschrieben werden, was bei Ausfällen garantiert werden muss und wie komplex das Schema werden wird, als lediglich zu fragen, ob es sich um eine „schnelle Datenbank“ handelt. Die folgende Erörterung orientiert sich am Umfang der offiziellen MySQL-8.4-Dokumentation. Das tatsächliche Verhalten kann je nach Version, Speicher-Engine, Konfiguration und Replikationstopologie abweichen. dev.mysql.com
Welche Art von Datenbank ist MySQL?
Eine relationale Datenbank speichert Daten in Tabellen aus Zeilen und Spalten und nutzt die Abfragesprache SQL, um Beziehungen zwischen Tabellen zu verwalten. Ein Onlineshop kann beispielsweise Tabellen wie customers, orders und order_items verwenden, um Beziehungen zwischen Kunden, Bestellungen und bestellten Produkten zu verwalten. In vielen Fällen müssen mehrere Änderungen zu einem Vorgang zusammengefasst werden, etwa das Anlegen einer Bestellung, das Verringern des Lagerbestands und das Erfassen des Zahlungsstatus.
Speicher-Engines sind in MySQL wichtig. Eine Speicher-Engine ist eine Komponente, die dafür verantwortlich ist, wie Tabellen gespeichert, gesperrt und wiederhergestellt werden. Insbesondere ist InnoDB die Standard-Speicher-Engine von MySQL und bietet ACID-Transaktionen, Commits und Rollbacks, Wiederherstellung nach Abstürzen, Sperren auf Zeilenebene, Multiversion Concurrency Control (MVCC) und Fremdschlüssel. Daher bezieht sich die Transaktionszuverlässigkeit, die üblicherweise mit MySQL verbunden wird, oft auf MySQL mit korrekt konfigurierten InnoDB-Tabellen. dev.mysql.com
ACID ist ein Sammelbegriff für die erwarteten Eigenschaften von Transaktionen. Atomarität bedeutet, dass ein gesamter Vorgang entweder erfolgreich ist oder abgebrochen wird. Konsistenz bedeutet, dass definierte Datenregeln eingehalten werden. Isolation steuert die Auswirkungen gleichzeitig ausgeführter Vorgänge aufeinander, während Dauerhaftigkeit bedeutet, dass bestätigte Ergebnisse Ausfälle überstehen müssen. Die ACID-Eigenschaften von MySQL werden ebenfalls durch Engine, Konfiguration, Hardware und Betriebsverfahren beeinflusst; der Name allein sollte daher nicht so verstanden werden, dass er automatisch jedes Ausfallszenario löst. dev.mysql.com
Warum sind InnoDB-Transaktionen und Parallelität ein Vorteil?
OLTP bezeichnet Arbeitslasten mit häufigen, relativ kurzen Anfragen, etwa dem Entgegennehmen von Bestellungen, dem Aktualisieren von Mitgliedsdaten oder dem Ändern des Zahlungsstatus. In dieser Umgebung können viele Benutzer gleichzeitig dieselben Arten von Daten ändern. Deshalb ist es wichtig, Datenänderungen sicher zu gruppieren und den Umfang von Konflikten möglichst klein zu halten.
Da InnoDB Transaktions-Commits, Rollbacks und Wiederherstellung nach Abstürzen bereitstellt, kann eine Anwendung beispielsweise so konfiguriert werden, dass sie eine Transaktion zurücksetzt, wenn beim Anlegen einer Bestellung und beim Verringern des Lagerbestands ein Schritt fehlschlägt. Sperren auf Zeilenebene sperren bei Bedarf bestimmte Zeilen und können für parallele Arbeit günstiger sein als das breite Sperren einer ganzen Tabelle. Wartezeiten und Konflikte verschwinden jedoch nicht, wenn mehrere Vorgänge häufig um dieselben Zeilen oder benachbarte Datenbereiche konkurrieren. dev.mysql.com
MVCC ermöglicht konsistente Lesevorgänge durch die Verwendung mehrerer Datenversionen. Das bedeutet nicht einfach, dass Lese- und Schreibvorgänge sich niemals gegenseitig beeinflussen. Die beobachteten Ergebnisse und das Sperrverhalten können je nach Isolationsstufe einer Transaktion, den ausgeführten SQL-Anweisungen und der Verwendung sperrender Lesevorgänge unterschiedlich sein. Prüfen Sie bei der Lösung von Parallelitätsproblemen daher nicht nur den Namen der Engine. Definieren Sie zunächst in den Geschäftsregeln, welche Lesevorgänge den neuesten Wert sehen müssen und welche Aktualisierungen sich gegenseitig ausschließen müssen.
Ein Fremdschlüssel ist eine Einschränkung, die sicherstellt, dass ein Wert in einer Tabelle auf eine vorhandene Zeile in einer anderen Tabelle verweist. Er kann beispielsweise erzwingen, dass eine Kunden-ID in einer Bestellung auf einen tatsächlich vorhandenen Kunden zeigt. Das kann helfen, ungültige Referenzen zu reduzieren, bedeutet aber auch, dass Lösch- und Aktualisierungsregeln sowie die Tabellenstruktur sorgfältig im Voraus entworfen werden müssen. Wenn Sie später eine Partitionierung einführen möchten, müssen Sie auch die Kompatibilitätsbeschränkungen im Zusammenhang mit Fremdschlüsseln prüfen. dev.mysql.com dev.mysql.com
Welche Vorteile bietet MySQL für Entwicklungsumgebungen und die Zugriffskontrolle?
MySQL bietet mehrere Client-Protokolle und APIs für C/C++, Java, PHP, Python, Ruby und weitere Sprachen. Anwendungen, die diese Sprachen und Tools bereits nutzen, haben daher Optionen zum Aufbau einer Verbindungsschicht, und ein grundlegender Pfad zwischen einer Webanwendung und der Datenbank lässt sich relativ einfach einrichten. Das Vorhandensein einer API für eine bestimmte Sprache gewährleistet jedoch nicht automatisch, dass Connection Pooling, Fehlerwiederholungen, Zeichensätze und die Zeitzonenbehandlung korrekt konfiguriert sind. Der Datenzugriffsansatz der Anwendung muss separat validiert werden. dev.mysql.com
Auch das Berechtigungssystem ist Teil des Betriebsdesigns. MySQL bietet Berechtigungen auf globaler Ebene, Datenbankebene und Objektebene sowie dynamische Berechtigungen. Damit lassen sich Rollen trennen: Beispielsweise kann ein Anwendungskonto nur die erforderlichen Lese- und Schreibberechtigungen für bestimmte Tabellen erhalten, während für Sicherungs- und Verwaltungsaufgaben separate Konten verwendet werden. Das Prinzip der geringsten Rechte ist ein nützliches Gestaltungsprinzip, um die Auswirkungen zu begrenzen, falls ein Konto kompromittiert wird oder ein Programm einen Fehler enthält. dev.mysql.com
Eine feinere Granularität von Berechtigungen vervollständigt jedoch nicht von selbst die Sicherheit. In der Praxis müssen Sie verwalten, welche Konten welche Berechtigungen besitzen, ob Administrator- und Anwendungskonten getrennt sind und welcher Prozess Berechtigungsänderungen regelt. Mit anderen Worten: Die Berechtigungsfunktionen von MySQL stellen Kontrollmechanismen bereit, die Verantwortung für ihre Zuordnung zu Geschäftsrollen verbleibt jedoch beim Betrieb.
Welche Probleme lösen Indizes und Partitionierung?
Ein Index ist eine Datenstruktur, die den Bedarf verringern soll, eine gesamte Tabelle nach gewünschten Zeilen zu durchsuchen. Wenn beispielsweise Anfragen zum Auffinden einer einzelnen Bestellung anhand der Bestellnummer häufig sind, kann ein Index auf dieser Spalte helfen. Mehrspaltige Indizes können für Abfragen nützlich sein, die mehrere Spalten zusammen als Bedingungen verwenden, aber die Spaltenreihenfolge und die tatsächlichen Abfrageprädikate sind entscheidend. InnoDB unterstützt bis zu 64 Sekundärindizes pro Tabelle und bis zu 16 Spalten pro mehrspaltigem Index. dev.mysql.com
Indizes sind jedoch nicht automatisch besser, wenn mehr davon erstellt werden. Sie verbrauchen Speicherplatz und müssen auch bei eingefügten, aktualisierten oder gelöschten Zeilen gepflegt werden. Die Grenze für die Anzahl unterstützter Indizes ist eine technische Grenze, kein Designziel. Ob ein Index, der einen Suchpfad verkürzt, tatsächlich erforderlich ist und wie stark er Schreibpfade belastet, sollte anhand repräsentativer Abfragen und der Datenverteilung bewertet werden.
Auch Zeichenkettenindizes unterliegen physischen Einschränkungen. Das Präfixlimit für InnoDB-Indexschlüssel beträgt im Allgemeinen 3.072 Byte, kann jedoch abhängig vom Zeilenformat auf 767 Byte reduziert sein. Wenn Sie lange Zeichenketten mit einem Zeichensatz indexieren möchten, der pro Zeichen viel Speicher benötigt, etwa utf8mb4, kann dieses Limit das Schemadesign beeinflussen. Besonders wichtig ist die Unterscheidung, dass es sich um ein Byte-basiertes Limit und nicht um eine Begrenzung der Zeichenzahl handelt. dev.mysql.com
Partitionierung ist eine Funktion, die eine Tabelle nach festgelegten Regeln auf mehrere Partitionen verteilt speichert. Wenn eine Bedingung den Partitionierungsregeln entspricht, kann Partition Pruning Partitionen ausschließen, die MySQL nicht durchsuchen muss. Bei einer großen Verlaufstabelle, die nach Datumsbereichen abgefragt wird, können Sie beispielsweise bei einer Partitionierung nach Datum ein Design erwägen, das den Zielbereich für Suchen über einen bestimmten Zeitraum verringert. dev.mysql.com
Das bedeutet nicht, dass jede große Tabelle partitioniert werden sollte. Wenn häufig verwendete Bedingungen nicht zum Partitionsschlüssel passen, kann die erwartete Verringerung der Zieldaten ausbleiben. Die Partitionierung führt zudem zusätzliche Regeln für Betrieb, Schlüsseldesign und Einschränkungen ein. Es ist daher besser, zuerst zu vergleichen, ob sich das Problem mit einfacheren Indizes und Abfrageverbesserungen lösen lässt.
Welche Einschränkungen gelten für Partitionierung und Volltextsuche?
In MySQL 8.4 wird die Partitionierung von den Speicher-Engines InnoDB und NDB unterstützt. Eine partitionierte InnoDB-Tabelle darf keine Fremdschlüssel haben und darf auch nicht Ziel von Fremdschlüsselreferenzen aus einer anderen Tabelle sein. Außerdem muss jede im Partitionsschlüssel verwendete Spalte Teil jedes eindeutigen Schlüssels sein, einschließlich des Primärschlüssels. Diese Bedingung kann das Modell erheblich verändern, wenn Sie eine zentrale Tabelle mit vielen Referenzen, etwa eine Bestelltabelle, partitionieren möchten. dev.mysql.com
Die Volltextsuche ist eine Funktion zum Durchsuchen von Text nach Wörtern. MySQL unterstützt Volltextsuche mit InnoDB und MyISAM, jedoch nicht für partitionierte Tabellen. Wenn Sie daher für dieselbe Tabelle sowohl eine Suchfunktion für lange Dokumente als auch eine Partitionierung für umfangreiche Verlaufsdaten erwarten, sollten Sie frühzeitig prüfen, ob diese Kombination möglich ist. Das spätere Hinzufügen einer Funktion kann das Aufteilen von Tabellen oder eine Änderung der Sucharchitektur erfordern. dev.mysql.com
Diese Einschränkungen zeigen nicht einfach, dass MySQL Funktionen fehlen, sondern dass Funktionen möglicherweise nicht unabhängig voneinander kombinierbar sind. Sie können den Bedarf an Fremdschlüsseln, eindeutigen Schlüsseln, Partitionsschlüsseln und Volltextsuche einzeln prüfen. Es ist sicherer, ein Schema nicht anhand des Vorteils nur einer einzigen Funktion zu entscheiden.
Wie kann Replikation zur Skalierung von Lesezugriffen und für Backups verwendet werden?
Replikation ist eine Architektur, die Änderungen von einem Server an einen anderen sendet. Typischerweise zeichnet ein Quellserver Änderungen auf, und Replikatserver wenden sie an. Die Verteilung eines Teils der Leseanfragen auf mehrere Replikate kann die Leselast der Quelle verringern; außerdem können Sicherungs- oder Analyseaufgaben auf Replikate ausgelagert werden. dev.mysql.com
GTID ist eine Methode zur Behandlung von Replikationspositionen, bei der jeder Transaktion eine Kennung zugewiesen wird. GTID-basierte Replikation kann dazu beitragen, den Aufwand für das manuelle Abgleichen von Namen und Positionen binärer Logdateien zu verringern. Der Aufbau einer Replikationstopologie ist jedoch etwas anderes als die Überwachung des Replikationsverzugs und der Betrieb von Wiederherstellungsverfahren. Sie müssen festlegen, welcher Server Schreibvorgänge verarbeitet, welche Server Lesevorgänge bedienen dürfen und was bei Verzögerungen geschieht. dev.mysql.com
Die Standardreplikation ist asynchron. Das bedeutet, dass im Augenblick, in dem ein Commit auf der Quelle abgeschlossen wird, nicht garantiert ist, dass jedes Replikat dieselbe Änderung bereits angewendet hat. Eine Abfrage, die unmittelbar nach einer Adressänderung eines Benutzers an ein Replikat geleitet wird, kann beispielsweise noch die vorherige Adresse anzeigen. Dies kann als Read-after-Write-Konsistenzproblem betrachtet werden. Anfragen, die die neuesten Daten benötigen, erfordern eine Richtlinie, die sie an die Quelle leitet oder den Anwendungsstatus der Replikate berücksichtigt. dev.mysql.com
Semisynchrone Replikation verwendet einen Ansatz, bei dem die Quelle eine Bestätigung erhält, dass ein Replikat ein Transaktionsereignis empfangen und protokolliert hat. Dies ist eine Alternative zur standardmäßigen asynchronen Replikation, bedeutet jedoch nicht, dass jede Anforderung vollständig synchron wird. Bei Anforderungen an starke Synchronität sollten Sie die erforderliche Konsistenzstufe, den akzeptablen Latenzbereich und das Ausfallverhalten klar definieren und auch separate Optionen wie NDB Cluster berücksichtigen. dev.mysql.com
Löst Group Replication die Hochverfügbarkeit automatisch?
Hochverfügbarkeit ist das Ziel, ein System so zu konfigurieren, dass ein Dienst weiterlaufen kann, wenn ein Teil eines Servers oder Netzwerks ausfällt. Group Replication verwaltet Gruppenmitgliedschaften, wählt im Single-Primary-Modus automatisch einen Primärknoten oder unterstützt Multi-Primary-Konfigurationen. Die Fähigkeit, in Kombination mit InnoDB Cluster und MySQL Router eine Hochverfügbarkeitstopologie zu bilden, ist eine wichtige MySQL-Option. dev.mysql.com
Konsens zwischen Datenbankservern und das Failover von Anwendungsverbindungen sind jedoch nicht dasselbe Problem. Group Replication enthält keine Funktion, die ausgefallene Clients auf funktionsfähige Mitglieder umschaltet. Anwendungen benötigen MySQL Router, einen Load Balancer, einen Connector oder benutzerdefinierte Middleware, um zu bestimmen, wohin Verbindungen hergestellt werden; auch diese Schicht muss unter Berücksichtigung von Ausfällen, Wiederholungen und Statusaktualisierungen betrieben werden. dev.mysql.com
Wenn Sie daher „automatisches Failover“ hören, stellen Sie mindestens drei getrennte Fragen. Erstens: Kann ein Primärknoten gewählt werden? Zweitens: Werden neue Anwendungsverbindungen zu einem funktionsfähigen Server geleitet? Drittens: Welche Ergebnisse sehen laufende Anfragen und vom Benutzer wiederholte Anfragen? Das Vorhandensein einer Funktion für die erste Frage garantiert die anderen beiden nicht automatisch.
Auch eine Multi-Primary-Konfiguration lässt sich nicht einfach als Schalter zur Steigerung der Schreibleistung verstehen. Wenn Schreibvorgänge von mehreren Orten erlaubt sind, müssen Sie auf Geschäftsebene entwerfen, wie gleichzeitige Änderungen an denselben Daten vermieden oder behandelt werden, und welche Regeln der Schreibpfad der Anwendung einhalten muss. Hochverfügbarkeit ist ein Betriebsaspekt, der neben der Auswahl von Funktionen auch Ausfallübungen, Beobachtbarkeit und Wiederherstellungsverfahren umfasst.
Warum können komplexe Abfragen den Tuning-Aufwand erhöhen?
Der Optimizer ist eine Komponente, die unter mehreren Ausführungswegen für eine SQL-Anweisung den Plan auswählt, dessen Kosten am niedrigsten geschätzt werden. Er bestimmt beispielsweise, welcher Index zuerst verwendet wird und in welcher Reihenfolge Tabellen verknüpft werden. Der kostenbasierte Optimizer von MySQL kann sich bei unzureichenden Statistiken auf Schätzungen stützen und daher einen Plan wählen, der von den Erwartungen einer Person abweicht. dev.mysql.com
Mit zunehmender Zahl verknüpfter Tabellen kann die Zahl möglicher Ausführungspläne exponentiell wachsen. Dann können nicht nur der Datenabruf selbst, sondern auch die Optimierungszeit zur Suche nach geeigneten Plänen zum Engpass werden. In Systemen, die häufig komplexe analytische Abfragen oder viele Joins ausführen, lässt sich die Eignung daher nicht allein daran beurteilen, ob SQL syntaktisch ausgeführt werden kann. Tests sollten tatsächliche Datenverteilungen und repräsentative Bedingungen verwenden. dev.mysql.com
EXPLAIN ist ein Werkzeug zur Prüfung des für eine Abfrage gewählten Ausführungsplans. Bei langsamen Ergebnissen sollten Sie zuerst Prädikate, Join-Bedingungen, die verwendeten Indizes und geschätzte Zeilenzahlen prüfen. Bei Bedarf können Sie Statistiken aktualisieren oder Indizes und Abfragestruktur anpassen. Index-Hinweise und Funktionen zur Optimizer-Steuerung sind ebenfalls verfügbar, aber Ansätze, die einen bestimmten Plan erzwingen, müssen fortlaufend darauf geprüft werden, ob sie nach Datenänderungen weiterhin gültig sind. dev.mysql.com dev.mysql.com
Das bedeutet nicht, dass komplexe Analysen nicht in MySQL durchgeführt werden können. Wenn jedoch umfangreiche Multi-Table-Joins und analytische Abfragen die Kernarbeitslast bilden, ist es realistisch, im Voraus zu vergleichen, wie viel Zeit Sie für Tuning aufwenden können, ob Analysen auf Replikate ausgelagert werden sollten und ob ein dediziertes Analysesystem ergänzt werden sollte. Umgekehrt kann dieser Aufwand für einen Dienst, der hauptsächlich aus kurzen, vorhersehbaren Transaktionen besteht, relativ geringer sein.
Wann sollten Sie bei Stored Routines vorsichtig sein?
Stored Routines sind Prozeduren oder Funktionen, die auf dem Datenbankserver gespeichert und ausgeführt werden. Sie können einige Datenverarbeitungsregeln nahe an der Datenbank halten, aber gespeicherte Funktionen, die in SQL-Anweisungen verwendet werden können, unterliegen Einschränkungen. Beispielsweise darf eine gespeicherte Funktion keine Anweisung verwenden, die eine Ergebnismenge zurückgibt. Eine Funktion, die einen einzelnen Rückgabewert berechnet, und ein Abfragevorgang, der mehrere Zeilen zurückgibt, haben unterschiedliche Zwecke und Verwendungsmuster. dev.mysql.com dev.mysql.com
Auch die Determiniertheit von Stored Routines ist in Replikationsumgebungen wichtig. Deterministisch bedeutet, bei gleicher Eingabe dasselbe Ergebnis zu erzeugen. Nichtdeterministische oder zeitabhängige Routinen, die je nach Zeit oder Umgebungsstatus variieren, können abhängig von der Replikationsmethode Probleme bei der Reproduzierbarkeit verursachen und erfordern bei der anweisungsbasierten Replikation besondere Vorsicht. Wenn Geschäftslogik in der Datenbank platziert wird, sollten Sie auch prüfen, ob diese Logik bei Replikation und Wiederherstellung nach Abstürzen dasselbe Ergebnis erzeugen kann. dev.mysql.com
Die Entscheidung für oder gegen Stored Routines betrifft weniger die Frage, ob eine Funktion existiert, als die Frage, wo die Verantwortung für Änderungen, Tests und Bereitstellung liegen soll. Wenn Regeln zwischen Anwendungscode und Datenbankroutinen aufgeteilt werden, können Nachverfolgung und Tests komplexer werden. Umgekehrt können sie für einfache Regeln nahe an der Datenintegrität nützlich sein. Die zentrale Frage ist, ob das Team nachvollziehen und verwalten kann, wo diese Regeln ausgeführt werden und welche Auswirkungen sie auf die Replikation haben.
Wann passt MySQL gut, und wann sollten Sie vorsichtig sein?
Die folgende Tabelle ist keine Rangliste von Produkten. Sie bietet eine Perspektive, um die Übereinstimmung zwischen Anforderungen und Funktionen zu prüfen.
| Situation | Was Sie mit MySQL erwägen können | Zusätzlich zu prüfende Bedingungen |
|---|---|---|
| Allgemeine Webdienste sowie Bestell- oder Mitgliederverwaltung | Sie können InnoDB-Transaktionen, Sperren auf Zeilenebene, MVCC und Fremdschlüssel verwenden. | Transaktionsgrenzen und Regeln für gleichzeitige Aktualisierungen müssen entworfen werden. |
| Leselastige Dienste | Source-Replica-Replikation kann Lese-, Sicherungs- und Analyselasten trennen. | Sie benötigen Richtlinien für Replikationsverzug und aktuelle Lesevorgänge. |
| Dienste mit Bedarf an einer fehlertoleranten Konfiguration | Sie können eine Topologie aus Group Replication, Router und zugehörigen Komponenten erwägen. | Verbindungs-Failover, Wiederholungen und Ausfallverfahren müssen separat betrieben werden. |
| Große Verlaufsabfragen nach Datumsbereich | Partition Pruning kann je nach Bedingung die Zielpartitionen verringern. | Prüfen Sie zuerst Einschränkungen für Fremdschlüssel, eindeutige Schlüssel und Volltextsuche. |
| Analyseorientierte Arbeitslasten mit vielen Tabellen-Joins | Sie können SQL-Ausführung sowie Funktionen zur Index- und Optimizer-Steuerung verwenden. | Bewerten Sie die Validierung von Ausführungsplänen und die Kosten fortlaufenden Tunings. |
Die ersten drei Zeilen der Tabelle basieren auf den offiziellen Funktionen von InnoDB, Replikation und Group Replication. Die letzten zwei Zeilen berücksichtigen ebenfalls das Verhalten und die Einschränkungen von Partitionierung und Optimizer. dev.mysql.com dev.mysql.com dev.mysql.com dev.mysql.com dev.mysql.com
Insbesondere wenn starke Konsistenz über mehrere Regionen hinweg oder unterbrechungsfreies Failover eine Kernanforderung ist, sollten Sie keine Entscheidung allein auf Grundlage der standardmäßigen asynchronen Replikation treffen. Legen Sie Anforderungen an Aktualität, akzeptable Latenz, die Möglichkeit von Schreibvorgängen bei Ausfällen und den Failover-Pfad der Anwendung fest und vergleichen Sie dann Group Replication, NDB Cluster oder andere verteilte Optionen. Wenn Sie dagegen typische Lese-Schreib-Transaktionen innerhalb eines einzelnen Dienstbereichs zuverlässig verarbeiten und Lesevorgänge bei Bedarf auf Replikate verteilen möchten, kann die Funktionskombination von MySQL ein praxisnaher Ausgangspunkt sein. dev.mysql.com dev.mysql.com
Was sollten Sie vor der Einführung prüfen?
Prüfen Sie zunächst, ob Kern-Tabellen InnoDB verwenden und ob Transaktionsgrenzen zu Geschäftseinheiten passen. Änderungen, die gemeinsam erfolgreich sein oder fehlschlagen müssen, etwa das Anlegen einer Bestellung, sollten als eine Transaktion definiert werden. Vermeiden Sie dabei unnötig lange Transaktionen, die die Sperrdauer erhöhen. Listen Sie zweitens die häufigsten Lese- und Schreibabfragen auf und prüfen Sie, ob die erforderlichen Indizes den tatsächlichen Prädikaten und der Sortiermethode entsprechen. dev.mysql.com dev.mysql.com
Drittens sollten Sie bei Verwendung von Replikation entscheiden, „welche Lesevorgänge von Replikaten erlaubt sind“. Ein Ansatz besteht darin, Anfragen zu unterscheiden, die Aktualität erfordern, etwa die Prüfung eines Status unmittelbar nach einer Zahlung, und Listen- sowie Statistikabfragen, die eine gewisse Verzögerung tolerieren können. Viertens: Wenn eine Hochverfügbarkeitskonfiguration erforderlich ist, testen Sie Ausfallszenarien nicht nur für die Wahl von Datenbankmitgliedern, sondern auch dafür, wohin Anwendungsverbindungen tatsächlich wechseln. dev.mysql.com dev.mysql.com
Fünftens sollten Sie von wachsendem Datenvolumen ausgehen und prüfen, ob Partitionierung wirklich erforderlich ist und ob Sie Einschränkungen bei Fremdschlüsseln und eindeutigen Schlüsseln akzeptieren können. Wenn Sie gleichzeitig Suche in langen Zeichenketten, Volltextsuche und Partitionierung benötigen, prüfen Sie zuerst die Einschränkungen zwischen den Funktionen. Wenn komplexe Joins zentral sind, untersuchen Sie schließlich EXPLAIN unter Bedingungen, die Produktionsdaten nahekommen, und bewerten Sie, ob Sie die Kapazität haben, Statistiken und Indexänderungen kontinuierlich zu verwalten. dev.mysql.com dev.mysql.com dev.mysql.com
Fazit: Wie sollten Sie die Vor- und Nachteile von MySQL bewerten?
Zu den Stärken von MySQL gehören InnoDB-basierte Transaktions- und Parallelitätskontrolle, die Integration in ein breites Spektrum von Entwicklungsumgebungen, die Leseverteilung durch Replikation und offizielle Funktionen zum Aufbau von Hochverfügbarkeitskonfigurationen. Diese können eine bedeutende Grundlage für allgemeine Webdienste und typische OLTP-Arbeitslasten bieten. dev.mysql.com dev.mysql.com dev.mysql.com
Gleichzeitig müssen der mögliche Verzug der Standardreplikation, zusätzliches Design für das Failover von Verbindungen in Hochverfügbarkeitsumgebungen, die Validierung von Ausführungsplänen bei komplexen Abfragen sowie Einschränkungen bei Indizes, Partitionierung und Volltextsuche als reale Kosten berücksichtigt werden. Letztlich ist MySQL keine Wahl mit universell positiven Eigenschaften. Es ist eine Datenbank, deren Eignung bewertet werden kann, wenn Anforderungen an Datenkonsistenz, das Lese-Schreib-Verhältnis, Schemabeschränkungen, das Niveau der Ausfallreaktion sowie Tuning- und Betriebskapazitäten konkret festgelegt werden. dev.mysql.com dev.mysql.com dev.mysql.com