Shopware mit MySQL: Best Practice

Die Wahl der passenden Datenbank ist für einen erfolgreichen Shopware-Shop entscheidend. Viele Hosting-Anbieter bieten sowohl MySQL als auch MariaDB an. Beide Systeme basieren auf ähnlichen Grundlagen, unterscheiden sich aber in Details, Funktionsumfang und Entwicklungsgeschwindigkeit. Im Folgenden erfährst du, worauf es bei der Entscheidung ankommt, welche Vorteile MySQL bietet und wie du die optimale Konfiguration für deinen Shop erreichst.

Inhaltsverzeichnis

• 1. Die Entstehung von MariaDB
• 2. Die Vorteile – Zahlen, Daten, Fakten
• 3. Welche MySQL Version ist die richtige für Shopware?
• 4. Vier wichtige Einstellungen
• 5. sql_mode und group_concat_max_len
• 6. Anpassung der .env-Datei
• 7. max_allowed_packet
• 8. Besonderheiten bei der Nutzung von Shopware mit MySQL
• 9. Praxis-Tipps & Geheimwissen
• 10. Fazit
• 11. Quellen
• 12. Weiterführende Links

1. Die Entstehung von MariaDB

MariaDB wurde 2009 von Michael „Monty“ Widenius, einem der ursprünglichen Entwickler von MySQL, gegründet. Auslöser war die Übernahme von MySQL durch Oracle, die in der Open-Source-Community große Bedenken hinsichtlich der künftigen Offenheit und Unabhängigkeit von MySQL auslöste.

MariaDB entstand als Fork von MySQL, um eine freie und offene Weiterentwicklung zu sichern. Viele der ursprünglichen MySQL-Entwickler schlossen sich dem neuen Projekt an. Anfangs war MariaDB als Drop-in-Replacement für MySQL konzipiert, entwickelte aber ab Version 10.0 zunehmend eigene Funktionen und Innovationen.

Heute ist MariaDB in vielen Linux-Distributionen als Standarddatenbank enthalten und wird insbesondere bei 1-Klick Installationen für Shopware verwendet. Ich geh auch davon aus, dass die meisten Shopware Freelancer und Agenturen eher Maria DB als MySQL verwenden. Mein Bauchgefühl sagt da ungefähr 70% Maria DB und 30% MySQL.

Zurück zur Übersicht

2. Die Vorteile – Zahlen, Daten, Fakten

Kommen wir zu den handfesten Vorteilen und technischen Fakten, die den Unterschied zwischen MySQL und MariaDB im Shopware-Umfeld ausmachen. Hier zeigt sich, wo MySQL seine Stärken im Alltag wirklich ausspielt:

• JSON-Felder und Filter: MySQL (ab Version 8) verarbeitet JSON-Daten nativ und deutlich effizienter als MariaDB, das JSON als LONGTEXT behandelt. Das wirkt sich bei komplexen Filtern und dynamischen Attributen positiv auf die Geschwindigkeit aus.
• Große Kataloge und Varianten: Bei sehr vielen Produkten oder Varianten profitiert MySQL von ausgereiften Index- und JOIN-Optimierungen. Abfragen bleiben auch bei großen Datenmengen performant.
• Custom Fields und Plugins: Viele Erweiterungen speichern zusätzliche Felder als JSON. MySQL verarbeitet diese flexibler und schneller, was sich auf Ladezeiten und Backend-Reaktionszeiten auswirkt.
• Hohe Last und parallele Zugriffe: MySQL bleibt auch bei vielen gleichzeitigen Anfragen stabil und zuverlässig. Moderne Optimierungsverfahren sorgen für eine effiziente Ausführung komplexer Abfragen.
• Elasticsearch für Suche und Filter: Bei großen Shops oder komplexen Suchanforderungen sorgt Elasticsearch für konstante Antwortzeiten im Millisekundenbereich – unabhängig von der Datenbankgröße. Die Integration entlastet die Datenbank erheblich.
• Transaktionssicherheit: ACID-Transaktionen und Row-Level-Locking reduzieren Konflikte bei parallelen Bestellungen.
• Skalierbarkeit: MySQL unterstützt nativ verschiedene Cluster- und Replikationsmodelle, was die horizontale Skalierung und Ausfallsicherheit erleichtert.
• Offizielle Empfehlung: Shopware empfiehlt ab Version 6 ausdrücklich MySQL 8 für alle modernen Installationen, insbesondere bei vielen Produkten, Varianten und JSON-Feldern.

