Effiziente Statistikaktualisierung in MySQL-Datenbanksystemen: Einblick in ANALYZE TABLE
Die Aktualisierung von Statistiken für Tabellen und Indizes in MySQL-Datenbanken kann unter bestimmten Umständen unumgänglich sein. Hierbei spielt der Befehl ANALYZE TABLE eine zentrale Rolle. Dieser Beitrag befasst sich mit den Auswirkungen dieses Befehls auf Produktionsumgebungen, insbesondere mit Blick auf die damit verbundene Systembelastung. Diese Betrachtung konzentriert sich nicht auf die herkömmlichen Kosten, die durch die Analyse von Tabellenzeilen für statistische Zwecke entstehen, da diese durch die Anpassung der Stichprobengröße gesteuert werden können.
In den vergangenen Jahren wurde deutlich, dass der Einsatz von ANALYZE TABLE in stark beanspruchten Produktionsumgebungen zu Problemen führen konnte. Die Kernherausforderung lag darin, dass für die Ausführung des Befehls eine exklusive Sperre auf den Tabellendefinitions-Cache erforderlich war. Dies führte zu Wartezeiten bei lang laufenden Abfragen und konnte weitere Wartezeiten bei neu hinzukommenden Anfragen nach sich ziehen. Kurzum, der Befehl konnte in intensiv genutzten Umgebungen zu erheblichen Verzögerungen führen.
Es gab jedoch erhebliche Entwicklungen in diesem Bereich. Viele Systeme, die heute noch im Einsatz sind, verwenden Versionen, die von dieser Problematik betroffen sind. Lassen Sie uns einen Blick auf die Entwicklungen werfen:
MySQL Server – Community Edition
Die Problematik betrifft alle MySQL-Community-Versionen bis zu 8.0.23. Keine signifikanten Verbesserungen gab es in der 5.7er Serie, die bald ihr End-of-Life erreicht. Dies bedeutet, dass selbst die aktuellste Version 5.7.43 von diesem Problem betroffen ist. Beispielhaft könnte man hier folgende Situationen antreffen:
- Bei Version 5.7.43: Lange laufende Abfragen verzögern die Ausführung von ANALYZE.
- Bei Version 8.0.23: Ähnliche Verzögerungen wie bei Version 5.7.43.
- Ab Version 8.0.24: Ein Update behebt dieses Problem, so dass lange laufende Abfragen die Ausführung von ANALYZE nicht mehr verzögern.
-- Überprüfung der aktuellen Version
mysql> SELECT @@version, @@version_comment;
-- Ergebnis:
-- +---------+------------------------------+
-- | 5.7.43 | MySQL Community Server (GPL) |
-- +---------+------------------------------+
-- Anzeigen der aktuellen Prozesse
mysql> SHOW FULL PROCESSLIST;
-- Mögliche Ausgabe:
-- +----+----------+-----------+------+---------+------+-------------------------+-----------------------------------------------------+
-- | Id | User | Host | db | Command | Time | State | Info |
-- +----+----------+-----------+------+---------+------+-------------------------+-----------------------------------------------------+
-- | 4 | msandbox | localhost | db1 | Query | 54 | Ausführung | SELECT AVG(k) FROM sbtest1 WHERE pad NOT LIKE '%f%' |
-- | 13 | msandbox | localhost | db1 | Query | 29 | Warte auf Tabellensperr | ANALYZE TABLE sbtest1 |
-- +----+----------+-----------+------+---------+------+-------------------------+-----------------------------------------------------+
-- Überprüfung der aktuellen Version
mysql> SELECT @@version, @@version_comment;
-- Ergebnis:
-- +---------+------------------------------+
-- | 8.0.24 | MySQL Community Server - GPL |
-- +---------+------------------------------+
-- Ausführen von ANALYZE TABLE
mysql> ANALYZE TABLE sbtest1;
-- Ergebnis:
-- +-------------+---------+----------+----------+
-- | Table | Op | Msg_type | Msg_text |
-- +-------------+---------+----------+----------+
-- | db1.sbtest1 | ANALYZE | status | OK |
-- +-------------+---------+----------+----------+
Trotz dieser Verbesserungen finden sich in der offiziellen Dokumentation für Version 8.1 immer noch Warnungen, dass ANALYZE TABLE zu Wartezeiten führen kann.
Percona Server für MySQL
Percona hat eine Lösung für das Problem der Sperre des Tabellendefinitions-Caches eingeführt. In den Versionen 5.6.38 und 5.7.20, die damals die aktuellen Entwicklungsreihen waren, war das Ausführen von ANALYZE TABLE bereits sicher. Die Version 8.0 von Percona Server für MySQL war von Anfang an frei von diesem Problem, da die Verbesserungen aus der 5.7er Serie übernommen wurden.
MariaDB Server
Auch MariaDB war bis zur Version 10.5.3 von der Problematik betroffen. Ab Version 10.5.4 wurde die von Percona entwickelte Lösung implementiert. In Versionen vor 10.5.4, einschließlich der aktuellen 10.4.31, können ähnliche Verzögerungen auftreten.
-- Überprüfung der aktuellen Version in MariaDB 10.5.3
mysql> SELECT @@version, @@version_comment;
-- Ergebnis:
-- +-------------+----------------+
-- | 10.5.3 | MariaDB Server |
-- +-------------+----------------+
-- Anzeigen der aktuellen Prozesse
mysql> SHOW FULL PROCESSLIST;
-- Mögliche Ausgabe:
-- +----+----------+-----------+------+---------+------+-------------------------+-----------------------------------------------------+
-- | Id | User | Host | db | Command | Time | State | Info |
-- +----+----------+-----------+------+---------+------+-------------------------+-----------------------------------------------------+
-- | 4 | msandbox | localhost | db1 | Query | 18 | Ausführung | SELECT AVG(k) FROM sbtest1 WHERE pad NOT LIKE '%f%' |
-- | 13 | msandbox | localhost | db1 | Query | 16 | Warte auf Tabellensperr | ANALYZE TABLE sbtest1 |
-- +----+----------+-----------+------+---------+------+-------------------------+-----------------------------------------------------+
Fazit
In modernen MySQL- oder MariaDB-Umgebungen sollte das Ausführen von ANALYZE TABLE keine unerwarteten Verzögerungen mehr verursachen. Nutzer der Percona Server für MySQL-Versionen 5.6.38+, 5.7.20+ und 8.0.x können ebenfalls auf sichere Ausführung vertrauen. Wer noch ältere Community-Versionen nutzt, sollte in Erwägung ziehen, auf eine aktuellere Version umzusteigen, um die Problematik zu umgehen.
Hinterlasse einen Kommentar
Alle Kommentare werden vor der Veröffentlichung geprüft.
Diese Website ist durch reCAPTCHA geschützt und es gelten die allgemeinen Geschäftsbedingungen und Datenschutzbestimmungen von Google.