Eine kurze Analyse der grundlegenden MySQL-Planungsstrategien

[Einführung] MySQL ermöglicht die Beeinflussung der Planungseigenschaften von Anweisungen, wodurch Abfragen von mehreren Clients besser zusammenarbeiten können, sodass ein einzelner Client nicht zu lange gesperrt wird. Durch die Änderung von Planungsmerkmalen kann auch dafür gesorgt werden, dass bestimmte Abfragen schneller verarbeitet werden. Schauen wir uns zunächst die Standardplanungsrichtlinie von MySQL an und schauen uns dann

an. Mit MySQL können Sie die Planungseigenschaften von Anweisungen beeinflussen, wodurch Abfragen von mehreren Clients besser zusammenarbeiten, sodass ein einzelner Client nicht gesperrt wird zu lange. Durch die Änderung von Planungsmerkmalen kann auch dafür gesorgt werden, dass bestimmte Abfragen schneller verarbeitet werden. Schauen wir uns zunächst die Standardplanungsrichtlinie von MySQL an und dann die verfügbaren Optionen zum Ändern dieser Richtlinie. Für die Zwecke dieser Diskussion wird davon ausgegangen, dass das Client-Programm, das den Abruf ausführt (SELECT), das Leseprogramm ist. Ein weiteres Clientprogramm, das eine Tabellenänderungsoperation (DELETE, INSERT, REPLACE oder UP DATE) ausführt, ist der Writer.

Die grundlegende Planungsstrategie von MySQL lässt sich wie folgt zusammenfassen:

◆Schreibanfragen sollten in der Reihenfolge ihres Eintreffens verarbeitet werden.

　◆Schreiben hat höhere Priorität als Lesen.

Implementieren Sie eine Planungsstrategie mithilfe von Tabellensperren. Wann immer ein Clientprogramm auf eine Tabelle zugreifen möchte, muss es zunächst eine Sperre für die Tabelle erhalten. Dies kann direkt über LOCK TABLES erfolgen, aber im Allgemeinen ruft der Sperrenmanager des Servers die Sperre bei Bedarf automatisch ab. Die Sperre für die Tabelle kann aufgehoben werden, wenn der Client die Verarbeitung der Tabelle abgeschlossen hat. Direkt erworbene Sperren können mit UNLOCK TABLES freigegeben werden, der Server gibt jedoch auch automatisch erworbene Sperren frei.

Der Client, der den Schreibvorgang ausführt, muss über eine exklusive Zugriffssperre für die Tabelle verfügen. Während der Schreibvorgang ausgeführt wird, befindet sich die Tabelle in einem inkonsistenten Zustand, da Datensätze in der Tabelle gelöscht, hinzugefügt oder geändert werden, und die Indizes der Tabelle müssen möglicherweise auch entsprechend aktualisiert werden. Wenn sich die Tabelle ständig ändert, kann es zu Problemen führen, wenn anderen Clients zu diesem Zeitpunkt der Zugriff auf die Tabelle gestattet wird. Es ist offensichtlich nicht gut, wenn zwei Clients gleichzeitig in dieselbe Tabelle schreiben, da die Tabelle dadurch schnell nicht mehr verfügbar ist. Es ist auch nicht sinnvoll, einem Client das Lesen einer Tabelle zu ermöglichen, die sich ständig ändert, da zum Zeitpunkt des Lesens möglicherweise Änderungen an der Tabelle vorgenommen werden und die Ergebnisse falsch sind. Der Client, der den Lesevorgang ausführt, muss über eine Sperre verfügen, die andere Clients daran hindert, in die Tabelle zu schreiben, um sicherzustellen, dass sich die Tabelle während des Tabellenlesevorgangs nicht ändert. Die Sperre muss jedoch keinen exklusiven Zugriff für Lesevorgänge bereitstellen. Diese Sperre ermöglicht es auch anderen Clients, gleichzeitig aus der Tabelle zu lesen. Durch das Lesen wird die Tabelle nicht verändert, daher besteht keine Notwendigkeit, andere Clients am Lesen der Tabelle zu hindern.

MySQL erlaubt mehrere Abfragelimitmodifikatoren, um seine Planungsstrategie zu beeinflussen. Eines davon ist das Schlüsselwort LOW_PRIORITY für DELETE-, INSERT-, LOAD DATA-, REPLACE- und UP DATE-Anweisungen. Das andere ist das Schlüsselwort HIGH_PRIORITY der SELECT-Anweisung. Das dritte ist das Schlüsselwort DELAYED der INSERT- und REPLACE-Anweisungen.