So eignen sich diese Stärken insbesondere für Shopware-Betreiber, die große Produktkataloge, komplexe Filter- und Suchfunktionen, viele individuelle Felder oder hohe Zugriffszahlen im Shop abbilden möchten – denn hier spielt MySQL seine technischen und performanceseitigen Vorteile voll aus. Besonders relevant ist dies auch für Shops, die intensiv mit Custom Fields arbeiten: Diese Zusatzfelder werden häufig von Themes und Plugins verwendet, um Produkte, Kunden oder Bestellungen flexibel zu erweitern. Da Custom Fields in Shopware als JSON gespeichert werden, profitieren gerade solche Szenarien mit vielen individuellen Erweiterungen und Plugin-Funktionen besonders von der nativen und schnellen JSON-Verarbeitung in MySQL.

Zurück zur Übersicht

3. Welche MySQL Version ist die richtige für Shopware 6?

Kommen wir nun zu der Frage, welche MySQL Version genutzt werden sollte. Dafür sollten wir zunächst einmal wissen, dass es MySQL 8 (MySQL 5 ist zu alt und die MySQL 9 Versionen sind noch nicht kompatibel) in folgenden Versionen gibt:

Legende:

• LTS = Long-Term Support (Langzeitunterstützung)
• Innovation = Kurzlebige Innovationsreleases mit neuen Features.

Wichtige Hinweise:

• MySQL 8.0 ist noch bis April 2026 im Support, wird aber nicht mehr weiterentwickelt (nur noch Bugfixes).
• MySQL 8.4 ist die aktuelle LTS-Version mit Support bis 2032 und wird für produktive Umgebungen empfohlen.
• MySQL 9.x sind Innovationsreleases mit neuen Features, aber ohne Langzeitunterstützung.

Zusammenfassung:

• Für stabile, lang laufende Systeme ist MySQL 8.4 LTS die empfohlene Version.
• Wer neue Features frühzeitig nutzen möchte, kann die Innovation Releases (z. B. 9.3) einsetzen, muss aber mit häufigeren Upgrades rechnen.

In den Shopware Docs heißt es hierzu:

Recommended version: 8.4
Minimum version: 8.0.22

Die Versionen 8.1 – 8.3 kann man überspringen, da es sich hierbei nur um Kurzzeit Support-Versionen handelt. Wer auf „Nummer sicher“ gehen will nimmt 8.0 da es bei MySQL 8.4 noch vereinzelt zu Inkompatibilitäten mit Plugins kommen könnte.

MySQL 8.0 und 8.4 im Vergleich

MySQL 8.4 bietet gegenüber MySQL 8.0 zahlreiche Vorteile, die besonders für Unternehmen mit hohen Anforderungen an Stabilität, Sicherheit und Compliance relevant sind. Der wichtigste Unterschied ist der Langzeit-Support (LTS): MySQL 8.4 erhält bis 2032 regelmäßige Sicherheitsupdates und Bugfixes, was eine planbare und sichere Nutzung über viele Jahre hinweg ermöglicht. Die Standardwerte wurden gezielt für moderne Hardware wie SSDs und RAID-Systeme optimiert, sodass MySQL 8.4 dort spürbar schneller und effizienter arbeitet – insbesondere bei schreibintensiven Workloads.

Insgesamt ist MySQL 8.4 die beste Wahl für Unternehmen, die auf eine zukunftssichere, performante (mehr dazu weiter unten) und compliance-gerechte Datenbanklösung setzen möchten.

Zurück zur Übersicht

4. Vier wichtige Einstellungen

Auf dem Weg zu einem leistungsstarken und stabilen Shopware-Shop gilt es, vier entscheidende Einstellungen vorzunehmen. Diese Konfigurationen sind das Fundament für eine reibungslose Zusammenarbeit zwischen Shopware und MySQL – und der Schlüssel, um das volle Potenzial deines Shops auszuschöpfen. Mach dich bereit, diese Etappen Schritt für Schritt zu meistern und deinen Shop fit für Wachstum und Performance zu machen!

• group_concat_max_len auf mindestens 320000.
• Entferne ONLY_FULL_GROUP_BY aus dem SQL-Mode.
• Setzen den Wert in der für SQL_SET_DEFAULT_SESSION_VARIABLES auf 0 .
• Erhöhe max_allowed_packet auf mindestens 32M.

