Webhosting 3 Min Lesezeit

MySQL & MariaDB optimieren – Performance-Guide 2026

Grundlagen der MySQL- und MariaDB-Architektur verstehen

MySQL und MariaDB basieren auf einer mehrschichtigen Architektur, die aus dem Connection Layer, dem SQL Layer und dem Storage Engine Layer besteht. Das Verständnis dieser Schichten ist entscheidend, um Performance-Probleme gezielt zu diagnostizieren und zu beheben. Der SQL Layer verarbeitet die eingehenden Queries, optimiert sie und leitet sie an die Storage Engine weiter.

Die Standard-Storage-Engine InnoDB hat sich in beiden Datenbanksystemen durchgesetzt, da sie ACID-Konformität, Transaktionssicherheit und Row-Level-Locking bietet. Im Gegensatz zur älteren MyISAM-Engine unterstützt InnoDB Foreign Keys, MVCC und Crash Recovery. Für die meisten Anwendungsfälle ist InnoDB die richtige Wahl.

MariaDB bringt einige zusätzliche Storage Engines mit, darunter ColumnStore für analytische Workloads und Spider für verteilte Datenbanken. Diese Erweiterungen machen MariaDB besonders attraktiv für hybride Szenarien, in denen transaktionale und analytische Anfragen auf derselben Datenbank laufen.

Der Query Optimizer analysiert eingehende SQL-Statements und wählt den effizientesten Ausführungsplan aus. Dazu nutzt er Statistiken über die Datenverteilung, die in den Tabellen gespeichert sind. Veraltete Statistiken führen häufig zu suboptimalen Ausführungsplänen, weshalb ein regelmäßiges ANALYZE TABLE empfehlenswert ist.

InnoDB-Tuning: Buffer Pool und I/O-Optimierung

Der InnoDB Buffer Pool ist der wichtigste Performance-Hebel überhaupt, da er die Datenseiten im Speicher hält und somit Festplattenzugriffe minimiert. Die Faustregel lautet, den Buffer Pool auf 70-80% des verfügbaren RAMs zu konfigurieren. Bei einem dedizierten Datenbankserver mit 64 GB RAM sollten also etwa 50 GB für den Buffer Pool reserviert werden.

# my.cnf Konfiguration für InnoDB
[mysqld]
innodb_buffer_pool_size = 50G
innodb_buffer_pool_instances = 16
innodb_log_file_size = 4G
innodb_log_buffer_size = 256M
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

Die Anzahl der Buffer Pool Instances sollte der Anzahl der CPU-Kerne entsprechen, um Lock-Contention zu vermeiden. Bei einem 16-Kern-System sind 16 Instances optimal. Jede Instance verwaltet ihren eigenen Free List und LRU-Mechanismus, was die Parallelität deutlich erhöht.

Das innodb_flush_log_at_trx_commit-Verhalten hat erhebliche Auswirkungen auf die Performance. Der Wert 1 bietet maximale Sicherheit (ACID-Konformität), flusht aber bei jeder Transaktion auf die Festplatte. Der Wert 2 flusht nur einmal pro Sekunde und ist ein guter Kompromiss für die meisten Anwendungen, da Daten höchstens eine Sekunde verloren gehen können.

Die I/O-Konfiguration mit O_DIRECT umgeht das OS-Cache und verhindert doppeltes Caching. Auf Linux-Systemen mit modernen NVMe-SSDs ist dies die empfohlene Einstellung. Die innodb_io_capacity sollte an die tatsächliche Disk-Performance angepasst werden, was sich mit Tools wie fio messen lässt.

Index-Strategien für maximale Query-Performance

Indizes sind der Schlüssel zu schnellen Queries, können aber bei falscher Anwendung auch zum Performance-Killer werden. Ein gut konzipierter Index kann die Performance einer Query um den Faktor 1000 verbessern, während ein schlechter Index Schreiboperationen verlangsamt und Speicherplatz verschwendet.

Der B-Tree-Index ist der Standard für die meisten Anwendungsfälle und wird automatisch für PRIMARY KEY und UNIQUE Constraints erstellt. Bei zusammengesetzten Indizes ist die Reihenfolge der Spalten entscheidend: Spalten mit hoher Selektivität sollten zuerst kommen, gefolgt von Spalten, die in ORDER BY oder GROUP BY verwendet werden.

Index-TypAnwendungsfallVorteilNachteil
B-TreeGleichheits- und BereichsabfragenUniversell einsetzbarGroßer Speicherbedarf
HashNur GleichheitsabfragenSehr schnellKeine Range-Queries
FulltextVolltextsucheRelevanz-SortierungBegrenzte Sprachen
CompositeMehrspaltige WHERE-KlauselnCovering Index möglichReihenfolge kritisch
DescendingORDER BY DESCOptimierte SortierungMySQL 8.0+ benötigt