Das Schlüsselwort LOW_PRIORITY wirkt sich wie folgt auf die Planung aus. Wenn ein Schreibvorgang in eine Tabelle eintrifft, während die Tabelle gelesen wird, wird der Schreiber normalerweise blockiert, bis der Leser den Vorgang abschließt, da eine einmal gestartete Abfrage nicht mehr unterbrochen werden kann. Wenn während des Wartens des Autors eine weitere Leseanforderung eintrifft, wird der Leser ebenfalls blockiert, da die Standardplanungsrichtlinie dem Autor eine höhere Priorität als dem Leser einräumt. Am Ende des ersten Leseprogramms wird das Schreibprogramm fortgesetzt und am Ende dieses Schreibprogramms beginnt das zweite Leseprogramm.

Wenn es sich bei der Schreibanforderung um eine LOW_PRIORITY-Anfrage handelt, wird davon ausgegangen, dass der Schreibvorgang keine höhere Priorität hat als der Lesevorgang. Wenn in diesem Fall eine zweite Leseanforderung eintrifft, während der Schreiber wartet, sollte der zweite Lesevorgang vor dem wartenden Schreibvorgang in die Warteschlange gestellt werden. Der Writer darf nur dann ausführen, wenn keine anderen Leseanforderungen vorliegen. Die theoretische Auswirkung dieser Änderung in der Planung besteht darin, dass Schreibvorgänge mit LOW_PRIORITY möglicherweise für immer blockiert werden. Immer wenn eine weitere Leseanforderung eintrifft, während eine vorherige Leseanforderung verarbeitet wird, darf diese neue Anforderung vor dem Schreibvorgang mit LOW_PRIORITY in die Warteschlange gestellt werden.

Das Schlüsselwort HIGH_PRIORITY der SELECT-Abfrage hat einen ähnlichen Effekt. Dadurch wird SELECT vor einem anstehenden Schreibvorgang eingefügt, auch wenn der Schreibvorgang normale Priorität hat. Der ELAYED-Modifikator von INSERT funktioniert wie folgt: Wenn eine INSERT DELAYED-Anfrage für die Tabelle eintrifft, stellt der Server die entsprechenden Zeilen in eine Warteschlange und gibt sofort einen Status an das Client-Programm zurück, sodass das Client-Programm auch dann weiter ausgeführt werden kann, wenn diese Zeilen vorhanden sind rows Es wurde noch nicht in die Tabelle eingefügt. Wenn ein Leser aus der Tabelle liest, sind die Zeilen in der Warteschlange ausstehend. Wenn keine Lesevorgänge vorliegen, beginnt der Server mit dem Einfügen von Zeilen in die Warteschlange für verzögerte Zeilen. Von Zeit zu Zeit stoppt der Server, um zu sehen, ob neue Leseanforderungen eingegangen sind, und wartet. Wenn dies der Fall ist, wird die verzögerte Zeilenwarteschlange angehalten und der Leser kann fortfahren. Wenn keine anderen Lesevorgänge stattfinden, beginnt der Server erneut mit dem Einfügen verzögerter Zeilen. Dieser Vorgang wird fortgesetzt, bis die verzögerte Warteschlange leer ist.

Dies erscheint nicht in allen MySQL-Versionen. In der folgenden Tabelle sind diese Modifikatoren und die MySQL-Versionen aufgeführt, die sie unterstützen. Anhand dieser Tabelle können Sie ermitteln, über welche Funktionen die von Ihnen verwendete MySQL-Version verfügt:

INSERT DELAYED ist nützlich, wenn andere Clients möglicherweise längere SELECT-Anweisungen ausführen und Sie nicht warten möchten, bis die Einfügung abgeschlossen ist. Clients, die INSERT DELAYED ausgeben, können die Ausführung schneller fortsetzen, da der Server einfach die einzufügende Zeile einfügt. Sie sollten sich jedoch des Unterschieds zwischen normaler INSERT- und INSERT DELAYED-Leistung bewusst sein. Wenn in INSERT DELAYED ein Syntaxfehler vorliegt, wird ein Fehler an den Client gesendet. Wenn es normal ist, wird keine Nachricht gesendet. Beispielsweise kann dem AUTO_INCREMENT-Wert, der bei der Rückgabe dieser Anweisung erhalten wird, nicht vertraut werden. Sie können auch nicht die Anzahl der Duplikate in einem eindeutigen Index ermitteln. Dies liegt daran, dass der Einfügevorgang einen Status zurückgibt, bevor der eigentliche Einfügevorgang abgeschlossen ist. Andere weisen auch darauf hin, dass diese Zeilen verloren gehen, wenn Zeilen für eine INSERT DELAYED-Anweisung in der Warteschlange stehen und auf das Einfügen warten und der Server abstürzt oder beendet wird (mit kill -9). Bei der normalen TERM-Beendigung ist dies nicht der Fall. Der Server fügt diese Zeilen vor dem Beenden ein.

Das Obige ist eine kurze Analyse der grundlegenden MySQL-Planungsstrategie. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn).