Die Leistung einer Datenbank ents­chei­det oft maß­ge­blich über die Ges­chwin­dig­keit und Sta­bi­lität von We­banwen­dun­gen. MariaDB und MySQL bieten zahl­rei­che Mö­gli­ch­kei­ten zur Op­ti­mi­e­rung: Von Kon­fi­gu­ra­tion über Indizes bis hin zu Caching und Re­pli­ka­tion. Mit gezielten Maßnahmen lassen sich die Da­ten­ban­kres­sour­cen ef­fi­zi­en­ter nutzen und die Antwort­zei­ten für Abfragen deutlich re­du­zi­e­ren.

Wieso sollte man MariaDB und MySQL op­ti­mi­e­ren?

Die Op­ti­mi­e­rung von MariaDB und MySQL ist sinnvoll, weil unop­ti­mi­erte Da­ten­ban­ken schnell an ihre Grenzen stoßen. Eine schlechte Per­for­mance kann zu langen La­de­zei­ten, Timeouts oder sogar Sys­te­mausfäl­len führen.

Gerade bei großen Da­ten­men­gen oder vielen glei­ch­zei­ti­gen Zugriffen belastet jede inef­fi­zi­ente Abfrage CPU und RAM. Auch das Speichern von re­dun­dan­ten Daten oder fehlende Indizes wirken sich negativ auf die Ges­chwin­dig­keit aus. Eine op­ti­mi­erte Datenbank reduziert die Sys­tem­last, ver­bes­sert die Ska­li­er­bar­keit und sorgt dafür, dass Anwen­dun­gen auch unter hoher Last stabil laufen.

Wie kann man MySQL/MariaDB op­ti­mi­e­ren?

Es gibt viele Mö­gli­ch­kei­ten, eine MariaDB- oder MySQL-Datenbank auf einem Linux-Server zu op­ti­mi­e­ren. Dazu gehören An­pas­sun­gen an der Kon­fi­gu­ra­tion, Index-Op­ti­mi­e­rung, Ver­bes­se­rung der Abfragen, Tuning von InnoDB und die Nutzung von Caching oder Re­pli­ka­tion. Im Folgenden werden die wi­ch­tigs­ten Maßnahmen vor­ges­tellt.

Mö­gli­ch­keit 1: Langsame Anfragen iden­ti­fi­zi­e­ren

Ein Teil des Prozesses zur Op­ti­mi­e­rung von MySQL/MariaDB ist die Über­prü­fung auf langsame oder inef­fi­zi­ente Abfragen. Eine schlecht struk­tu­ri­erte MySQL/MariaDB-Abfrage kann die gesamte Datenbank ver­lang­sa­men.

MySQL/MariaDB kann kon­fi­gu­ri­ert werden, um jede Abfrage zu pro­to­kol­li­e­ren, die länger als die an­ge­ge­bene Anzahl von Sekunden dauert. Auf diese Weise können Sie alle langsamen Anfragen verfolgen und bei Bedarf kor­ri­gi­e­ren.

Um die Pro­to­kol­li­e­rung langsamer Abfragen zu ak­ti­vi­e­ren, melden Sie sich bei MySQL/MariaDB an:

mysql -u root -p

Geben Sie den folgenden Befehl ein, um die Pro­to­kol­li­e­rung zu ak­ti­vi­e­ren:

SET GLOBAL slow_query_log = 'ON';

Der vo­rein­ges­tellte Schwel­lenwert beträgt 10 Sekunden. Verwenden Sie den folgenden Befehl, um die Pro­to­kol­li­e­rung für jede Abfrage zu ak­ti­vi­e­ren, die länger als 1 Sekunde dauert:

SET GLOBAL long_query_time = 1;

Abfragen, die länger als 1 Sekunde dauern, werden unter /var/lib/mysql/hostname-slow.log pro­to­kol­li­ert.

