Minecraft Server Datenbank-Optimierung: MySQL und SQLite richtig konfigurieren

# Minecraft Server Datenbank-Optimierung: MySQL und SQLite für maximale Performance

Wenn dein Minecraft-Server Plugins wie LuckPerms, EssentialsX, CoreProtect, ShopGUI+ oder ein Economy-Plugin verwendet — läuft auf deinem Server eine Datenbank. Und wenn diese Datenbank schlecht konfiguriert ist, kann sie deinen TPS still und leise reduzieren und Lag-Spikes verursachen, die nichts mit Entities oder Chunk-Loading zu tun haben.

Dieser Leitfaden erklärt, wie du MySQL und SQLite für Minecraft-Server richtig konfigurierst, wann du welches System wählen solltest und wie du maximale Performance aus deiner Datenschicht herausholst.

---

Warum Datenbank-Performance für Minecraft-Server wichtig ist

Die meisten Server-Admins konzentrieren sich auf Entity-Counts, View Distance und JVM-Flags — ignorieren die Datenbank aber völlig. Das ist ein Fehler:

• Plugins wie CoreProtect protokollieren jede Block-Interaktion. Auf einem belebten Server entstehen Tausende von Schreiboperationen pro Minute.
• LuckPerms, EssentialsX und CMI lesen und schreiben bei Join, Quit und im Gameplay ständig Spielerdaten.
• Langsame Datenbankabfragen laufen in vielen älteren Plugins synchron — sie blockieren den Haupt-Thread und senken direkt deinen TPS.
• Verbindungstimeouts oder falsch konfigurierte Pools lassen Plugins einfrieren, während sie auf eine Datenbankreaktion warten.

---

SQLite vs MySQL: Das richtige Backend wählen

SQLite

SQLite speichert alles in einer einzigen .db-Datei. Es erfordert keine Einrichtung und funktioniert sofort — deshalb ist es für die meisten Plugins der Standard.

Verwende SQLite wenn:

• Du einen kleinen Server mit unter 20 gleichzeitigen Spielern betreibst
• Du keine Multi-Server-Synchronisation benötigst
• Einfachheit wichtiger ist als rohe Performance

SQLite-Einschränkungen:

• Single-Writer-Architektur — nur ein Schreibvorgang gleichzeitig
• Performance verschlechtert sich bei großen Datensätzen (100k+ Zeilen)
• Nicht geeignet für BungeeCord/Velocity-Netzwerke

MySQL / MariaDB

MySQL ist eine vollständige Client-Server-Datenbank-Engine. MariaDB ist ein Community-Fork, der oft schneller und kompatibler mit Minecraft-Plugin-Treibern ist.

Verwende MySQL wenn:

• Du 20+ gleichzeitige Spieler hast
• Du ein Netzwerk mit mehreren Servern betreibst
• Plugins hohe Schreiblasten erzeugen (CoreProtect, LogBlock)
• Du bessere Performance bei gleichzeitigem Zugriff benötigst

> Empfehlung: Für jeden ernsthaften Server: Nutze MariaDB 10.6+ statt MySQL. Es bietet bessere Performance für die gemischten Lese-/Schreib-Workloads, die Minecraft-Plugins erzeugen.

---

MySQL für Minecraft-Plugins konfigurieren

Connection Pooling mit HikariCP

Viele moderne Plugins (LuckPerms, CoreProtect 22+, Plan) verwenden HikariCP für Connection Pooling. Das ist entscheidend für die Performance — ohne es öffnet und schließt jede Datenbankoperation eine neue Verbindung, was extrem langsam ist.

In LuckPerms (config.yml):

storage-method: mysql

data:
  address: localhost:3306
  database: luckperms
  username: luckperms_user
  password: deinpasswort
  pool-settings:
    maximum-pool-size: 10
    minimum-idle: 10
    maximum-lifetime: 1800000
    keepalive-time: 0
    connection-timeout: 5000

Wichtige Einstellungen erklärt:

• maximum-pool-size: Anzahl simultaner Verbindungen. Für die meisten Server reichen 10. Erhöhe auf 20 bei stark frequentierten Netzwerken.
• maximum-lifetime: Verbindungen nach 30 Minuten schließen und neu öffnen, um veraltete Verbindungen zu vermeiden.
• connection-timeout: Wenn innerhalb von 5 Sekunden keine Verbindung verfügbar ist, Fehler werfen statt unbegrenzt zu warten.

MySQL-Server-Konfiguration

Wenn du MariaDB selbst hostest, bearbeite /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
innodb_buffer_pool_size = 256M
innodb_log_file_size = 64M
innodb_flush_log_at_trx_commit = 2
max_connections = 150
query_cache_type = 0
query_cache_size = 0

