MariaDB vs MySQL: Was ist der Unterschied und was passt zu Ihnen?

MariaDB vs MySQL: Was ist der Unterschied?

Bei MariaDB vs MySQL geht es um zwei relationale Datenbankserver mit gemeinsamem Ursprung, die heute bei Eigentümer, Lizenz, Funktionen und Kompatibilität eigene Wege gehen. MariaDB ist also eine Abspaltung, die eine Community vorantreibt. MySQL gehört dagegen Oracle und erscheint unter der GPL und unter einer kommerziellen Lizenz.

Was bedeutet das für Sie? Als Website Betreiber merken Sie meist wenig, denn beide sprechen dasselbe SQL. Als Entwickler stoßen Sie dagegen konkret auf kleine, aber lästige Details.

Wir sind ein Team für digitales Marketing und Webprojekte, kein Hosting Anbieter. Deshalb stützen wir die technischen Aussagen auf die offizielle Dokumentation. Unser Ziel ist daher ein neutraler Überblick, keine Verkaufsrede. Am Ende wissen Sie, wohin Sie neigen sollten, worauf Sie bei einem Umzug achten und welche Aufgaben Ihr Hosting Anbieter übernehmen sollte.

Woher kommt der Unterschied bei MariaDB vs MySQL?

Zunächst zur Geschichte: MySQL war jahrelang das Produkt einer schwedischen Firma. Danach kaufte Sun Microsystems diese Firma. 2009 kündigte Oracle an, Sun zu übernehmen, und die Zukunft von MySQL wurde zum Streitthema.

Michael "Monty" Widenius, einer der ursprünglichen Entwickler von MySQL, und sein Team sorgten sich um den Open Source Charakter des Projekts. Deshalb spalteten sie den Code ab und starteten 2009 MariaDB. Der Name stammt übrigens von Widenius' Tochter Maria. MySQL trägt den Namen seiner anderen Tochter My.

Dann folgte Ende 2012 die MariaDB Foundation. Sie ist gemeinnützig und soll das Projekt unabhängig von einzelnen Firmen halten. Das heißt, hinter MariaDB stehen eine Community und eine Stiftung.

Oracle treibt dagegen die Entwicklung von MySQL voran. Der Code bleibt offen, allerdings legt eine einzelne Firma die Roadmap fest. Dieser Unterschied erklärt viele Entscheidungen bei Lizenz und Releases, die Sie gleich sehen.

Wie unterscheiden sich die Lizenzen bei MariaDB vs MySQL?

Zunächst stehen beide Community Editionen unter Lizenzen aus der GPL Familie. Der Unterschied zeigt sich allerdings auf der kommerziellen Seite.

Oracle schreibt auf der Lizenzseite, dass es den MySQL Server und die Client Bibliotheken sowohl unter der GPL als auch unter einer kommerziellen Lizenz anbietet. Die kommerzielle Lizenz richtet sich an Softwarehersteller, die MySQL ohne GPL Pflichten in ein Produkt einbauen wollen. Außerdem kosten Enterprise Editionen und Supportpakete Geld.

MariaDB ist dagegen auf dem Papier einfacher. Zudem sagt die Dokumentation, dass der gesamte Code unter GPL, LGPL oder BSD erscheint. Zudem gibt es laut Dokumentation keine geschlossenen Module wie in der MySQL Enterprise Edition. Die Quellen sind der Funktionsvergleich von MariaDB und die Lizenzseite von MySQL.

Wenn Sie nur Ihre eigene Website oder Ihren Onlineshop betreiben, spüren Sie diesen Unterschied im Alltag nicht. Wollen Sie dagegen eine Datenbank in ein Produkt einbauen, das Sie verkaufen, klären Sie die Lizenz zuerst mit einem Juristen.

Welche Speicher Engines trennen MariaDB vs MySQL?

Eine Speicher Engine bestimmt, wie Daten auf der Platte liegen und wie der Server sie wieder liest. In beiden Systemen ist also InnoDB der Standard. Transaktionen, Sperren auf Zeilenebene und die Wiederherstellung nach Abstürzen kommen von dieser Engine. Alltägliche Webanwendungen ruhen daher in beiden auf demselben Fundament.

