MySQL oder MariaDB: was heute wirklich unterschiedlich ist
Der gemeinsame Ursprung führt in die Irre. Nach über fünfzehn Jahren getrennter Entwicklung entscheidet vor allem, was deine Anwendung und deine Distribution voraussetzen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Name suggeriert eine Austauschbarkeit, die es nicht mehr gibt
In vielen Projekten steht MariaDB dort, wo jemand mysql-server installieren wollte, weil die Distribution es so vorgesehen hat. Solange die Anwendung einfache Tabellen anlegt und Abfragen stellt, fällt das nie auf. Auffällig wird es an den Rändern: bei einer Kollation, die es nur in einem der beiden gibt, bei einer JSON-Spalte mit Index, bei einem Werkzeug, das die Replikationskennung ausliest.
Der teure Fall ist der ungeplante Wechsel unter Zeitdruck. Ein Umzug von MySQL 8 auf MariaDB lässt sich nicht dadurch erledigen, dass man das Datenverzeichnis mitnimmt, weil MySQL seinen Katalog seit Version 8 transaktional in InnoDB führt und MariaDB weiterhin mit eigenen Beschreibungsdateien arbeitet. Nötig ist ein logischer Export und ein Import, und der dauert bei großen Beständen so lange, wie er dauert.
Hinzu kommt eine Erwartung, die selten ausgesprochen wird: dass Replikation zwischen beiden funktioniert, etwa als sanfter Übergang. Das tut sie nicht verlässlich, weil die Formate der globalen Transaktionskennungen unterschiedlich aufgebaut sind. Wer damit plant, plant mit einem Umschaltfenster, das es nicht gibt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der direkte Vergleich
MySQL
das Original bei Oracle, LTS-Reihen im Zweijahresabstand, aktuell 9.7
MariaDB
der Ableger von 2009 unter der MariaDB Foundation, jährlich eine LTS-Reihe, aktuell 12.3
| Entscheidungsfrage | MySQL | MariaDB |
|---|---|---|
| Wie gut passt es zu einer Anwendung, die gegen MySQL 8 entwickelt wurde? | Stärke Die Anwendung läuft ohne Anpassung, einschließlich Voreinstellung der Kollation, JSON-Typ und mehrwertiger Indizes. | Schwäche Der Kern funktioniert, aber Kollationen mit 0900 im Namen, mehrwertige Indizes über JSON-Arrays und die Kopierfunktion CLONE fehlen. Schwerer wiegt, dass ein Hersteller, der ausdrücklich MySQL 8 oder höher voraussetzt, den Betrieb auf MariaDB in aller Regel nicht unterstützt, unabhängig davon, ob die Anwendung technisch läuft. |
| Was bekommst du ohne kostenpflichtige Zusatzlizenz? | Kommt darauf an Die Community-Ausgabe deckt den Betrieb ab, Thread-Pool und Audit-Protokollierung gehören aber zur Enterprise-Ausgabe. | Stärke Thread-Pool und Audit-Plugin sind Bestandteil der frei verfügbaren Ausgabe, ebenso die Cluster-Erweiterung Galera. |
| Wie stabil bleiben Skripte und Monitoring über einen Versionswechsel? | Schwäche Mit 8.4 sind CHANGE MASTER TO, SHOW SLAVE STATUS, mysql_upgrade und mysqlpump verschwunden. Jedes Skript, das sie nutzt, bricht beim Upgrade. | Stärke Die alte Schreibweise funktioniert weiter, die neue steht als Alias daneben. Bestehende Wartungsskripte überstehen den Versionswechsel meist unverändert. |
| Wie gut lässt sich JSON speichern und indizieren? | Stärke Ein eigener Binärtyp mit direktem Zugriff auf einzelne Pfade und mehrwertige Indizes, die Werte aus einem Array indizieren. | Kommt darauf an JSON ist ein Textfeld mit einer Prüfregel auf Gültigkeit. Die Funktionen zum Auswerten gibt es, ein Index entsteht nur über eine generierte Spalte. |
| Wie lange bekommst du für eine gewählte Version Korrekturen? | Stärke Eine LTS-Reihe wird fünf Jahre im Premier-Support gepflegt, danach folgen drei Jahre erweiterter Support. Der Abstand zwischen LTS-Reihen beträgt rund zwei Jahre. | Kommt darauf an Eine LTS-Reihe wird drei Jahre gepflegt, dafür erscheint jährlich eine neue. Wer selten aktualisiert, kommt mit dem kürzeren Zyklus schlechter zurecht. |
| Woher kommt das Paket auf einem typischen Linux-Server? | Kommt darauf an Unter Debian liegt MySQL nicht in den Standardquellen, das Paket kommt aus dem Repository des Herstellers und muss eigens eingebunden und gepflegt werden. | Stärke MariaDB ist in den Paketquellen der verbreiteten Distributionen enthalten und wird über die normalen Systemaktualisierungen versorgt. |
Wie gut passt es zu einer Anwendung, die gegen MySQL 8 entwickelt wurde?
Die Anwendung läuft ohne Anpassung, einschließlich Voreinstellung der Kollation, JSON-Typ und mehrwertiger Indizes.
Der Kern funktioniert, aber Kollationen mit 0900 im Namen, mehrwertige Indizes über JSON-Arrays und die Kopierfunktion CLONE fehlen. Schwerer wiegt, dass ein Hersteller, der ausdrücklich MySQL 8 oder höher voraussetzt, den Betrieb auf MariaDB in aller Regel nicht unterstützt, unabhängig davon, ob die Anwendung technisch läuft.
Was bekommst du ohne kostenpflichtige Zusatzlizenz?
Die Community-Ausgabe deckt den Betrieb ab, Thread-Pool und Audit-Protokollierung gehören aber zur Enterprise-Ausgabe.
Thread-Pool und Audit-Plugin sind Bestandteil der frei verfügbaren Ausgabe, ebenso die Cluster-Erweiterung Galera.
Wie stabil bleiben Skripte und Monitoring über einen Versionswechsel?
Mit 8.4 sind CHANGE MASTER TO, SHOW SLAVE STATUS, mysql_upgrade und mysqlpump verschwunden. Jedes Skript, das sie nutzt, bricht beim Upgrade.
Die alte Schreibweise funktioniert weiter, die neue steht als Alias daneben. Bestehende Wartungsskripte überstehen den Versionswechsel meist unverändert.
Wie gut lässt sich JSON speichern und indizieren?
Ein eigener Binärtyp mit direktem Zugriff auf einzelne Pfade und mehrwertige Indizes, die Werte aus einem Array indizieren.
JSON ist ein Textfeld mit einer Prüfregel auf Gültigkeit. Die Funktionen zum Auswerten gibt es, ein Index entsteht nur über eine generierte Spalte.
Wie lange bekommst du für eine gewählte Version Korrekturen?
Eine LTS-Reihe wird fünf Jahre im Premier-Support gepflegt, danach folgen drei Jahre erweiterter Support. Der Abstand zwischen LTS-Reihen beträgt rund zwei Jahre.
Eine LTS-Reihe wird drei Jahre gepflegt, dafür erscheint jährlich eine neue. Wer selten aktualisiert, kommt mit dem kürzeren Zyklus schlechter zurecht.
Woher kommt das Paket auf einem typischen Linux-Server?
Unter Debian liegt MySQL nicht in den Standardquellen, das Paket kommt aus dem Repository des Herstellers und muss eigens eingebunden und gepflegt werden.
MariaDB ist in den Paketquellen der verbreiteten Distributionen enthalten und wird über die normalen Systemaktualisierungen versorgt.
Was passt wann
- Wenn eine gekaufte Anwendung ausdrücklich MySQL 8 voraussetzt
- bleib bei MySQL, denn Kollationen und JSON-Indizes nachzubauen kostet mehr als die Paketquelle.
- Wenn du eine eigene Anwendung betreibst und aus den Distributionsquellen versorgt werden willst
- nimm MariaDB und halte dich an die jährlichen LTS-Reihen.
- Wenn Systemversionierung, Spaltenspeicher oder Galera im Betriebskonzept stehen
- entscheidet das für MariaDB, weil es diese Bausteine mitbringt statt sie zuzukaufen.
Fünf Stellen, an denen der Unterschied im Betrieb auftaucht
- 01 Der Datenkatalog liegt bei MySQL 8 in InnoDB, bei MariaDB in eigenen Dateien.
- 02 Die Kollationen mit 0900 im Namen gibt es ausschließlich in MySQL.
- 03 JSON ist einmal ein Binärtyp und einmal Text mit einer Prüfregel.
- 04 Die Kennungen für Replikation sind zwischen beiden Systemen unlesbar.
- 05 MySQL 8.4 hat die alte Befehlsschreibweise entfernt, MariaDB nicht.
Danach entscheidest du anhand der Anwendung, nicht anhand des Namens
Für eine Entscheidung reichen fünf Fragen: Gegen welches System wurde die Anwendung entwickelt, woher kommen die Pakete, welche Hochverfügbarkeit ist vorgesehen, wie lange soll die gewählte Version unterstützt werden, und wie viel Aufwand darf ein späterer Wechsel kosten.
Die Speicherstruktur als harte Grenze lesen
MySQL 8 führt den Datenkatalog transaktional in InnoDB, MariaDB nutzt weiterhin eigene Beschreibungsdateien. Damit ist ein Wechsel durch Austausch der Binärdateien ausgeschlossen, es geht nur über Export und Import.
Kollationen und Zeichensätze prüfen
Die Kollationen mit dem Namensbestandteil 0900, darunter die Voreinstellung von MySQL 8, gibt es in MariaDB nicht. Ein Dump aus MySQL 8 lässt sich deshalb nicht ohne Anpassung der Spaltendefinitionen einlesen.
JSON nicht als dasselbe behandeln
MySQL speichert JSON in einem eigenen Binärformat und kann Werte aus Arrays über mehrwertige Indizes direkt indizieren. In MariaDB ist JSON ein Textfeld mit Prüfregel, Indizes entstehen dort über generierte Spalten.
Werkzeuge und Skripte gegen Versionswechsel absichern
MySQL 8.4 hat die alte Befehlsschreibweise entfernt, CHANGE MASTER TO und SHOW SLAVE STATUS gibt es nicht mehr. MariaDB akzeptiert beide Schreibweisen. Monitoring und Wartungsskripte sind davon direkt betroffen.
Supportzeiträume gegeneinanderhalten
Oracle liefert für eine LTS-Reihe fünf Jahre Premier-Support und drei Jahre darüber hinaus, dafür erscheint sie nur etwa alle zwei Jahre. MariaDB veröffentlicht jährlich eine LTS-Reihe und pflegt sie drei Jahre.
Den Weg zurück mitplanen
Von MySQL nach MariaDB führt ein logischer Export. Zurück wird es schwierig, sobald Systemversionierung, Sequenzobjekte oder MariaDB-eigene Speicher-Engines im Schema stecken, denn dafür gibt es in MySQL keine Entsprechung.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Woher die Unterschiede kommen
MariaDB entstand 2009, nachdem MySQL über die Übernahme von Sun bei Oracle gelandet war. Bis MariaDB 5.5 war der Ableger ein direkter Ersatz, gleiche Versionsnummern, gleiches Datenformat, austauschbare Binärdateien. Mit MariaDB 10.0 endete diese Gleichung, weil beide Seiten anfingen, dieselben Aufgaben unterschiedlich zu lösen.
Die tiefste Trennung kam mit MySQL 8.0. Dort wanderte der Datenkatalog in transaktionale Tabellen innerhalb von InnoDB, die alten Beschreibungsdateien je Tabelle sind verschwunden. MariaDB hat diesen Schritt nicht mitgemacht. Damit lassen sich Datenverzeichnisse nicht mehr gegenseitig lesen, und jeder Wechsel läuft zwingend über einen logischen Export.
Auch die Speicher-Engine ist nicht mehr dieselbe. MariaDB pflegt einen eigenen Zweig von InnoDB und übernimmt Änderungen aus Oracles Fassung nicht automatisch. Das erklärt, warum Optimierungen und Fehlerkorrekturen auf einer Seite auftauchen und auf der anderen nicht, und warum Messwerte aus einem Blogbeitrag über das eine System über das andere wenig aussagen.
Wo der Unterschied im Alltag auffällt
Bei Zeichensätzen. MySQL 8 verwendet standardmäßig eine Kollation, deren Name mit utf8mb4_0900 beginnt und die auf einer bestimmten Unicode-Fassung beruht. Diese Kollationsfamilie gibt es in MariaDB nicht. Ein Dump aus MySQL scheitert dort beim Einlesen an genau dieser Stelle. Die Reparatur besteht darin, im Dump alle Kollationsangaben zu ersetzen, seit MariaDB 10.10 am ehesten durch die uca1400-Familie. Damit sortiert die Datenbank anschließend anders als vorher, und das fällt bei ORDER BY und bei Vergleichen mit Groß- und Kleinschreibung auf, nicht beim Import.
Bei der Authentifizierung. MySQL 8 verwendet standardmäßig caching_sha2_password, ältere Clients kennen nur mysql_native_password, und seit MySQL 8.4 ist das alte Verfahren nicht mehr voreingestellt aktiv. MariaDB setzt weiterhin auf mysql_native_password und bietet ergänzend ed25519 an. Wer beide Systeme im Haus hat, braucht Treiber, die mit beidem umgehen.
Bei Replikation und Werkzeugen. Die globalen Transaktionskennungen sind unterschiedlich aufgebaut, eine Replikation zwischen beiden Systemen ist deshalb kein vorgesehener Weg. Dazu kommt die Sprache selbst: MySQL 8.4 hat CHANGE MASTER TO, SHOW SLAVE STATUS, START SLAVE und die zugehörigen Statusvariablen entfernt. MariaDB versteht die alten und die neuen Formen. Für ein selbstgebautes Monitoring ist das der Unterschied zwischen einem Versionswechsel und einem Umbau.
Was jedes System exklusiv mitbringt
MariaDB liefert Bausteine mit, für die es in MySQL keine Entsprechung gibt: systemversionierte Tabellen, die den Verlauf jeder Zeile mitführen und Abfragen zu einem vergangenen Zeitpunkt erlauben, echte Sequenzobjekte statt AUTO_INCREMENT, die Speicher-Engines ColumnStore für spaltenweise Auswertungen und Spider für verteilte Tabellen, dazu die Cluster-Erweiterung Galera direkt im Server. Auch RETURNING bei INSERT und DELETE ist eine MariaDB-Eigenheit.
MySQL hält dagegen mit einem Betriebspaket, das aufeinander abgestimmt ist: Group Replication mit InnoDB Cluster, dem Router davor und der MySQL Shell zur Verwaltung, dazu die CLONE-Anweisung, mit der sich eine vollständige Instanz für einen neuen Knoten direkt kopieren lässt. Dazu kommen die mehrwertigen Indizes über JSON-Arrays und das X-Protokoll für den dokumentorientierten Zugriff.
Für die Entscheidung heißt das: Wenn eine dieser Funktionen im Betriebskonzept steht, ist die Wahl damit getroffen. Wenn keine davon vorkommt, und das ist der häufigere Fall, entscheidet die Paketquelle, der gewünschte Supportzeitraum und die Frage, gegen welches System die Anwendung getestet wurde.
Wie ein Wechsel tatsächlich abläuft
Von MySQL nach MariaDB führt der Weg über einen logischen Export mit mysqldump, eine Durchsicht des Dumps auf Kollationen, JSON-Spalten und Definitionen, die die Zielseite nicht kennt, und anschließend den Import. Plan für den Import deutlich mehr Zeit ein als für den Export, weil Indizes neu gebaut werden. Danach gehören die Benutzerkonten geprüft, weil das Authentifizierungsverfahren nicht übernommen wird und Passwörter neu gesetzt werden müssen.
In die andere Richtung ist der Aufwand größer, aber nicht wegen des Datenvolumens. Systemversionierte Tabellen, Sequenzobjekte, Tabellen in ColumnStore oder Spider und die MariaDB-eigenen Kollationen haben in MySQL keine Entsprechung. Sie müssen im Schema und in der Anwendung ersetzt werden, bevor überhaupt Daten bewegt werden.
In beiden Richtungen lohnt sich derselbe Zwischenschritt: den Import zuerst auf eine Kopie fahren, die Anwendung dagegen laufen lassen und die Abfrageprotokolle vergleichen. Unterschiede zeigen sich fast nie beim Einlesen, sondern später bei Sortierungen, bei Vergleichen mit Groß- und Kleinschreibung und bei Abfragen über JSON-Felder.
Dazu passende Kurse
Wer den Server selbst betreibt, merkt die Unterschiede zuerst bei Sicherung und Replikation, und genau dort setzen die MariaDB-Schulungen für Administratoren an.
Für die Gegenseite, etwa wenn eine gekaufte Anwendung MySQL 8 voraussetzt, ist das Kursangebot rund um MySQL der passende Einstieg.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Ist MariaDB noch ein direkter Ersatz für MySQL?
Kann ich zwischen MySQL und MariaDB replizieren, um sanft umzustellen?
Welches System ist schneller?
Was bedeutet es, dass Debian MariaDB ausliefert?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Zwei Systeme, die man auseinanderhalten können sollte
Wie sich Betrieb, Replikation und Sicherung im jeweiligen System tatsächlich anfühlen, siehst du bei cmt an einer laufenden Installation statt an einer Merkmalsliste.