MySQL und MariaDB begründet vergleichen
Voraussetzungen und Lernziele
Du kannst Tabellen und einfache SQL-Abfragen lesen. Nach dieser Lektion kannst du die historische Beziehung von MySQL und MariaDB erklären, eine versionsbezogene Kompatibilitätsprüfung planen und einen belastbaren Migrationsversuch von einer unbelegten Produktempfehlung unterscheiden. Aufwand: 120 Minuten: 35 Minuten Theorie, 55 Minuten Vergleichsmatrix und 30 Minuten Transfer.
Verwandte Systeme sind keine identischen Systeme
MariaDB ging aus der MySQL-Entwicklung hervor und wurde ursprünglich als kompatible Alternative angelegt. Heute werden beide Datenbanksysteme unabhängig weiterentwickelt. Viele grundlegende SQL-Abfragen und zahlreiche Anwendungsprotokolle ähneln sich weiterhin. Daraus folgt keine pauschale Austauschbarkeit aktueller Versionen.
Die sinnvolle Frage lautet deshalb nicht «Ist MariaDB mit MySQL kompatibel?», sondern beispielsweise: «Kann diese Anwendung mit diesem Schema, diesen Abfragen und diesem Treiber von MySQL 8.0.36 auf MariaDB 11.4.1 migriert werden?» Das sind bewusst konkrete Vergleichsversionen aus einer offiziellen Kompatibilitätsübersicht, keine Empfehlung, gerade diese älteren Punktversionen neu zu installieren.
Ein Produktname ist kein ausreichender Versuchsaufbau. Ergänze immer Version, Betriebssystem, Treiber, Speicherengine, Zeichensatz, Kollation und relevante Konfiguration. Sonst ist ein Bericht kaum reproduzierbar.
Vier Ebenen der Kompatibilität
Verbindung: Kann der Treiber den Server erreichen und mit dem eingerichteten Authentifizierungsverfahren arbeiten? Ein erfolgreicher Verbindungsaufbau beweist noch nicht, dass das Schema importierbar ist.
Schema und Daten: Sind Datentypen, Constraints, Zeichensätze, Kollationen, generierte Spalten und verwendete Funktionen mit denselben Bedeutungen verfügbar? Ein importierbarer SQL-Dump beweist noch nicht, dass alle Daten fachlich gleich interpretiert werden.
Abfragen und Transaktionen: Liefern JOINs, Gruppierungen und Vergleichsoperationen die erwarteten Ergebnisse? Entsprechen Sperrverhalten und Fehlerbehandlung den Annahmen der Anwendung? Eine schnell ausgeführte Startseite prüft noch keine konkurrierende Änderung.
Betrieb und Werkzeuge: Funktionieren Backup, Wiederherstellung, Monitoring, Benutzerrechte, Replikation und geplante Wartung? Ein einzelner SELECT ist kein Nachweis für die Wiederherstellbarkeit des Gesamtsystems.
Ein konkretes Beispiel: JSON
Eine Anwendung speichert zusätzliche Merkmale als JSON. Bei MySQL und MariaDB darf die gleiche Typbezeichnung nicht mit identischer interner Speicherung verwechselt werden. Die offizielle Vergleichsdokumentation beschreibt Unterschiede zwischen MySQLs JSON-Typ und MariaDBs JSON-Kompatibilitätsdarstellung. Für eine Migration prüfst du deshalb nicht nur, ob ein Wert eingefügt werden kann, sondern auch Validierung, Rückgabewerte der verwendeten JSON-Funktionen, Vergleichsverhalten und die tatsächlich verwendete Indexstrategie.
Die Lektion verlangt nicht, alle Unterschiede auswendig zu lernen. Du sollst aus dem konkreten Funktionsbedarf der Anwendung eine überprüfbare Liste ableiten. Auch die dokumentierte Vergleichsseite nennt ihre zugrunde liegenden Punktversionen; spätere Versionen musst du erneut prüfen.
Werkzeuge gezielt auswählen
Verwende zu den gewählten Serverversionen passende Verwaltungs- und Sicherungswerkzeuge. Ein logischer Dump ist eine Darstellung von Schema und Daten als Anweisungen, kein Beweis, dass jedes andere Produkt diese Anweisungen unverändert versteht. Ein physisches Backup enthält wiederum serverabhängige Datenstrukturen und ist nicht als allgemeines Austauschformat zu behandeln.
Ein sorgfältiger Migrationsversuch arbeitet auf einer separaten Zielumgebung. Er enthält ein geprüftes Quellbackup, einen dokumentierten Export und Import, Vergleich von Zeilenanzahlen und fachlichen Prüfsummen, Anwendungstests sowie eine geplante Rückkehr zum Quellsystem. Während eines echten Wechsels muss ausserdem geklärt werden, was mit neuen Schreibzugriffen geschieht. Einfach beide Datenbanken gleichzeitig beschreiben zu lassen erzeugt noch keine zuverlässige Synchronisation.
Warum «schneller» ohne Versuchsaufbau wenig sagt
Die Laufzeit hängt unter anderem von Abfrage, Datenverteilung, Indizes, Cachezustand, Hardware, Nebenlast und Konfiguration ab. Ein Produkt kann bei einer bestimmten Aufgabe schneller sein und bei einer anderen langsamer. Eine pauschale Aussage wie «MariaDB ist immer schneller» ist deshalb kein begründeter Systemvergleich.
Miss dieselbe fachliche Aufgabe mit festgehaltenen Bedingungen mehrfach. Berichte Streuung und Ausreisser, nicht nur den besten Durchlauf. Untersuche zuerst, ob beide Abfragen überhaupt gleichwertige Ergebnisse liefern. Ein fehlerhaftes Ergebnis bleibt unbrauchbar, auch wenn es schnell entsteht.
Verständnisfragen mit Erklärung
Beweist ein erfolgreicher Login die Migrationsfähigkeit? Nein. Er bestätigt höchstens einen Teil des Verbindungswegs. Schema, Datenbedeutung und Anwendungstransaktionen sind noch ungeprüft.
Warum reicht die Versionsangabe «8» nicht? Fehlerkorrekturen und Funktionsänderungen erfolgen auch innerhalb eines Versionszweigs. Eine belastbare Prüfung nennt die genaue Version und das Prüfdatum.
Sind PostgreSQL und SQLite bloss andere Namen für dieselbe Architektur? Nein. Sie sind eigenständige Systeme. SQLite wird typischerweise als eingebettete Bibliothek verwendet; die anderen hier genannten Systeme werden typischerweise über einen separaten Datenbankdienst angesprochen. Auswahlkriterien müssen zum konkreten Einsatz passen.
Übung: Eine Migrationsmatrix erstellen
Eine kleine Lernplattform verwendet Fremdschlüssel, Transaktionen, JSON-Merkmale, eine sortierte Namenssuche und nächtliche Sicherungen. Erstelle eine Tabelle mit den Spalten Anwendungsfunktion, Annahme, Prüfschritt, erwartetes Ergebnis, tatsächliches Ergebnis und Rückfallmassnahme. Mindestens sechs Zeilen sind erforderlich.
Hilfe 1
Trenne «die Abfrage läuft» von «das Ergebnis entspricht fachlich dem Quellsystem». Überlege bei der Namenssuche auch, welche Bedeutung die Kollation hat.
Beispiel einer begründeten Lösung
| Funktion | Prüfschritt | Erwartung |
|---|---|---|
| Fremdschlüssel | Ungültige Kurskennung einzufügen versuchen | Die Beziehung wird abgewiesen; kein verwaister Datensatz |
| Transaktion | Zweiten Schritt eines Kurswechsels absichtlich fehlschlagen lassen | Vollständiger Ausgangszustand nach bewusstem Rollback |
| JSON | Eigene gültige und ungültige Testwerte sowie verwendete Funktionen prüfen | Dokumentierte, fachlich passende Behandlung |
| Namenssuche | Gleiche Testnamen mit definierten Akzent- und Grossschreibungsfällen suchen | Gewollte und erklärbare Trefferliste |
| Backup | Sicherung auf eine frische getrennte Zielinstanz zurückspielen | Schema und überprüfte Daten vollständig verfügbar |
| Zugriff | Datenbankkonto mit nur benötigten Rechten testen | Erlaubte Aktionen möglich, unnötige Administration verweigert |
Die eigentliche Abgabe ergänzt konkrete Versionen, Beobachtungen und Rückfallmassnahmen. Diese Tabelle behauptet keine bereits ausgeführte Migration.
Transfer und Zusammenfassung
Schreibe eine einseitige Entscheidungsvorlage für eine lokale Einzelbenutzeranwendung und für eine Webanwendung mit mehreren gleichzeitig Schreibenden. Vergleiche dabei auch SQLite und PostgreSQL anhand offizieller Dokumentation. Kennzeichne Annahmen und offene Fragen. Erfinde keine Messwerte.
Historische Verwandtschaft erleichtert manche Wechsel, ersetzt aber keine versionsbezogene Prüfung. Gute Entscheidungen verbinden fachliche Korrektheit, passende Werkzeuge, gemessene Eigenschaften und einen getesteten Rückweg.
Quellen und Prüfung
Primärquellen zuletzt inhaltlich konsultiert am 8. November 2026. Versionsangaben beachten; eine Dokumentationsseite kann sich später ändern.
- MariaDB Foundation: About MariaDB Server
- MariaDB: Unterschiede zwischen MariaDB 11.4 und MySQL 8.0 (versionsgebundener Vergleich)
Konto erstellen, um deinen Bearbeitungsstand zu speichern.