Covering Indizes enthalten alle Spalten, die eine Query benötigt, sodass die Datenseiten nicht aus der Tabelle geladen werden müssen. Dies ist besonders effektiv für SELECT-Statements, die nur wenige Spalten aus einer großen Tabelle abrufen. EXPLAIN zeigt an, ob ein Index als "Using index" markiert ist.

Überflüssige Indizes sind eine häufige Ursache für langsame Schreiboperationen. Jeder Index muss bei INSERT, UPDATE und DELETE aktualisiert werden. Das Tool pt-duplicate-key-checker von Percona identifiziert redundante Indizes und schlägt Optimierungen vor. Eine regelmäßige Index-Analyse gehört zum Pflichtprogramm jedes DBAs.

Query-Optimierung mit EXPLAIN und Performance Schema

Das EXPLAIN-Statement ist das wichtigste Werkzeug zur Query-Analyse. Es zeigt den vom Optimizer gewählten Ausführungsplan, einschließlich der verwendeten Indizes, der Join-Reihenfolge und der geschätzten Zeilenzahlen. In MySQL 8.0 und MariaDB 10.6 liefert EXPLAIN FORMAT=JSON oder EXPLAIN ANALYZE noch detailliertere Informationen.

Warnzeichen in EXPLAIN sind full table scans (type: ALL), temporäre Tabellen (Extra: Using temporary) und filesort-Operationen (Extra: Using filesort). Diese deuten auf fehlende oder ungeeignete Indizes hin. Die geschätzte Zeilenzahl in der rows-Spalte sollte mit der tatsächlichen Zeilenzahl übereinstimmen, andernfalls sind veraltete Statistiken die Ursache.

# EXPLAIN einer komplexen Query
EXPLAIN ANALYZE
SELECT u.username, COUNT(o.id) AS order_count, SUM(o.total) AS total_spent
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at >= '2025-01-01'
  AND u.status = 'active'
GROUP BY u.id
ORDER BY total_spent DESC
LIMIT 100;

-- Ergebnis analysieren
-> Limit: 100 row(s)  
  -> Sort: total_spent DESC
    -> Stream results
      -> Group aggregate
        -> Index range scan on u using idx_created_status
          -> Nested loop left join
            -> Index lookup on o using idx_user_id

Das Performance Schema ist seit MySQL 5.5 verfügbar und bietet detaillierte Einblicke in die Datenbankaktivität. Mit der events_statements_summary_by_digest-Tabelle lassen sich die zeitintensivsten Queries identifizieren. Das sys-Schema, das auf dem Performance Schema aufbaut, stellt komfortable Views bereit, die komplexe Abfragen vereinfachen.

Slow Query Logs sind eine weitere wichtige Diagnosequelle. Die Konfiguration erfolgt über slow_query_log, long_query_time (in Sekunden) und log_slow_extra. Percona Toolkit bietet mit pt-query-digest ein leistungsfähiges Tool zur Aggregation und Analyse der Slow Logs, das die problematischsten Queries schnell identifiziert.

Schreiboptimierung: Bulk-Inserts und Replication

Schreiboperationen sind häufig der Engpass in datenintensiven Anwendungen. Bulk-Inserts sind wesentlich schneller als einzelne INSERT-Statements, da sie den Overhead pro Zeile reduzieren. Mit LOAD DATA INFILE lassen sich Millionen von Zeilen in wenigen Sekunden importieren, vorausgesetzt die Tabelle ist richtig vorbereitet.

Während eines Bulk-Imports sollten alle nicht benötigten Indizes deaktiviert werden, da jeder Index aktualisiert werden muss. AUTO_INCREMENT-Spalten beschleunigen den Import, da der Wert nicht aus dem Index abgerufen werden muss. Die Konfiguration von innodb_autoinc_lock_mode auf 2 (interleaved) ist für die meisten Anwendungen optimal.

# Bulk-Import mit LOAD DATA INFILE
LOAD DATA INFILE '/tmp/users.csv'
INTO TABLE users
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '
'
IGNORE 1 ROWS
(username, email, created_at);

# Alternative mit INSERT ... VALUES
INSERT INTO users (username, email, created_at) VALUES
('user1', '[email protected]', NOW()),
('user2', '[email protected]', NOW()),
('user3', '[email protected]', NOW());

Für kontinuierlich hohe Schreiblasten ist die asynchrone Replication ein bewährtes Mittel zur Lastverteilung. Writes gehen an den Master, Reads an einen oder mehrere Slaves. MariaDB bietet zusätzlich die Galera-Cluster-Technologie für synchrone Multi-Master-Replication, die bei Bedarf auch Writes auf

Hugo vs. Astro – Static Site Generator Hosting Vergleich 2026
Webhosting 06. June 2026 14 Min

Hugo vs. Astro – Static Site Generator Hosting Vergleich 2026

Hugo vs. Astro: Der große Static-Site-Generator-Vergleich 2026 ✓ Performance, Hosting, Lernkurve, Deployment & Use Cases. Welcher SSG passt zu dir?

Weiterlesen →

📖 Ähnliche Artikel