Die Unterschiede beginnen allerdings bei der Liste der zusätzlichen Engines. Laut MariaDB Dokumentation enthalten die Pakete neben MyISAM, BLACKHOLE, CSV, MEMORY, ARCHIVE und MERGE noch weitere Engines:

• ColumnStore: spaltenorientierte Speicherung für Analyse Aufgaben.
• MyRocks: eine Engine mit Fokus auf Kompression, die zu schreibintensiven Lasten passt.
• Aria: als absturzsicherer Nachfolger von MyISAM entwickelt.
• Spider und CONNECT: Zugriff auf entfernte Tabellen und andere Datenquellen.
• SEQUENCE, FederatedX, OQGRAPH und SphinxSE.

Die meisten dieser Engines brauchen Sie nicht. Denn die meisten Websites nutzen nur InnoDB. Zum Beispiel betreibt eine typische WordPress Installation ihre Tabellen mit InnoDB und berührt die zusätzlichen Engines nie. Fragen Sie sich also, ob Sie wirklich Bedarf haben, bevor Sie die Vielfalt als Argument nutzen.

Welche Funktionen gibt es nur bei MariaDB?

Die MariaDB Dokumentation hebt einige Funktionen hervor, die in eigenen Releases entstanden sind. In zeitlicher Reihenfolge:

• Parallele Replikation und Replikation aus mehreren Quellen: kam mit MariaDB 10.0.
• Neue JSON Funktionen: erschienen mit MariaDB 10.2.
• SEQUENCE Unterstützung nach Oracle Vorbild: kam mit MariaDB 10.3.
• Tabellen mit Systemversionierung: erlauben Abfragen auf historische Daten und starteten mit MariaDB 10.3.
• Thread Pool: hilft dem Server bei vielen gleichzeitigen Verbindungen.

Lesen Sie diese Liste allerdings nicht einseitig. Andererseits bekommt auch MySQL mit jedem Release neue Funktionen. MySQL 8.4 ist zum Beispiel ein Release mit Langzeitunterstützung (LTS) und entfernt einige ältere Funktionen.

Legen Sie daher beim Vergleich immer die Versionsnummer fest. Sagen Sie stattdessen nicht "MariaDB kann das", sondern "diese MariaDB Version kann das, diese MySQL Version nicht". Sonst vergleichen Sie Funktionen aus zwei verschiedenen Epochen.

Warum arbeitet JSON bei MariaDB vs MySQL anders?

JSON ist eine der bekanntesten Stellen, an denen sich die Systeme trennen. MySQL bietet einen eigenen JSON Datentyp und speichert die Daten in einem eigenen Binärformat. Dieses Format zielt anders gesagt auf schnellen Zugriff auf Felder im Dokument.

Die MariaDB Dokumentation sagt klar, dass sie einen anderen Weg geht. MariaDB dagegen folgt dem SQL Standard und speichert JSON als gewöhnlichen TEXT oder BLOB. JSON Funktionen gibt es trotzdem, Ihre Abfragen laufen also weiter.

Das hat drei praktische Folgen:

• Wenn Sie eine Tabelle mit JSON Spalten zwischen den Systemen verschieben, müssen Sie testen.
• Prüfen Sie, ob Ihre Anwendung von JSON Funktionen abhängt, die nur MySQL kennt.
• Das Verhalten bei Indizes und Validierung kann sich von Version zu Version ändern.

Zum Beispiel: Speichert Ihre Anwendung JSON nur als einfaches Einstellungsfeld, merken Sie vermutlich nichts. Läuft in Ihrer Software dagegen viel JSON Abfragelast, probieren Sie zuerst einen kleinen Versuch. Prüfen Sie dann dabei sowohl die Richtigkeit der Ergebnisse als auch die Laufzeiten.

Ist MariaDB ein direkter Ersatz für MySQL?

Die kurze Antwort: Früher ja, heute nicht immer. Die Kompatibilitätsseite in der MariaDB Dokumentation zeigt, dass der einfache Wechsel mit neueren Versionen schwindet.