Auch Mo­ni­to­ring-Tools wie mysqltuner oder performance_schema können genutzt werden und liefern wertvolle Hinweise, um zu erkennen, welche Abfragen optimiert werden können.

Mö­gli­ch­keit 2: InnoDB-Kon­fi­gu­ra­tion anpassen

Die Kon­fi­gu­ra­tion von MariaDB/MySQL ist eine der wir­kungs­volls­ten Methoden, um die Per­for­mance einer Datenbank na­chhal­tig zu ver­bes­sern. Viele Stan­dar­dins­tal­la­ti­o­nen nutzen ge­ne­ris­che Werte, die für kleinere Tes­tum­ge­bun­gen ausgelegt sind, aber nicht für pro­duk­tive Systeme mit vielen Abfragen. Durch das gezielte Anpassen von InnoDB-Pa­ra­me­tern kann die Datenbank Res­sour­cen ef­fi­zi­en­ter nutzen.

Wichtige Parameter sind unter anderem:

  • innodb_flush_log_at_trx_commit: Diese Eins­tel­lung bietet einen erhe­bli­chen Kom­pro­miss zwischen Leistung und Zu­verläs­sig­keit. Stan­dardmäßig steht der Wert auf 1, was bedeutet, dass jede Tran­sak­tion sofort auf die Fest­platte ges­ch­ri­e­ben wird. Das ga­ran­ti­ert maximale Si­cherheit, kann jedoch die Per­for­mance bei hoher Tran­sak­ti­ons­last stark re­du­zi­e­ren. Ein Wert von 2 reduziert I/O-Ope­ra­ti­o­nen erheblich, während ein geringes Risiko von Da­ten­ver­lust bei einem Absturz besteht.
  • innodb_log_file_size: Die Größe der InnoDB-Log­da­teien hat direkten Einfluss auf die Ges­chwin­dig­keit von Sch­rei­bo­pe­ra­ti­o­nen. Größere Logfiles bedeuten, dass mehr Tran­sak­ti­o­nen im Speicher gesammelt werden können, bevor sie auf die Fest­platte ges­ch­ri­e­ben werden.
  • innodb_file_per_table: Mit dieser Option wird für jede InnoDB-Tabelle eine eigene Ta­bles­pace-Datei erstellt. Das hat mehrere Vorteile: Es er­lei­ch­tert das Ma­na­ge­ment großer Tabellen, reduziert Frag­men­ti­e­rung innerhalb des ge­mein­sa­men Ta­bles­pa­ces und kann die Per­for­mance bei Backups ver­bes­sern.
  • innodb_buffer_pool_size: Dieser Wert sollte ty­pis­cherweise 50–80 % des verfüg­ba­ren RAMs ausmachen, um möglichst viele Daten und Indizes im Speicher zu halten.
  • innodb_flush_method: Diese Option legt fest, wie InnoDB Daten und Logs auf die Fest­platte schreibt. Setzen Sie diesen Wert auf O_DIRECT, um eine doppelte Pufferung der Daten zu vermeiden.

Um die InnoDB-Eins­tel­lun­gen zu ändern, öffnen Sie die Datei my.cnf zur Be­ar­bei­tung. Eine exem­pla­ris­che Kon­fi­gu­ra­tion in my.cnf könnte dann beis­pi­elsweise so aussehen:

[mysqld]
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 512M
innodb_file_per_table = 1
innodb_buffer_pool_size = 1G
innodb_flush_method = O_DIRECT

Starten Sie MariaDB/MySQL neu, damit die Än­de­run­gen wirksam werden.

Mö­gli­ch­keit 3: Indizes anpassen

Indizes sind es­sen­zi­ell, um die Per­for­mance von MySQL- oder MariaDB-Abfragen zu ver­bes­sern. Statt jede Zeile einer Tabelle zu dur­ch­su­chen, kann die Datenbank mithilfe des Index direkt zu den re­le­van­ten Einträgen springen.

