MySQL 5.7 auf 8.4 migrieren: Was kaputt geht und wie ich es repariere

MySQL 5.7 ist seit Oktober 2023 End of Life. Das bedeutet: keine Sicherheits-Updates mehr, keine Bugfixes. Trotzdem laufen noch viele Produktionssysteme damit – weil "es läuft ja". Bis es nicht mehr läuft. Ich beschreibe hier, was in der Praxis beim Upgrade auf Version 8 wirklich bricht und wie ich systematisch vorgehe.

Was konkret bricht

ONLY_FULL_GROUP_BY und der sql_mode

MySQL 8 aktiviert standardmäßig einen strengeren sql_mode, darunter ONLY_FULL_GROUP_BY. Viele Legacy-Queries, die jahrelang funktioniert haben, schlagen damit fehl. Ein typisches Beispiel:

-- Funktioniert in 5.7, schlägt in 8.x fehl:
SELECT id, name, MAX(created_at)
FROM orders
GROUP BY customer_id;

-- Fix: alle nicht-aggregierten Spalten in GROUP BY aufnehmen
SELECT MIN(id), MIN(name), MAX(created_at)
FROM orders
GROUP BY customer_id;

Alternativ lässt sich ONLY_FULL_GROUP_BY temporär deaktivieren – das sollte aber nur als Übergangslösung dienen, nicht als Dauerzustand.

NO_ZERO_DATE und ungültige Datumswerte

Legacy-Systeme speichern gerne 0000-00-00 als Platzhalter für "kein Datum". MySQL 8.x lehnt das standardmäßig ab. Betroffene Spalten müssen entweder auf NULL umgestellt oder die Werte migriert werden.

Authentication Plugin

MySQL 8.x verwendet standardmäßig caching_sha2_password statt mysql_native_password. Ältere PHP-Versionen oder PDO-Treiber ohne SSL-Support können sich damit nicht verbinden. Kurzfristig lässt sich das pro User oder global auf das alte Plugin zurückstellen – langfristig sollte man die Verbindungsinfrastruktur anpassen.

Reservierte Keywords

Wörter wie rank, groups, lateral und system sind in MySQL 8.x reservierte Keywords. Tabellen- oder Spaltennamen, die diese Wörter verwenden, müssen in Backticks gesetzt werden – oder umbenannt werden, was ich bevorzuge.

Der Migrations-Prozess

Ich gehe immer in drei Stufen vor: lokale Testumgebung, dann Staging, dann Produktion. Niemals direkt auf Produktion – das klingt selbstverständlich, ist es in der Praxis aber nicht immer.

Vor jeder Migration mache ich ein vollständiges Backup mit mysqldump:

mysqldump -u root -p \
  --single-transaction \
  --routines \
  --triggers \
  --all-databases > backup_vor_upgrade.sql

Dann installiere ich MySQL 8.4 lokal, importiere den Dump und führe die Anwendung aus. Die auftretenden Fehler dokumentiere ich und behebe sie systematisch – erst dann geht es auf Staging.

In einem Projekt hatten wir 47 Queries mit GROUP-BY-Problemen. Das klingt viel – es war aber innerhalb von zwei Tagen bereinigt, weil die Fehler durch den strikten Modus klar und eindeutig gemeldet wurden. In 5.7 liefen dieselben Queries einfach stillschweigend mit falschen Ergebnissen.

Fazit

Der Upgrade auf MySQL 8 ist keine Kleinigkeit, aber er ist handhabbar. Die häufigsten Probleme – GROUP BY, Datumswerte, Authentication – sind gut dokumentiert und folgen klaren Mustern. Wer jetzt noch auf 5.7 ist, sollte nicht weiter warten: Sicherheitslücken in einer ungepatchten Datenbank sind kein theoretisches Risiko mehr.