Diese vier Einstellungen sollten auf allen Servern eines Clusters identisch gesetzt werden. Im nächsten Abschnitt führen wir dich durch die Details und zeigen, wie du jede einzelne Konfiguration erfolgreich umsetzt.

Zurück zur Übersicht

5. sql_mode und group_concat_max_len

Der Wert group_concat_max_len ist für Shopware auf mindestens 320.000 zu setzen. Der SQL-Mode ONLY_FULL_GROUP_BY ist nicht kompatibel und muss entfernt werden.

Beispiel-Konfiguration für den sql_mode:

sql_mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

Beispiel-Konfiguration für den group_concat_max_len Wert:

group-concat-max-len=320000

Sollte die Datenbank bei Timme Hosting liegen und als Container gehostet werden, müssen die Einstellungen bei jeder Datenbank einzeln gesetzt werden. Das geht hier: Webseiten > Datenbanken > eine_datenbank_auswählen > Erweiterte Einstellungen > Datenbank-Einstellungen (optional):

Hier können wir jetzt mit diesen Zeilen zwei Fliegen mit einer Klappe schlagen:

--sql-mode="STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"
--group-concat-max-len=320000

Sobald wir diese beiden Punkte erledigt haben kann es zum nächsten Punkt weitergehen, nämlich der Anpassung unserer .env Datei

Zurück zur Übersicht

6. Anpassung der .env-Datei

SQL_SET_DEFAULT_SESSION_VARIABLES=0

#  * .env                contains default values for the environment variables needed by the app
#  * .env.local          uncommitted file with local overrides
#  * .env.$APP_ENV       committed environment-specific defaults
#  * .env.$APP_ENV.local uncommitted environment-specific overrides

Zurück zur Übersicht

7. max_allowed_packet

Setze max_allowed_packet auf mindestens 32 MB, um Übertragungsfehler bei großen Datenmengen zu vermeiden.

Wer Zugriff darauf hat kann den Wert in seiner mysql.cnf folgendermaßen anpassen:

[mysqld]
max_allowed_packet = 32M

Andernfalls werdet ihr euch an euren Hosting Anbieter wenden müssen. Bei unserem Server lag der Wert im Standard bei 20 MB und wurde auf unsere Anfrage angepasst.

Zurück zur Übersicht

8. Besonderheiten bei der Nutzung von Shopware mit MySQL

Anderer Port

Bei einigen Hostern verwendet die Datenbank einen anderen Port als die Standard-Datenbank. Zudem kann es außerdem sein, dass jede einzelne Datenbank ihren eigenen Port hat. In unserem fall war der Port z.B. 14500 für die erste, 14501 für die zweite, 14502 für die dritte und so weiter.

Anderer Host

Es kann sein, dass der Host nicht, wie üblich localhost ist sondern 127.0.0.1

Login auf phpmyadmin

Es kann sein, dass der Login die Angabe des Ports & Hosts erfordert.

Zugangsdaten bei Erstinstallation

In einigen Fällen muss oben beim Host nicht localhost rein sondern die 127.0.0.1 gefolgt von einem Doppelpunkt und dem korrekten Port.

Das könnte dann so aussehen: 127.0.0.1:14500

Zurück zur Übersicht

9. Praxis-Tipps & Geheimwissen

Tipps

• Überprüfe die Konfiguration nach jedem Datenbank-Update.
• Stimme Parameteranpassungen bei Managed Hosting mit dem Provider ab.
• Regelmäßige Backups und Monitoring der Datenbank-Performance sind Pflicht.

Geheimwissen

Maria DB verhindert größere Migrationen aus Shopware 5!
Wer aus einem Shopware 5 Shop mit einer MySQL 5 Datenbank zu Shopware 6 mighiert und viele Produkte im Shop hat, sollte von Beginn an auf auf MySQL setzen (s. Link im Forum).

group_concat_max_len muss kleiner sein als max_allowed_packet
Völlig belangloses Zusatzwissen, das außer dir niemand besitzt. Genauso wie di eInfos, dass der Maximalwert von group_concat_max_len abhängig davon ist, ob ein System mit 32 oder 64bit genutzt wird.