Dieselbe Seite betont zwei Gemeinsamkeiten. Erstens sind MariaDB Datendateien in der Regel binärkompatibel zur passenden MySQL Version. Zweitens ist das MariaDB Client Protokoll binärkompatibel zum MySQL Client Protokoll. Daher verbinden sich Client Bibliotheken in PHP, Python oder Node.js meist mit beiden Servern. In der Praxis müssen Sie die Verbindungszeile im Anwendungscode selten ändern.

Kompatibles Protokoll heißt allerdings nicht, dass jede Funktion gleich arbeitet. Denn verbinden ist eine Sache, ein Schema ohne Überraschungen umzuziehen eine andere. Die Tabelle im nächsten Abschnitt fasst zusammen, welche Versionspaare zusammenpassen.

Welche MariaDB Version passt zu welcher MySQL Version?

Die offizielle Kompatibilitätsseite von MariaDB fasst die Zuordnung so zusammen. Wir haben die Tabelle für einen schnellen Überblick gebaut, Details finden Sie in der Quelle:

Die letzte Zeile ist die wichtigste. Die MariaDB Dokumentation sagt, dass die Unterschiede in der Umsetzung ab 10.6 weiter wachsen. Folglich stimmte der Satz "MariaDB ist eine Eins zu eins Kopie von MySQL" für alte Versionen und stimmt für neue nicht mehr.

Quelle: das Kompatibilitätsdokument von MariaDB und MySQL.

Welche Lücken gibt es bei Authentifizierung und Replikation?

Die Kompatibilitätsseite nennt außerdem einige konkrete Stolperstellen für einen Umzug. Alle beschreiben ältere Versionspaare, die Logik gilt aber auch heute:

• GTID: Die GTID Umsetzung von MariaDB arbeitet nicht mit MySQL 5.6 zusammen. Daher kann MySQL 5.6 kein Replikat von MariaDB 10.0 sein.
• Passwörter: Benutzer mit dem SHA256 Passwortverfahren von MySQL können sich zum Beispiel bei MariaDB 10.0 nicht anmelden.
• Gruppenreplikation: Die Gruppenreplikation von MySQL 5.7 funktioniert nicht mit dem Galera Cluster von MariaDB.
• Views und Zeitdaten: Sie müssen eventuell Views neu anlegen oder Zeitformate prüfen.

Zudem aktiviert MySQL 8.4 das Plugin mysql_native_password nicht mehr standardmäßig. Laut offizieller Dokumentation müssen Sie den Server mit einer bestimmten Option starten, um es wieder einzuschalten. Hängt eine alte Anwendung an diesem Plugin, sehen Sie womöglich Verbindungsfehler.

Setzen Sie die Authentifizierung deshalb weit oben auf Ihre Testliste vor dem Umzug.

Welche Datenbank läuft bei cPanel und Shared Hosting?

Eine allgemeingültige Antwort gibt es allerdings nicht. Ihr Hosting Anbieter installiert eine der beiden, und Ihr Konto nutzt sie. Manche Anbieter setzen auf MariaDB, andere dagegen auf MySQL. Manchmal steht im Panel "MySQL", obwohl darunter MariaDB läuft, denn beide teilen Client Befehle und Protokoll.

Das herauszufinden ist einfach. Zunächst zeigt die Startseite von phpMyAdmin Servertyp und Version. Alternativ führen Sie diese Abfrage aus:

SELECT VERSION(), @@version_comment;

Taucht in der Ausgabe MariaDB auf, dann ist es MariaDB. Bei der Anbieterwahl lohnt es sich zudem, nach Datenbankversion und Supportzeitraum zu fragen. Alle Auswahlkriterien beschreiben wir in Webhosting auswählen: Server Kriterien. Möchten Sie sehen, wer einen Server betreibt, hilft unser IP Abfrage Tool.

Was passt besser zu WordPress und Onlineshops?

Die offiziellen Anforderungen von WordPress nennen MySQL und MariaDB gemeinsam. Zudem unterstützen auch beliebte Frameworks wie Laravel beide. Die Datenbankwahl allein entscheidet also auf diesen Plattformen nicht über den Erfolg.

In der Praxis läuft die Entscheidung so:

• Shared Hosting: Die Wahl trifft der Anbieter, nicht Sie. Achten Sie darauf, dass die Version aktuell ist.
• Eigener VPS: Der Standard aus dem Paketarchiv Ihrer Distribution macht meist die wenigsten Probleme.
• Entwicklung von Produkten oder Plugins: Testen Sie mit beiden, damit Ihr Produkt beim Hosting Ihrer Zielgruppe läuft.

Im Onlineshop liegt allerdings das eigentliche Risiko nicht in der Engine, sondern in Backups und langsamen Abfragen. Zum Beispiel bremst ein fehlender Index auf der Bestelltabelle den Warenkorb, egal für welche Engine Sie sich entscheiden. Wie Ladezeit den Umsatz beeinflusst, lesen Sie in Ladezeit im Onlineshop: Beeinflusst sie den Umsatz?. Bei Kampagnen springt der Traffic, deshalb zeigen sich diese Schwächen schnell.

Brauchen Sie bei einem Webprojekt eine Entscheidung zur Infrastruktur, unterstützen wir Sie mit unserem Webdesign Angebot und unserer individuellen Softwareentwicklung.

Verändert MariaDB vs MySQL die Performance?

Das kann sein, aber einen pauschalen Sieger zu nennen, wäre irreführend. Die Performance hängt von Version, Konfiguration, Hardware, Schema und Abfragen ab. Die meisten Aussagen der Form "diese Engine ist X Prozent schneller" gelten für eine Last und bestimmte Versionen.

Deshalb nennen wir keine Zahlen. Auch die offizielle Dokumentation liefert daher keine allgemeine Zahl. Außerdem hängt ein Benchmark von Dutzenden Faktoren ab, von der Hardware bis zur Netzwerklatenz. Wir empfehlen stattdessen diese Reihenfolge:

1. Schalten Sie zunächst das Protokoll für langsame Abfragen ein und suchen Sie die schwersten Abfragen.
2. Legen Sie dann die passenden Indizes für diese Abfragen an.
3. Danach überlegen Sie eine Cache Schicht.
4. Zuletzt bewerten Sie einen Wechsel von Engine oder Version, und zwar mit Messungen.

Schritt 1 und 2 bringen also oft viel mehr als ein Engine Wechsel. Denn Langsamkeit entsteht meist durch schlechte Abfragen und nicht durch die Engine. Ein einziger Index kann eine Abfrage von Sekunden auf Millisekunden drücken. Zum Caching lesen Sie Caching erklärt: Redis und Memcached. Den Zusammenhang von Tempo und Ranking finden Sie in Wie beeinflusst die Ladezeit die SEO?.

Wie unterscheiden sich Sicherheit und Update Politik?

Beide Projekte veröffentlichen regelmäßig Sicherheitspatches. Der echte Unterschied liegt im Release Modell und im Supportkalender. Oracle kennzeichnet zum Beispiel MySQL 8.4 als LTS Release. Auch MariaDB hat Releases mit Langzeitsupport, den Kalender prüfen Sie aber auf den Seiten von MariaDB.

Wir nennen hier keine Daten und keine Versionszahlen, denn Supportkalender ändern sich. Stattdessen sagen wir "aktuelles stabiles Release".

Sicherheit hängt vor allem an der Pflege als am Namen der Engine. Konkret ist eine ungepatchte MariaDB so riskant wie eine ungepatchte MySQL. Diese Gewohnheiten zählen mehr als die Wahl:

• Betreiben Sie keine Version ohne Support in der Produktion.
• Geben Sie Datenbankbenutzern nur die Rechte, die sie brauchen.
• Öffnen Sie den Datenbankport nicht zum Internet.
• Vernachlässigen Sie die Prüfung von Eingaben in Ihrer Anwendung nicht.

Außerdem kommen die meisten Angriffe auf Datenbanken über Lücken im Anwendungscode. Dazu mehr in OWASP Top 10: Sicherheitslücken in Webanwendungen und Maßnahmen.

Wie ziehen Sie zwischen MariaDB und MySQL um?

Ein Umzug ist keine Kopieraufgabe. Die folgende Reihenfolge ist eine allgemeine Checkliste, die der Logik der offiziellen Kompatibilitätshinweise folgt:

1. Erstellen Sie ein vollständiges Backup. Lagern Sie es an einem anderen Ort und probieren Sie einmal die Wiederherstellung.
2. Legen Sie die Versionen fest. Notieren Sie Quell und Zielversion und prüfen Sie die Kompatibilitätstabelle.
3. Bauen Sie eine Testumgebung. Lassen Sie Ihre Anwendung gegen eine Kopie der Produktionsdaten laufen.
4. Prüfen Sie Benutzer und Plugins. Bestätigen Sie das Anmeldeverfahren.
5. Testen Sie JSON, Views und Zeitspalten.
6. Planen Sie die Replikation getrennt. GTID und Cluster unterscheiden sich.
7. Führen Sie nach dem Wechsel das Upgrade Werkzeug aus. Laut Dokumentation aktualisiert es die Rechte und Ereignistabellen mit den neuen Feldern.

Ein typisches logisches Backup sieht so aus. Benutzer und Datenbanknamen sind Beispiele:

mysqldump --single-transaction --routines --events -u example_user -p example_db > example_db.sql
mysql -u example_user -p example_db < example_db.sql

Neuere Releases liefern diese Werkzeuge eventuell auch unter Namen mit dem Präfix mariadb. Prüfen Sie daher die Dokumentation Ihrer eigenen Version. Das ganze Bild zu Sicherungen finden Sie in unserer Strategie für Website Backups.

Warum verwirren die Befehlsnamen?

Ältere Anleitungen zeigen Befehle wie mysql, mysqldump und mysql_upgrade. MariaDB behielt diese Namen lange, denn es ging um Kompatibilität. In neueren Releases rücken die Varianten mit dem Präfix mariadb nach vorn. Welcher Name auf Ihrem Server funktioniert, hängt von Distribution und Version ab.

Das führt zu zwei Arten von Verwirrung, also zu zwei Stolpersteinen. Erstens kopieren Sie vielleicht einen Befehl aus einer Anleitung und erhalten "Befehl nicht gefunden". Zweitens verhält sich derselbe Befehl auf beiden Systemen womöglich leicht anders.

Wir empfehlen daher diese Gewohnheiten:

• Prüfen Sie vor dem Ausführen mit --version oder --help, was der Befehl ist.
• Prüfen Sie, für welche Version die Anleitung gedacht ist.
• Bestätigen Sie den Befehlsnamen im Zweifel in der offiziellen Dokumentation Ihrer Version.

Die Dokumentation von MySQL 8.4 sagt, dass das Werkzeug mysql_upgrade in diesem Release entfällt. Ein Upgrade Schritt aus einer alten Anleitung funktioniert also in einer neuen MySQL Version eventuell nicht. Kurz gesagt: Ein Versionsunterschied bedeutet einen Befehlsunterschied.

Was sollten Sie nach dem Umzug testen?

Wenn der Umzug fertig ist, reicht "die Seite öffnet sich" nicht. Zudem zeigen sich Datenbankprobleme oft leise, auf einer Seite oder bei einer Aktion. Bereiten Sie deshalb eine kurze, aber systematische Testliste vor.

Wiederholen Sie die Tests direkt nach dem Wechsel und noch einmal nach einigen Tagen. Behalten Sie außerdem den alten Server eine Weile, damit Sie bei Problemen zurückgehen können. Wählen Sie für den Wechsel eine Stunde mit wenig Traffic, denn das Ausfallrisiko ist real.

Wie erkennen Sie, welche Datenbank Ihr Server nutzt?

Verwalten Sie einen eigenen VPS oder haben Zugang zum Hosting Panel, finden Sie es auf drei Wegen heraus:

• SQL Abfrage: Nennt SELECT VERSION(); den Namen MariaDB, ist der Server MariaDB.
• Versionskommentar: SELECT @@version_comment; zeigt die Beschreibung Ihrer Distribution.
• phpMyAdmin: Die Startseite nennt Servertyp und Version.

Auch auf der Kommandozeile können Sie nachsehen:

mysql --version

Auf neueren Distributionen läuft dieser Befehl auch dann, wenn darunter MariaDB arbeitet. Distributionen behalten nämlich die alten Befehlsnamen aus Kompatibilitätsgründen. Lesen Sie daher den Text in der Ausgabe.

