2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Im Allgemeinen kann MySQL in zwei Schichten unterteilt werden
mysql -h$ip -P$port -u$user -p
Das MySQL im Verbindungsbefehl ist ein Client-Tool, das zum Herstellen einer Verbindung mit dem Server verwendet wird.Nach Abschluss des klassischen TCP-Handshakes erfolgt der Connector
Es wird gleich mit der Authentifizierung Ihrer Identität begonnen. Zu diesem Zeitpunkt werden der von Ihnen eingegebene Benutzername und das Passwort verwendet.
Wenn der Client zu lange inaktiv ist, wird er vom Connector automatisch getrennt. Diese Zeit wird durch den Parameter wait_timeout gesteuert und der Standardwert beträgt 8 Stunden.
Wenn der Client nach dem Verbindungsabbau erneut eine Anfrage sendet, erhält er eine Fehlererinnerung: Lost connection to MySQL server during query . Wenn Sie zu diesem Zeitpunkt fortfahren möchten, müssen Sie die Verbindung erneut herstellen und dann die Anfrage ausführen.
In der Datenbank bedeutet eine lange Verbindung, dass nach erfolgreicher Verbindung immer dieselbe Verbindung verwendet wird, wenn der Client weiterhin Anfragen stellt. Eine kurze Verbindung bedeutet, dass die Verbindung nach einigen ausgeführten Abfragen getrennt wird und für die nächste Abfrage eine neue Verbindung hergestellt wird.
Der Vorgang des Verbindungsaufbaus ist in der Regel kompliziert. Ich schlage daher vor, dass Sie versuchen, den Verbindungsaufbau während der Nutzung so gering wie möglich zu halten, d. h. lange Verbindungen zu verwenden.
Nachdem jedoch alle langen Verbindungen verwendet wurden, kann es vorkommen, dass der von MySQL belegte Speicher sehr schnell zunimmtDer von MySQL während der Ausführung vorübergehend verwendete Speicher wird im Verbindungsobjekt verwaltet. . Diese Ressourcen werden freigegeben, wenn die Verbindung getrennt wird.Also wennDie Anhäufung langer Verbindungen kann zu einer übermäßigen Speichernutzung führen., wurde vom System (OOM) gewaltsam getötet. Dem Phänomen nach zu urteilen, wurde MySQL abnormal neu gestartet.
Wie kann dieses Problem gelöst werden? Sie können die folgenden zwei Optionen in Betracht ziehen.
mysql_reset_connection um Verbindungsressourcen neu zu initialisieren. Dieser Vorgang erfordert keine erneute Verbindung und keine Berechtigungsüberprüfung, sondern stellt die Verbindung in dem Zustand wieder her, in dem sie gerade erstellt wurde.Nachdem MySQL eine Abfrageanforderung erhält, geht es zunächst zum Abfragecache, um zu sehen, ob diese Anweisung bereits zuvor ausgeführt wurde. Zuvor ausgeführte Anweisungen und ihre Ergebnisse können in Form von Schlüssel-Wert-Paaren direkt im Speicher zwischengespeichert werden. Der Schlüssel ist die Abfrageanweisung und der Wert ist das Abfrageergebnis. Wenn Ihre Abfrage den Schlüssel direkt in diesem Cache finden kann, wird der Wert direkt an den Client zurückgegeben.
Befindet sich die Anweisung nicht im Abfragecache, wird die Ausführungsphase fortgesetzt. Nach Abschluss der Ausführung werden die Ausführungsergebnisse im Abfragecache gespeichert. Sie können sehen, dass MySQL das Ergebnis direkt zurückgeben kann, wenn die Abfrage den Cache erreicht, ohne dass nachfolgende komplexe Vorgänge ausgeführt werden müssen, was sehr effizient ist.
Aber meistens werde ich es tunEs wird empfohlen, kein Abfrage-Caching zu verwenden ,Warum? Weil Abfrage-Caching oft mehr schadet als nützt.
Der Abfragecache wird sehr häufig ungültig gemacht. Solange es eine Aktualisierung einer Tabelle gibt, werden alle Abfragecaches für diese Tabelle geleert. Es ist also möglich, dass Sie sich die Mühe gemacht haben, die Ergebnisse zu speichern, und bevor Sie sie überhaupt verwendet haben, wurden sie durch ein Update gelöscht. Bei Datenbanken mit hohem Aktualisierungsdruck ist die Trefferquote des Abfragecaches sehr niedrig. Es sei denn, Ihr Unternehmen verfügt über eine statische Tabelle, die nur einmal über einen längeren Zeitraum aktualisiert wird. Wenn es sich beispielsweise um eine Systemkonfigurationstabelle handelt, ist die Abfrage dieser Tabelle für den Abfragecache geeignet.
Glücklicherweise bietet MySQL auch diese „Use on Demand“-Methode an. Sie können den Parameter query_cache_type auf DEMAND setzen, sodass der Abfragecache nicht für die Standard-SQL-Anweisungen verwendet wird. Für Anweisungen, bei denen Sie sicher sind, dass Sie den Abfragecache verwenden möchten, können Sie SQL_CACHE verwenden, um ihn explizit anzugeben, wie die folgende Anweisung:
select SQL_CACHE * from T where ID=10；
muss sich darüber im Klaren sein,Die MySQL 8.0-Version löscht direkt die gesamte Abfrage-Cache-Funktion, was bedeutet, dass diese Funktion ab 8.0 nicht mehr verfügbar ist.
Wenn der Abfragecache nicht erreicht wird, beginnt die eigentliche Ausführung der Anweisung. Zunächst muss MySQL wissen, was Sie tun möchten, also muss es die SQL-Anweisung analysieren.
Ich weiß nicht, ob Sie sich noch an den Artikel „Kong Yiji“ erinnern. Der Hotelmanager verfügt über eine rosa Tafel, die speziell zur Erfassung der Kreditdaten der Gäste dient. Wenn es nicht viele Leute gibt, die auf Kredit bezahlen, kann er den Namen und das Konto des Kunden an die Tafel schreiben. Aber wenn es zu viele Leute mit Guthabenkonten gibt, wird es immer Zeiten geben, in denen das Fanboard den Überblick nicht behalten kann. Zu diesem Zeitpunkt muss der Ladenbesitzer ein Hauptbuch speziell für die Erfassung von Guthabenkonten haben.
Möchte jemand einen Kredit abbezahlen oder eine Schuld abbezahlen, hat der Ladenbesitzer grundsätzlich zwei Möglichkeiten:
Wenn das Geschäft boomt und die Theke voll ist, wird sich der Ladenbesitzer definitiv entscheidenLetzteres , weil die erstere Operation zu mühsam ist. Zuerst müssen Sie den Datensatz des Gesamtguthabenkontos dieser Person finden. Denken Sie darüber nach, es gibt Dutzende dicht gepackter Seiten. Um den Namen zu finden, muss der Ladenbesitzer möglicherweise eine Lesebrille aufsetzen und langsam suchen. Nachdem er ihn gefunden hat, wird er den Abakus herausnehmen, um ihn zu berechnen, und schließlich das Ergebnis zurückschreiben Das Hauptbuch.
Es ist mühsam, über diesen gesamten Prozess nachzudenken. Im Gegensatz dazu ist es einfacher, es zuerst an die rosa Tafel zu schreiben. Denken Sie darüber nach: Wenn der Ladenbesitzer nicht die Hilfe der rosa Tafel hat, muss er das Hauptbuch jedes Mal umdrehen, wenn er Konten aufzeichnet. Ist die Effizienz nicht unerträglich niedrig?
In ähnlicher Weise besteht dieses Problem auch in MySQL. Wenn jeder Aktualisierungsvorgang auf die Festplatte geschrieben werden muss und die Festplatte vor der Aktualisierung auch den entsprechenden Datensatz finden muss, sind die E/A-Kosten und Suchkosten des gesamten Prozesses sehr hoch. Um dieses Problem zu lösen, nutzten die MySQL-Designer eine Idee, die der rosa Tafel des Hotelladenbesitzers ähnelt, um die Aktualisierungseffizienz zu verbessern.
Der gesamte Prozess der Zusammenarbeit zwischen dem Pink Board und dem Ledger ist eigentlich das, was in MySQL oft erwähnt wird. WAL Technologie,WAL Der vollständige Name lautetWrite-Ahead Logging, der entscheidende Punkt istSchreiben Sie zuerst das Protokoll und dann auf die FestplatteDas heißt, schreiben Sie zuerst die rosa Tafel und dann das Geschäftsbuch, wenn Sie nicht beschäftigt sind.
Insbesondere wenn ein Datensatz aktualisiert werden muss, schreibt die InnoDB-Engine den Datensatz zunächst in das Redo-Protokoll (rosa Tafel) und aktualisiert den Speicher. Zu diesem Zeitpunkt ist die Aktualisierung abgeschlossen. Gleichzeitig aktualisiert die InnoDB-Engine den Vorgangsdatensatz zum richtigen Zeitpunkt auf der Festplatte. Diese Aktualisierung erfolgt häufig, wenn das System relativ inaktiv ist, genau wie der Ladenbesitzer es nach dem Schließen tut.
Wenn heute nicht viele Guthabenkonten vorhanden sind, kann der Ladenbesitzer mit dem Aussortieren der Artikel bis zum Ladenschluss warten. Was aber tun, wenn es an einem bestimmten Tag viele Guthabenkonten gibt und die rosa Tafel voll ist? Zu diesem Zeitpunkt hatte der Ladenbesitzer keine andere Wahl, als seine Arbeit niederzulegen, einige der Kreditdatensätze auf der rosa Tafel im Hauptbuch zu aktualisieren und diese Datensätze dann von der rosa Tafel zu löschen, um Platz für neue Konten zu schaffen.
Ebenso hat das Redo-Protokoll von InnoDB eine feste Größe. Es kann beispielsweise als Satz von 4 Dateien konfiguriert werden, wobei jede Datei 1 GB groß ist. Dann kann dieses „Pink Board“ insgesamt 4 GB Vorgänge aufzeichnen. Beginnen Sie mit dem Schreiben von vorne und kehren Sie dann zum Anfang zurück, um in einer Schleife zu schreiben, wie in der Abbildung unten gezeigt.
write pos ist die Position des aktuellen Datensatzes. Nach dem Schreiben wird an das Ende der Datei Nr. 3 zurückgekehrt. Der Prüfpunkt ist die aktuelle Position, die gelöscht werden soll, und er bewegt sich auch vorwärts und führt eine Schleife durch. Vor dem Löschen des Datensatzes muss der Datensatz in der Datendatei aktualisiert werden.
Der Raum zwischen Schreibposition und Prüfpunkt ist der leere Teil der „rosa Tafel“, der zum Aufzeichnen neuer Vorgänge verwendet werden kann. Wenn die Schreibposition den Prüfpunkt einholt, bedeutet dies, dass das „Pink Board“ voll ist und zu diesem Zeitpunkt keine neuen Aktualisierungen durchgeführt werden können. Sie müssen zuerst anhalten und einige Datensätze löschen, um den Prüfpunkt voranzutreiben.
Mit dem Redo-Protokoll kann InnoDB sicherstellen, dass zuvor übermittelte Datensätze nicht verloren gehen. Diese Funktion wird aufgerufencrash-safe。
Um das Konzept der Crash-Sicherheit zu verstehen, denken Sie an unser vorheriges Beispiel für Kreditunterlagen. Solange die Kreditaufzeichnung auf der rosa Tafel oder im Hauptbuch vermerkt ist, kann der Ladenbesitzer das Kreditkonto anhand der Daten im Hauptbuch klären, auch wenn er sie später vergisst, z. B. weil er sein Geschäft plötzlich für ein paar Tage einstellt Pinke Tafel nach Wiederaufnahme des Geschäftsbetriebs.
Wie bereits erwähnt, besteht MySQL als Ganzes eigentlich aus zwei Teilen: Der eine ist die Serverschicht, die hauptsächlich Dinge auf der Funktionsebene von MySQL erledigt, und der andere ist die Engine-Schicht, die für bestimmte speicherbezogene Angelegenheiten verantwortlich ist.Die rosa Tafel, über die wir oben gesprochen habenRedo-Protokoll ist ein Protokoll, das nur für die InnoDB-Engine gilt,Und Die Serverschicht verfügt außerdem über ein eigenes Protokoll namens Binlog (Archivprotokoll).。
Ich denke, Sie werden sich fragen: Warum gibt es zwei Protokolle?
Weil es zu Beginn keine InnoDB-Engine in MySQL gab. Die eigene Engine von MySQL ist MyISAM, aber MyISAM verfügt nicht über Absturzsicherungsfunktionen und Binlog-Protokolle können nur zur Archivierung verwendet werden. InnoDB wurde von einem anderen Unternehmen in Form eines Plug-Ins in MySQL eingeführt. Da die alleinige Verwendung von Binlog keine absturzsicheren Funktionen bietet, verwendet InnoDB ein anderes Protokollsystem, nämlich Redo Log, um absturzsichere Funktionen zu erreichen.
Diese beiden Protokolle weisen die folgenden drei Unterschiede auf.
Mit einem konzeptionellen Verständnis dieser beiden Protokolle schauen wir uns die internen Prozesse des Executors und der InnoDB-Engine bei der Ausführung dieser einfachen Update-Anweisung an.
Hier gebe ich das Ausführungsflussdiagramm dieser Aktualisierungsanweisung an. Das helle Kästchen in der Abbildung zeigt an, dass es in InnoDB ausgeführt wird, und das dunkle Kästchen zeigt an, dass es im Executor ausgeführt wird.
Ausführungsprozess der Update-Anweisung
Sie haben vielleicht bemerkt, dass die letzten drei Schritte etwas „zirkulär“ erscheinen. Das Schreiben des Redo-Logs ist in zwei Schritte unterteilt: Vorbereiten und Festschreiben. Dies ist ein „Zwei-Phasen-Commit“.
Warum ist eine „zweistufige Einreichung“ notwendig?Dadurch soll der Unterschied zwischen den beiden Protokollen berücksichtigt werdenlogisch konsistent . Um dieses Problem zu erklären, müssen wir mit der Frage am Anfang des Artikels beginnen: Wie kann die Datenbank innerhalb eines halben Monats auf den Zustand einer beliebigen Sekunde zurückgesetzt werden?
Wie bereits erwähnt, zeichnet Binlog alle logischen Vorgänge auf und übernimmt die Form des „Schreibens anhängen“. Wenn Ihr DBA verspricht, dass die Datenbank innerhalb eines halben Monats wiederhergestellt werden kann, speichert das Backup-System auf jeden Fall alle Binlogs des letzten halben Monats und führt regelmäßige Backups der gesamten Datenbank durch. Das „Regelmäßige“ hängt hier von der Wichtigkeit des Systems ab, das einmal am Tag oder einmal in der Woche sein kann.
Wenn Sie eine bestimmte Sekunde wiederherstellen müssen, beispielsweise eines Tages um zwei Uhr nachmittags, feststellen, dass eine Tabelle versehentlich mittags gelöscht wurde, und Sie die Daten abrufen müssen, können Sie Folgendes tun:
Okay, nachdem wir über den Datenwiederherstellungsprozess gesprochen haben, kommen wir zurück und sprechen darüber, warum das Protokoll ein „zweiphasiges Commit“ benötigt. Hier könnten wir zur Erklärung genauso gut einen Widerspruchsbeweis verwenden.
Da Redo-Log und Binlog zwei unabhängige Logiken sind, muss, wenn kein zweiphasiges Commit verwendet wird, entweder zuerst Redo-Log und dann Binlog geschrieben werden, oder es muss die umgekehrte Reihenfolge übernommen werden. Mal sehen, welche Probleme es mit diesen beiden Methoden gibt.
Verwenden Sie weiterhin die vorherige Update-Anweisung als Beispiel. Nehmen Sie an, dass der Wert von Feld c in der aktuellen Zeile mit ID=2 0 ist, und nehmen Sie an, dass es während der Ausführung der Update-Anweisung zu einem Absturz kommt, nachdem das erste Protokoll geschrieben wurde, aber bevor das zweite Protokoll geschrieben wurde.
Sie fragen sich: Ist diese Wahrscheinlichkeit sehr gering? Es gibt keine Situationen, in denen die temporäre Bibliothek zu irgendeinem Zeitpunkt wiederhergestellt werden muss.
Eigentlich nein, dieser Prozess ist nicht nur erforderlich, um Daten nach einer Fehlbedienung wiederherzustellen. Wenn Sie die Kapazität erweitern müssen, das heißt, wenn Sie mehr Standby-Datenbanken erstellen müssen, um die Lesekapazität des Systems zu erhöhen, ist es mittlerweile üblich, eine vollständige Sicherung zu verwenden und Binlog anzuwenden, um dies zu erreichen. Diese „Inkonsistenz“ führt zu Ihrem Problem eine Inkonsistenz zwischen den Master- und Slave-Datenbanken online.
Einfach ausgedrückt können sowohl Redo-Log als auch Binlog verwendet werden, um den Commit-Status einer Transaktion darzustellenDie zweistufige Einreichung dient dazu, die beiden Zustände logisch konsistent zu halten.。
Er widmet sich seit mehr als 30 Jahren der Technologieforschung und beherrscht verschiedene Sprachen wie Java, Linux, Javascript, PHP, CSS usw. Er hat viele Beiträge im Open-Source-Bereich geleistet Entwicklerdokumentationsstation, um einige Themen in der Technologieentwicklung als zukünftige Referenz zu teilen