MySQL ist je nach Situation schneller als MySQL 8.4!
MySQL 8.0 ist tendenziell schneller, wenn klassische Festplatten (HDDs) oder ältere Hardware mit geringer I/O-Leistung verwendet werden und die Standardkonfiguration nicht angepasst wurde. In Benchmarks zeigt sich, dass 8.0 bei Schreibvorgängen (insbesondere mit den alten Standardwerten für InnoDB) teilweise bis zu 10 % schneller sein kann, da die konservativen Einstellungen weniger parallele Schreiboperationen erlauben und so auf älteren Systemen weniger Overhead erzeugen.

MySQL 8.4 ist dagegen auf moderner Hardware wie SSDs und RAID-Systemen meist schneller, da die Standardwerte für wichtige Parameter wie innodb_io_capacity (von 200 auf 10.000) und innodb_log_buffer_size (von 16 MB auf 64 MB) deutlich erhöht wurden. Das ermöglicht wesentlich mehr parallele Schreibvorgänge und eine bessere Ausnutzung der hohen I/O-Leistung moderner Systeme. Gerade bei schreibintensiven Workloads und großen Datenmengen kann 8.4 so einen deutlichen Performance-Vorteil bieten – vorausgesetzt, die Hardware ist entsprechend leistungsfähig und die Konfiguration nutzt die neuen Möglichkeiten aus.

• 8.0 ist schneller: auf älterer Hardware, klassischen Festplatten und mit den alten Standardwerten.
• 8.4 ist schneller: auf SSDs und RAID-Systemen mit hoher I/O-Leistung und optimal angepasster Konfiguration, besonders bei schreibintensiven Anwendungen.

In beiden Fällen gilt: Die tatsächliche Performance hängt stark von der Hardware, dem Workload und der individuellen Konfiguration ab. Wer maximale Geschwindigkeit will, sollte die Parameter gezielt an das eigene System anpassen und eigene Benchmarks durchführen.

Uhrzeit und Zeitzonen in MySQL können abweichen. In der Vergangenheit gab es teilweise Probleme damit, dass die Datenbank eine andere Uhrzeit hatte als der Shop bzw. PHP. Ob das bei euch der Fall ist, könnt ihr in phpMyAdmin mit diesem Befehl testen:

SELECT @@global.time_zone, @@session.time_zone, NOW(), UTC_TIMESTAMP();

Wenn die Werte bei @@global.time_zone und @@session.time_zone identisch sind, dann passt alles grundsätzlich zusammen und die Datenbank verwendet für alle Verbindungen dieselbe Zeitzone.

Hinweise & Korrektur bei Abweichungen

• @@global.time_zone: Standard-Zeitzone für neue Verbindungen.
• @@session.time_zone: Zeitzone der aktuellen Verbindung aus der DB (maßgeblich für Zeitstempel).
• NOW(): Aktuelle Zeit in der Session-Zeitzone.
• UTC_TIMESTAMP(): Aktuelle Zeit in UTC.

Sollten die Werte unterschiedlich sein, empfiehlt es sich, die MySQL-Zeitzone in der Konfiguration (my.cnf) mit default-time-zone = '+00:00' auf UTC zu setzen und den Server neu zu starten. Auch in PHP sollte die Zeitzone entsprechend mit date_default_timezone_set('UTC'); gesetzt werden, damit Shop und Datenbank synchron laufen.

So sieht es aus, wenn alles richtig ist:

2 – Datenbank Zeit Einstellungen

Zurück zur Übersicht

10. Fazit

Für einen performanten und zukunftssicheren Shop empfiehlt sich der Einsatz von MySQL ab Version 8. Die Vorteile zeigen sich besonders bei großen Katalogen, intensiver Nutzung von JSON-Feldern und modernen Shopware-Architekturen. MariaDB bleibt eine Alternative für kleinere Shops oder Legacy-Systeme, ist aber langfristig weniger geeignet.

Zurück zur Übersicht

11. Quellen

Offizielle Dokumentation & Fachartikel

• Shopware Documentation: Requirements
• Shopware Developer Docs: Database Cluster
• Shopware Forum: Shopware 6 – MariaDB vs. MySQL
• AWS: MariaDB vs MySQL
• Offizielle MariaDB Foundation Webseite
• Offizielle MySQL Webseite

12. Weiterführende Links

Empfohlene Ressourcen

• Why I don’t like Custom fields? (Shyim’s Blog)
• Wikipedia: Michael (Monty) Widenius
• group_concat_max_len
• max_allowed_packet
• sql_mode
• MySQL upgraden von 8.0 auf 8.4