Al­ler­dings gilt: Zu viele oder falsche Indizes können kon­tra­pro­duk­tiv sein. Jeder zusätz­li­che Index benötigt Spei­cher­platz. Daher ist es wichtig, nur die Spalten zu in­de­xi­e­ren, die tatsä­ch­lich häufig verwendet werden.

Ein einfaches Beispiel: An­ge­nom­men, wir haben eine Tabelle users und suchen oft nach der Spalte email. Dann kann ein Index die Abfragen erheblich bes­ch­leu­ni­gen:

CREATE INDEX idx_user_email ON users(email);

Mit diesem Index werden Abfragen wie

SELECT * FROM users WHERE email='xyz@example.com';

deutlich schneller aus­geführt, weil die Datenbank nicht jede Zeile der Tabelle dur­ch­su­chen muss, sondern direkt auf die passenden Einträge zugreift.

Zusätz­lich können kom­bi­ni­erte Indizes sinnvoll sein, wenn mehrere Spalten zusammen häufig in Abfragen verwendet werden.

Re­gelmäßig sollten auch nicht mehr benötigte oder selten genutzte Indizes entfernt werden, um Speicher zu sparen und die Sch­reib­per­for­mance zu ver­bes­sern. Im Beispiel wird der Index idx_old_column gelöscht:

DROP INDEX idx_old_column ON users;

Mö­gli­ch­keit 4: Abfragen op­ti­mi­e­ren

Komplexe oder inef­fi­zi­ente SQL-Abfragen können die Datenbank stark belasten und die Per­for­mance vers­ch­le­ch­tern, ins­be­son­dere bei großen Tabellen. Um Abfragen zu op­ti­mi­e­ren, sollten Sie zunächst prüfen, wie die Datenbank die Abfrage ausführt. Dazu eignet sich der Befehl EXPLAIN.

EXPLAIN SELECT id, email FROM users WHERE status='active';

Mit EXPLAIN zeigt MySQL/MariaDB, welche Indizes verwendet werden, wie viele Zeilen gelesen werden müssen und in welcher Reihen­folge Tabellen ve­rar­bei­tet werden. So können Sie erkennen, ob die Abfrage effizient ist oder ob zusätz­li­che Op­ti­mi­e­run­gen sinnvoll sind, z. B. das Hin­zufü­gen von Indizes oder das Anpassen von Joins.

Vermeiden Sie zudem Abfragen der Form SELECT *, da dabei viele Spalten geladen werden, die nicht benötigt werden. Statt­des­sen sollten Sie nur die Spalten abfragen, die wirklich gebraucht werden. Das reduziert die Menge an über­tra­ge­nen Daten und ver­bes­sert die Ges­chwin­dig­keit der Abfrage. Bei komplexen Joins lohnt es sich, die Be­din­gun­gen in der WHERE-Klausel so präzise wie möglich zu for­mu­li­e­ren, um unnötige Scans der gesamten Tabelle zu verhin­dern.

Cloud Compute Engine da IONOS

Empresas de médio e grande porte optam pela nuvem da Alemanha. Serviços IaaS e PaaS são para campeões.

  • Seguro
  • Confiável
  • Flexível

Mö­gli­ch­keit 5: Re­pli­ka­tion und Caching

Auch Re­pli­ka­tion, also das Verteilen der Last auf mehrere Server, sowie Caching, um die Anzahl der direkten Da­ten­bank­zu­griffe zu re­du­zi­e­ren, können dabei helfen, MariaDB/MySQL zu op­ti­mi­e­ren.