• innodb_buffer_pool_size: Cache für häufig aufgerufene Daten. Setze auf 25-50% des verfügbaren RAMs bei dedizierten Datenbankservern.
• innodb_flush_log_at_trx_commit = 2: Schreibt jede Sekunde auf die Festplatte statt bei jeder Transaktion. Deutlich schneller bei minimalem Datenverlustrisiko.
• query_cache_size = 0: Der Query-Cache ist in modernem MySQL/MariaDB veraltet und verursacht Konflikte. Deaktivieren.

---

Spezifische Plugins optimieren

CoreProtect

CoreProtect ist eines der datenbankintensivsten Plugins überhaupt. Auf aktiven Survival-Servern kann es täglich Millionen von Zeilen erzeugen.

In config.yml:

mysql: true
host: localhost
port: 3306
database: coreprotect
username: coreprotect_user
prefix: co_
world-edit: true

Performance-Tipps:

• Führe monatlich co purge t:30d aus, um Logs älter als 30 Tage zu löschen
• Verwende MySQL statt SQLite — der Unterschied ist auf belebten Servern enorm
• Erwäge CoreProtect auf einer separaten MariaDB-Instanz zu betreiben bei sehr hohem Traffic

EssentialsX

Essentials speichert Spielerdaten standardmäßig als individuelle YAML-Dateien, was dank Dateisystem-Caching für kleine Server sogar schneller als eine Datenbank sein kann. Bei Servern mit 10.000+ einzigartigen Spielern wird der /userdata/-Ordner jedoch riesig.

Für große Server: Wechsel zu EssentialsX mit H2 oder migriere zu CMI mit effizientererem Storage-Backend.

Plan (Player Analytics)

Plan ist bekannt für hohe Datenbankbelastung. In config.yml:

Database:
  Type: MySQL
  MySQL:
    Host: localhost
    Port: 3306
    User: plan_user
    Password: deinpasswort
    Database: plan
    Max_connections: 8
    Launch_options: "?rewriteBatchedStatements=true&useSSL=false"

Die Option rewriteBatchedStatements=true ist entscheidend — sie bündelt mehrere INSERT-Statements zu einem einzigen Netzwerkaufruf und reduziert den Schreib-Overhead drastisch.

---

Datenbank-Lag diagnostizieren

Nicht sicher, ob deine Datenbank der Engpass ist? So findest du es heraus:

1. Nutze /timings report (Paper/Spigot) oder /spark — suche nach Plugin-Tasks, die mehr als 1ms benötigen. Datenbank-Plugins erscheinen oft als AsyncPlayerPreLoginEvent oder geplante Tasks.

1. Aktiviere Slow Query Logging in MariaDB:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5

Das protokolliert alle Abfragen, die länger als 500ms dauern — eine häufige Quelle versteckter Lags.

1. Überwache Connection Pool Exhaustion — wenn deine Plugin-Logs connection timeout-Fehler zeigen, erhöhe maximum-pool-size.

Tools wie PulseNode helfen dir, TPS-Einbrüche mit Plugin-Aktivität über Zeit zu korrelieren — so erkennst du schnell, ob ein datenbankintensives Plugin periodisch Lag-Spikes in Stoßzeiten verursacht.

---

Schnell-Checkliste: Datenbank-Optimierung

• [ ] Von SQLite auf MySQL/MariaDB wechseln bei 20+ Spielern
• [ ] MariaDB 10.6+ statt MySQL für bessere Performance verwenden
• [ ] HikariCP Connection Pooling in allen unterstützten Plugins aktivieren
• [ ] innodb_flush_log_at_trx_commit = 2 in der MariaDB-Konfiguration setzen
• [ ] MySQL Query Cache deaktivieren
• [ ] rewriteBatchedStatements=true zu JDBC-Connection-Strings hinzufügen
• [ ] Regelmäßige CoreProtect-Bereinigungen planen
• [ ] Slow Query Logging aktivieren
• [ ] Datenbank auf derselben physischen Maschine oder im selben LAN halten

---

Fazit

Datenbank-Performance ist einer der am meisten übersehenen Aspekte der Minecraft-Server-Optimierung — und doch ist sie oft für mysteriöse Lag-Spikes verantwortlich, die in Entity- oder Chunk-Profiling nicht auftauchen. Durch den Wechsel zu MariaDB, korrekte Connection-Pool-Konfiguration und saubere Plugin-Daten kannst du eine ganze Kategorie von Server-Lag eliminieren.

Wenn du überwachen möchtest, wie deine datenbankintensiven Plugins den TPS im Zeitverlauf beeinflussen, bietet PulseNode ein Echtzeit-Performance-Monitoring, das dir genau zeigt, wann und warum dein Server langsamer wird — ganz ohne Ratespiele.