Notieren Sie die Version und geben Sie sie an, wenn Sie den Support anschreiben. So klären Sie ein Problem also viel schneller. Sehen Sie auf Ihrem Server MariaDB, ist das kein Grund zur Sorge. Im Hosting ist das sehr verbreitet und völlig normal.

Diese Prüfungen lesen nur und richten keinen Schaden an. Stellen Sie trotzdem sicher, dass Sie auf dem Server Befehle ausführen dürfen.

Ändern verwaltete Datenbankdienste die Wahl?

Cloud Anbieter und einige Hosting Firmen bieten verwaltete Dienste, die die Datenbank für Sie betreiben. Dort übernimmt der Anbieter Upgrades, Backups und Patches. Aus "Welche Engine installiere ich?" wird also "Welche Engine bieten die an und welche Version unterstützen sie?".

Zudem gibt es oft mehr als eine Option. Welche Versionen angeboten werden und wie lange sie Support bekommen, unterscheidet sich allerdings je nach Anbieter. Bestätigen Sie das auf der offiziellen Seite Ihres Anbieters, wir listen es hier nicht einzeln auf.

Auch die Kosten verdienen einen nüchternen Blick. Bei Shared Hosting ist die Datenbank Engine kein eigener Posten. Platte, CPU, Speicher und Supportqualität bestimmen den Preis. Möchten Sie eine kommerzielle Lizenz oder Enterprise Support, prüfen Sie die aktuellen Preise auf den offiziellen Seiten der Hersteller.

Der Vorteil eines verwalteten Dienstes: Fachleute übernehmen die riskanten Aufgaben. Der Nachteil ist allerdings weniger Freiheit bei der Konfiguration. Für eine einzelne Firmenwebsite oder einen kleinen Blog ist ein eigener Datenbankbetrieb oft unnötige Arbeit. Geben Sie diese Aufgabe an Leute ab, die die Infrastruktur kennen, und konzentrieren Sie sich auf Ihr Geschäft.

Entscheidet die Wahl über den Datenschutz?

Nein, nicht allein. Vorschriften wie die DSGVO fragen, wie Sie mit personenbezogenen Daten umgehen, nicht nach dem Namen der Engine. MariaDB und MySQL unterstützen beide Zugriffskontrolle, verschlüsselte Verbindungen und Backups, wenn Sie sie sauber konfigurieren.

Diese Fragen zählen mehr:

• Wer kommt an die Datenbank, und sind die Rechte weiter gefasst als nötig?
• Wo liegen Backups, und wer kommt an sie heran?
• Ist die Verbindung zwischen Anwendung und Datenbank verschlüsselt?
• Müssen Sie diese personenbezogenen Daten überhaupt speichern?

Somit zählen die Antworten weit mehr als die Wahl der Engine. Speichert Ihre Website Kundendaten, arbeiten Sie mit einer Rechtsberatung und Ihrem Infrastrukturanbieter zusammen. Wir geben keine Rechtsauskunft. Wir erklären nur den technischen Hintergrund.

Wann wählen Sie MariaDB, wann MySQL?

Die folgende Tabelle ist eine Entscheidungshilfe, keine feste Regel. Richten Sie sich daher nach Ihrem Bedarf und nach dem Angebot Ihres Hosting Anbieters.

Die ehrlichste Folgerung: Ersetzen Sie ein funktionierendes System nicht aus Modegründen. Sie brauchen einen konkreten Grund für den Umzug. Er ergibt zum Beispiel Sinn, wenn Ihr Hoster eine alte Version abschaltet oder wenn Sie eine Funktion brauchen, die nur eine der beiden bietet.

Welche Mythen zu MariaDB vs MySQL begegnen Ihnen am häufigsten?

In Foren kursieren allerdings einige falsche Annahmen. Wir korrigieren sie der Reihe nach:

• "MariaDB ersetzt MySQL immer unverändert." Nur bei alten Versionen und nur eingeschränkt. Bei neueren Versionen dagegen wachsen die Unterschiede.
• "MariaDB ist immer schneller." Einen allgemeinen Tempo Sieger gibt es nicht. Stattdessen messen Sie mit Ihrer eigenen Last.
• "MySQL ist nicht mehr Open Source." Die MySQL Community Edition erscheint unter der GPLv2. Die kommerzielle Lizenz ist eine zusätzliche Option.
• "Das SQL ist exakt gleich." Die meisten Abfragen laufen, aber Funktionen und Datentypen können auseinanderlaufen.
• "Mit einem Engine Wechsel wird meine Seite schneller." Auf den meisten Websites liegt das Problem bei fehlenden Indizes, schweren Abfragen und fehlendem Caching.

Falsche Annahmen stammen nämlich meist aus altem Versionswissen. Ein Satz, der vor vier oder fünf Jahren stimmte, kann heute falsch sein. Prüfen Sie deshalb jede Aussage in der offiziellen Dokumentation Ihrer eigenen Version.

Wann überlassen Sie es besser Ihrem Hosting Anbieter?

Manche Aufgaben können Sie per Befehl erledigen, müssen es aber nicht. Geben Sie die Aufgabe in diesen Fällen an Ihren Hosting Anbieter oder an einen erfahrenen Systemadministrator ab:

• Sie wollen bei Shared Hosting die Datenbankversion ändern. Dafür haben Sie ohnehin keine Rechte, denn der Anbieter verwaltet den Server.
• Sie wollen die Datenbank eines laufenden Onlineshops ohne Backup verschieben.
• Es geht um Replikation, Cluster oder Hochverfügbarkeit.
• Sie haben noch nie Konfigurationsdateien eines Servers bearbeitet.
• Sie haben weder einen Rückfallplan noch eine Testumgebung.

Experimentieren Sie auf Ihrem eigenen VPS, um zu lernen, ist das großartig. Außerdem ist es einer der besten Wege, Können aufzubauen. Erstellen Sie aber zuerst einen Snapshot und spielen Sie nicht mit Produktionsdaten. Wir bieten kein Hosting an und erledigen deshalb keine Arbeiten am Server für Sie. Bei Anwendung und Web stehen wir dagegen an Ihrer Seite.

Wo beginnen Sie am besten mit dem Lernen?

Das stärkste Fundament in der Datenbankarbeit ist SQL. Beide Systeme teilen zudem die Sprache zu einem großen Teil. Kennen Sie SQL, erledigen Sie die Grundaufgaben auf jeder Engine, der Sie begegnen.

Wir empfehlen diese Reihenfolge:

• Lernen Sie zunächst SELECT, JOIN, GROUP BY und die Funktionsweise von Indizes.
• Bauen Sie dann in einer Testumgebung eine eigene Beispieldatenbank.
• Danach probieren Sie einmal Backup und Wiederherstellung.
• Schließlich lesen Sie die Versionsunterschiede in der offiziellen Dokumentation.

Für SQL ist unser Fahrplan für SQL lernen von null bis fortgeschritten ein guter Start. Bereiten Sie sich auf Vorstellungsgespräche vor, lesen Sie SQL Interview Fragen und Abfrageszenarien. Für eine schnelle Testumgebung erklärt unser Leitfaden Was ist Docker? die Idee der Container.

Was ist die Kurzfassung zu MariaDB vs MySQL?

Kurz gesagt geht es bei MariaDB vs MySQL um Geschichte, Lizenz, zusätzliche Funktionen und wachsende Lücken bei der Kompatibilität. SQL Grundlagen und Client Protokoll sind gemeinsam, deshalb laufen die meisten Websites mit beiden.

Stellen Sie sich vor der Entscheidung drei Fragen:

• Welche Datenbank bietet mein Hosting Anbieter, und bekommt diese Version noch Support?
• Welche unterstützt meine Anwendung offiziell?
• Habe ich einen konkreten Grund für den Umzug?

Können Sie nicht alle drei klar beantworten, lassen Sie das funktionierende System in Ruhe. Erstellen Sie stattdessen Ihre Backups, halten Sie die Version aktuell und räumen Sie langsame Abfragen auf. Somit bringen diese drei Schritte weit mehr als die Wahl der Engine. In einem Schwesterartikel behandeln wir außerdem die Installation von MySQL getrennt.