Hervorragende Software und praktische Tutorials
Handbuch zur Optimierung der MySQL-Schreibleistung in CyberPanel
Bei der Verwendung von CyberPanel kann es zu langsamen MySQL-Schreibvorgängen kommen. Normalerweise treten bei Datenbankschreibvorgängen keine Auffälligkeiten auf, aber wenn der Website-Verkehr zunimmt, wird die Datenbank sehr langsam.
Zu diesem Zeitpunkt werden Sie feststellen, dass CPU und Speicher noch im Leerlauf sind, weniger als 30% belegt sind und auch überschüssige Bandbreite vorhanden ist. Warum wird das Schreiben in die Datenbank langsam?
Die standardmäßig installierte Datenbank ist nicht optimiert. Sehen wir uns an, wie man die MySQL-Datenbank optimiert.
Die Optimierung der MySQL-Schreibleistung umfasst die Anpassung von Hardware, Konfiguration, Abfragedesign und Überwachung. Je nach tatsächlicher Arbeitslast (z. B. hohe Anzahl gleichzeitiger Schreibvorgänge) kann die Leistung durch die Optimierung um das Zwei- bis Zehnfache verbessert werden.
So optimieren Sie MySQL in CyberPanel:
Installieren Sie zunächst das Überwachungstool: sudo apt install mysql-tuner-perl und führen Sie perl mysql-tuner.pl aus, um vorläufige Vorschläge zu erhalten, z. B. die Erhöhung von innodb_buffer_pool_size.
Öffnen Sie die Datenbankkonfigurationsdatei
vi /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld] bind-address = 127.0.0.1 # Lokal binden, um Remote-Missbrauch zu vermeiden default_storage_engine = InnoDB # Standard-InnoDB (unterstützt Transaktionen) character-set-server = utf8mb4 # Emoji-Unterstützung collation-server = utf8mb4_unicode_ci
Wenn es nicht in der Konfigurationsdatei ist, fügen Sie es in [mysqld] hinzu.
Optimieren Sie den InnoDB-Pufferpool. Schreibengpässe treten häufig im InnoDB-Protokoll, im Puffer und bei Sperren auf. Passen Sie die Änderungen schrittweise an und überwachen Sie sie.
Setzen Sie innodb_buffer_pool_size = 70% System-RAM
innodb_buffer_pool_size = 44G innodb_buffer_pool_instances = 8 # Mehrere Instanzen reduzieren Sperrkonflikte
In leistungsstarken Webanwendungen schöpft MariaDB (MySQL-kompatibel) als Datenbank-Engine in der Standardkonfiguration das Potenzial des Servers oft nicht voll aus. Beispielsweise beträgt der standardmäßige InnoDB-Pufferpool bei 64 GB RAM nur 128 MB, weit weniger als die empfohlenen 701 TP3T RAM (ca. 45 GB). Dies kann zu häufigen Festplatten-E/A-Vorgängen, Abfragelatenz und Schreibengpässen führen. Laut dem offiziellen Benchmark von MariaDB und dem Percona-Bericht aus dem Jahr 2025 beträgt die TPS (Transaktionen pro Sekunde) mit einer nicht optimierten Konfiguration in der Spitze nur 301 TP3T. Mit Optimierung kann sich dieser Wert jedoch um das 4- bis 8-fache erhöhen, insbesondere in Szenarien mit hoher Parallelität wie E-Commerce oder CMS.
Die MySQL-Optimierung in CyberPanel ist kein einmaliger Aufwand, sondern ein iterativer Prozess. Beginnen Sie mit der Grundkonfiguration und kombinieren Sie diese mit Dashboard-Tools und Monitoring. So können Sie die Leistung deutlich verbessern und häufige Engpässe vermeiden. Denken Sie daran, nach der Optimierung die Auslastung zu testen (z. B. mit JMeter-Simulationen) und MySQL-Tuner regelmäßig auszuführen. Bis 2025 wird die CyberPanel-Integration mit dem Aufkommen KI-gestützter Datenbanktools noch intelligenter, manuelles Tuning bleibt jedoch die Grundlage. Nach der Optimierung wird Ihre Website effizienter und trägt zum Unternehmenswachstum bei.
Optimierung der Erstellung temporärer MySQL-Tabellendatenträger: Eine praktische Anleitung zur Reduzierung des Schwellenwerts von 46% auf 25%
Bei der MySQL-Leistungsoptimierung wirkt sich der Speicherort der temporären Tabellen direkt auf die Abfrageeffizienz und den Ressourcenverbrauch aus. Ihre aktuelle Situation zeigt Created_tmp_disk_tables / (Created_tmp_tables + Created_tmp_disk_tables) * 100 = 46% und überschreitet damit den empfohlenen Schwellenwert von 25% bei weitem. Das bedeutet, dass fast die Hälfte dieser temporären Tabellen auf der Festplatte und nicht im Arbeitsspeicher gespeichert ist, was zu einem Anstieg des E/A-Overheads, einer Verdoppelung der Abfragelatenz und sogar zu Engpässen bei hoher Parallelität führt. Basierend auf der Formel (Wert > 25) löst dies Warnungen in Tools wie mysql-tuner aus. Temporäre Tabellen werden häufig in GROUP BY-, ORDER BY- oder DISTINCT-Vorgängen verwendet. Wenn der Arbeitsspeicher nicht ausreicht, wechselt MySQL automatisch zur Festplatte (MyISAM-Engine). Dies sollte auf einem Server mit 64 GB RAM nicht passieren, kann aber auf eine suboptimale Konfiguration oder Probleme beim Abfragedesign hinweisen.
Passen Sie zunächst die Parameter gleichzeitig an – setzen Sie max_heap_table_size = tmp_table_size = 1024 MB (belegt 1,61 TP3T RAM) – indem Sie diese Zeile zum Abschnitt [mysqld] von my.cnf hinzufügen, MariaDB neu starten und testen. Überwachen Sie SHOW GLOBAL STATUS LIKE 'Created_tmp%'; mit dem Ziel, es auf < 251 TP3T zu reduzieren. Wenn dies nicht funktioniert, schreiben Sie die Abfrage neu: Analysieren Sie langsames SQL mit EXPLAIN, teilen Sie BLOB-Felder in externen Speicher auf oder aktivieren Sie das Abfrage-Caching. Kombinieren Sie dies mit pt-query-digest des Percona Toolkits, um Protokolle zu analysieren und Optimierungen zu iterieren. Letztendlich wird nicht nur die Trefferrate des temporären Tabellenspeichers über 801 TP3T erreichen, sondern die Gesamtleistung wird um das 2- bis 4-fache verbessert, wodurch Ihre Datenbank von kaum überlebensfähig zu äußerst reaktionsfähig wird.
temporäre Tabellengröße = 1024 M maximale Heap-Tabellengröße = 1024 M
Optimierung der MySQL long_query_time-Einstellung: Eine Anleitung zur Reduzierung von 10 Sekunden auf 1–5 Sekunden
Bei der MySQL-Leistungsüberwachung definiert der Parameter „long_query_time“ den Schwellenwert für das Protokoll langsamer Abfragen: Abfragen, die diesen Wert überschreiten, werden zur späteren Analyse und Optimierung als „langsame Abfragen“ aufgezeichnet. Ihre aktuelle Einstellung (10 Sekunden oder länger) bedeutet, dass nur extrem langsame Abfragen (wie komplexe Verknüpfungen oder große Tabellenscans) erfasst werden, wodurch viele potenzielle Engpässe übersehen werden und Leistungsprobleme verborgen bleiben. Laut MySQL-Dokumentation und Best Practices von Percona ist der standardmäßige Schwellenwert von 10 Sekunden für Testumgebungen mit geringer Auslastung geeignet, für Produktionsserver (mit einem täglichen Abfragevolumen von >100.000) wird das Protokoll langsamer Abfragen jedoch zu spärlich, sodass Probleme wie fehlende Indizes oder Sperrkonflikte nicht rechtzeitig erkannt werden. Das Ergebnis ist eine geringfügige Erhöhung der Datenbankantwortzeit, eine verschlechterte Benutzererfahrung und eine Verringerung der TPS (Transaktionen pro Sekunde) um 20–50 %.
Aktuelle Analyse: Der long_query_time-Schwellenwert von 10 wird direkt anhand einer Formel (Wert >= 10) validiert, die Warnungen in Tools wie mysql-tuner auslöst. Der 10-Sekunden-Schwellenwert ignoriert „mittellangsame Abfragen“ von 1–5 Sekunden, die oft gewinnbringende Optimierungsmöglichkeiten bieten (z. B. Analyse mit EXPLAIN). In Szenarien mit hohem Datenverkehr wird empfohlen, den Schwellenwert auf 1–5 Sekunden anzupassen: 1 Sekunde eignet sich für Echtzeitanwendungen (z. B. E-Commerce), 2–3 Sekunden für allgemeine Zwecke und 5 Sekunden für die Berichterstellung von Workloads. Das Verkürzen des Schwellenwerts führt zu umfangreicheren Protokollen, die Protokollgröße (/var/log/mysql/mariadb-slow.log) sollte jedoch überwacht werden, um eine übermäßige Festplattenauslastung zu vermeiden.
long_query_time = 5 # Empfohlen 1–5 Sekunden, basierend auf Belastungstests slow_query_log = 1 # Protokoll für langsame Abfragen aktivieren (falls nicht aktiviert) slow_query_log_file = /var/log/mysql/mariadb-slow.log log_slow_verbosity = query_plan,explain # Ausführungsplan aufzeichnen log_queries_not_using_indexes = 1 # Abfragen aufzeichnen, die keine Indizes verwenden log_slow_admin_statements = 1 # Administrative Anweisungen aufzeichnen
Nach der Optimierung erfasst das Protokoll langsamer Abfragen mehr Details, hilft bei der schnellen Identifizierung von Problemen und verbessert die allgemeine Abfragegeschwindigkeit um über 30%. Die Größe der Protokolldatei nimmt jedoch zu (10–100 MB pro Tag). Rotieren Sie sie regelmäßig mit logrotate /var/log/mysql/mariadb-slow.log. Kombinieren Sie bei hoher Auslastung EXPLAIN und Indexoptimierung, um übermäßige Protokollierung zu vermeiden. Führen Sie regelmäßig mysql-tuner aus, um die Schwellenwerte zu überprüfen und sicherzustellen, dass sie Ihren tatsächlichen Anforderungen entsprechen (z. B. von 2 Sekunden auf 3 Sekunden anpassen).
Durch diese Anpassungen wird Ihre MySQL-Datenbank agiler und Ihre Website läuft effizienter. Die Optimierung ist ein fortlaufender Prozess. Die Kombination mit Monitoring-Tools wie Grafana führt zu noch besseren Ergebnissen.
Nachfolgend finden Sie eine vollständige MySQL-Konfiguration, die in einer Produktionsumgebung verwendet werden kann.
# # Diese Gruppen werden vom MariaDB-Server gelesen. # Verwenden Sie es für Optionen, die nur der Server (aber nicht die Clients) sehen sollen. # Dies wird vom eigenständigen Daemon und eingebetteten Servern gelesen [Server] # Dies ist nur für den eigenständigen mysqld-Daemon [mysqld] # # * Grundeinstellungen # #user = mysql pid-file = /run/mysqld/mysqld.pid basedir = /usr #datadir = /var/lib/mysql #tmpdir = /tmp # Beschädigtes Reverse-DNS verlangsamt Verbindungen erheblich und die Namensauflösung kann # sicher übersprungen werden, wenn keine Zugriffsberechtigungen „Host nach Domänenname“ vorhanden sind. #skip-name-resolve # Anstatt „Skip-Networking“ wird jetzt standardmäßig nur auf # localhost gelauscht, was kompatibler und nicht weniger sicher ist. bind-address = 127.0.0.1 # # * Feinabstimmung # key_buffer_size = 512M max_allowed_packet = 2G thread_stack = 192K thread_cache_size = 1024 tmp_table_size = 1024M max_heap_table_size = 1024M open_files_limit = 0 #key_buffer_size = 128M #max_allowed_packet = 1G #thread_stack = 192K #thread_cache_size = 8 # Dies ersetzt das Startskript und überprüft MyISAM-Tabellen bei Bedarf # beim ersten Zugriff #myisam_recover_options = BACKUP #max_connections = 100 #table_cache = 64 myisam_recover_options = BACKUP max_connections = 9999 table_open_cache = 40000 # # * Protokollierung und Replikation # # Hinweis: Die konfigurierte Protokolldatei oder ihr Verzeichnis muss erstellt werden # und für den MySQL-Benutzer beschreibbar sein, zB: # $ sudo mkdir -m 2750 /var/log/mysql # $ sudo chown mysql /var/log/mysql # Beide Speicherorte werden vom Cronjob rotiert. # Beachten Sie, dass dieser Protokolltyp die Leistung beeinträchtigt. # Es wird empfohlen, dies zur Laufzeit nur für kurze Testzeiträume zu ändern, falls nötig! #general_log_file = /var/log/mysql/mysql.log #general_log = 1 # Beim Ausführen unter systemd geht die Fehlerprotokollierung über stdout/stderr an journald # und beim Ausführen von Legacy-Init geht die Fehlerprotokollierung an syslog aufgrund von # /etc/mysql/conf.d/mariadb.conf.d/50-mysqld_safe.cnf # Aktivieren Sie dies, wenn Sie die Fehlerprotokollierung in einer separaten Datei haben möchten #log_error = /var/log/mysql/error.log # Aktivieren Sie das Protokoll für langsame Abfragen, um Abfragen mit besonders langer Dauer anzuzeigen #log_slow_query_file = /var/log/mysql/mariadb-slow.log #log_slow_query_time = 10 #log_slow_verbosity = query_plan,explain #log-queries-not-using-indexes #log_slow_min_examined_row_limit = 1000 long_query_time =5 # Empfohlen 1–5 Sekunden, basierend auf Belastungstests slow_query_log = 1 # Protokoll für langsame Abfragen aktivieren (falls nicht aktiviert) slow_query_log_file = /var/log/mysql/mariadb-slow.log log_slow_verbosity = query_plan,explain # Ausführungsplan aufzeichnen log_queries_not_using_indexes = 1 # Abfragen aufzeichnen, die keine Indizes verwenden log_slow_admin_statements = 1 # Administrative Anweisungen aufzeichnen # Folgendes kann als einfach wiederzugebende Sicherungsprotokolle oder zur Replikation verwendet werden. #-Hinweis: Wenn Sie eine Replik einrichten, lesen Sie README.Debian, um weitere #-Einstellungen zu erfahren, die Sie möglicherweise ändern müssen. #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 #max_binlog_size = 100M # # * SSL/TLS # # Die Dokumentation finden Sie unter # https://mariadb.com/kb/en/securing-connections-for-client-and-server/ #ssl-ca = /etc/mysql/cacert.pem #ssl-cert = /etc/mysql/server-cert.pem #ssl-key = /etc/mysql/server-key.pem #require-secure-transport = on # # * Zeichensätze # # MySQL/MariaDB Standard ist Latin1, aber in Debian verwenden wir standardmäßig den vollständigen # UTF-8-4-Byte-Zeichensatz. Siehe auch client.cnf character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci # # * InnoDB # # InnoDB ist standardmäßig mit einer 10 MB großen Datendatei in /var/lib/mysql/ aktiviert. # Weitere InnoDB-bezogene Optionen finden Sie im Handbuch. Es gibt viele! # Am wichtigsten ist es, InnoDB 80 % des System-RAM für die Puffernutzung zu geben: # https://mariadb.com/kb/en/innodb-system-variables/#innodb_buffer_pool_size #innodb_buffer_pool_size = 8G innodb_buffer_pool_size = 48G innodb_buffer_pool_instances = 16 innodb_log_file_size = 12G innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT innodb_io_capacity = 2000 innodb_read_io_threads = 8 innodb_write_io_threads = 8 # dies ist nur für eingebettete Server [embedded] # Diese Gruppe wird nur von MariaDB-Servern gelesen, nicht von MySQL. # Wenn Sie dieselbe .cnf-Datei für MySQL und MariaDB verwenden, # können Sie hier nur MariaDB-Optionen einfügen [mariadb] # Diese Gruppe wird nur von MariaDB-10.11-Servern gelesen. # Wenn Sie dieselbe .cnf-Datei für MariaDB verschiedener Versionen verwenden, # verwenden Sie diese Gruppe für Optionen, die ältere Server nicht verstehen [mariadb-10.11]