Bei der Re­pli­ka­tion wird in der Regel das so­ge­nannte Master-Slave-Prinzip ein­ge­setzt: Der Master-Server ve­rar­bei­tet alle Sch­rei­bo­pe­ra­ti­o­nen, während ein oder mehrere Slave-Server die Daten re­pli­zi­e­ren und Le­se­ab­fra­gen über­neh­men. So kann die Datenbank hohe Last ef­fi­zi­en­ter bewäl­ti­gen, ohne dass der Master-Server über­las­tet wird. Kon­fi­gu­ra­tion und Ein­ri­ch­tung der Re­pli­ka­tion erfordern zwar initial Aufwand, bringen aber gerade bei stark genutzten Anwen­dun­gen eine Ver­bes­se­rung der Per­for­mance.

Zusätz­lich kann auch Caching die Antwort­zei­ten deutlich ver­bes­sern. MySQL/MariaDB bietet dazu den Query Cache, der Er­geb­nisse häufig wi­e­derhol­ter Abfragen zwis­chens­pei­chert. Dadurch müssen dieselben Abfragen nicht erneut aus­geführt werden. Mit folgenden Eins­tel­lun­gen können Sie die Größe des Caches festlegen und den Query-Cache ak­ti­vi­e­ren:

SET GLOBAL query_cache_size = 64*1024*1024;
SET GLOBAL query_cache_type = 1;

Für moderne Anwen­dun­gen ist es außerdem sinnvoll, externe Caching-Lösungen wie Redis zu nutzen, die noch schneller auf häufig benötigte Daten zugreifen können.

Mö­gli­ch­keit 6: Par­ti­ti­o­ni­e­rung von Tabellen

Bei sehr großen Tabellen kann die Ve­rar­bei­tung von Abfragen länger dauern, weil die Datenbank jede Zeile dur­ch­su­chen muss. Mit Par­ti­ti­o­ni­e­rung lassen sich Tabellen in kleinere, logisch getrennte Teile un­ter­tei­len, z. B. nach Datum, ID-Bereich oder anderen Kriterien. Jede Partition wird intern wie eine separate Tabelle behandelt, sodass Abfragen, die nur bestimmte Par­ti­ti­o­nen betreffen, deutlich schneller aus­geführt werden können.

Ein Beispiel für eine Par­ti­ti­o­ni­e­rung nach Jahr bei einer Bestell-Tabelle könnte so aussehen:

CREATE TABLE orders (
id INT,
order_date DATE,
amount DECIMAL(10,2)
)
PARTITION BY RANGE (YEAR(order_date)) (
PARTITION p2023 VALUES LESS THAN (2024),
PARTITION p2024 VALUES LESS THAN (2025)
);

In diesem Fall werden alle Bes­tel­lun­gen aus 2023 in der Partition p2023 und alle Bes­tel­lun­gen aus 2024 in p2024 abgelegt.

Mö­gli­ch­keit 7: Ver­bin­dungs­po­o­ling nutzen

Jede neue Ver­bin­dung zu MySQL/MariaDB benötigt Zeit und Res­sour­cen. Wenn Ihre Anwendung bei jeder Anfrage eine Ver­bin­dung auf- und wieder abbaut, entsteht dadurch eine unnötige Last auf dem Server. Das so­ge­nannte Ver­bin­dungs­po­o­ling kann genutzt werden, um MariaDB und MySQL zu op­ti­mi­e­ren, und löst dieses Problem, indem eine bestimmte Anzahl von Da­ten­bank­ver­bin­dun­gen dauerhaft geöffnet bleibt. Anwen­dun­gen greifen dann immer wieder auf diese bes­tehen­den Ver­bin­dun­gen zurück, anstatt neue auf­zu­bauen.

Ein Beispiel in PHP mit mysqli sieht so aus:

$mysqli = new mysqli('localhost', 'user', 'password', 'db');
$mysqli->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
php

Anstatt für jeden Request eine komplett neue Ver­bin­dung zu öffnen, nutzt der Pool die bereits bes­tehen­den Ver­bin­dun­gen. Das führt zu sch­nel­le­ren Re­ak­ti­ons­zei­ten und entlastet glei­ch­zei­tig den Da­ten­bank­ser­ver.

Ir para o menu principal