Lassen Sie uns analysieren, wie die Update-Anweisung von MySQL ausgeführt wird.

Dieser Artikel vermittelt Ihnen relevantes Wissen über MySQL und stellt hauptsächlich die damit verbundenen Probleme bei der Ausführung einer Aktualisierungsanweisung vor. Wenn der Aktualisierungsvorgang ausgeführt wird, ist der mit der Tabelle verbundene Abfragecache ungültig, sodass die Anweisung alle zwischengespeicherten Ergebnisse liefert Lassen Sie uns gemeinsam einen Blick darauf werfen. Ich hoffe, es wird für alle hilfreich sein.

Empfohlenes Lernen: MySQL-Tutorial

Vorbereitende Vorbereitung

Erstellen Sie zunächst eine Tabelle und fügen Sie dann drei Datenelemente ein:

CREATE TABLE T(
	ID int(11) NOT NULL AUTO_INCREMENT,
	c int(11) NOT NULL,
	PRIMARY KEY (ID)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='测试表';INSERT INTO T(c) VALUES (1), (2), (3);

Lassen Sie uns den Aktualisierungsvorgang später durchführen:

update T set c=c+1 where ID=2;

Bevor wir über den Aktualisierungsvorgang sprechen , jeder kommt zuerst Schauen Sie sich den Ausführungsprozess von SQL-Anweisungen in MySQL an~

Der Ausführungsprozess von SQL-Anweisungen

Wie in der Abbildung gezeigt: Die MySQL-Datenbank ist hauptsächlich in zwei Ebenen unterteilt: Serviceschicht und Storage-Engine-Schicht Service-Schicht: Die Serverschicht umfasst Konnektoren, Abfrage-Caches, Analysatoren, Optimierer und Executoren, einschließlich der meisten Kernfunktionen in MySQL. Alle speicherübergreifenden Engine-Funktionen sind auch in dieser Schicht implementiert, einschließlich gespeicherter Prozeduren. Auslöser, Ansichten usw. Speicher-Engine-Schicht: Die Speicher-Engine-Schicht umfasst gängige MySQL-Speicher-Engines, einschließlich MyISAM, InnoDB und Memory. Die am häufigsten verwendete ist InnoDB, die auch die Standard-Speicher-Engine von MySQL ist.

Einführung in Komponenten in der Serverschicht

• Connector: Erfordert MySQL-Client-Anmeldung, ein Connector ist erforderlich, um den Benutzer und die MySQL-Datenbank zu verbinden, „mysql -u Benutzername -p Passwort“ für MySQL-Anmeldung, Nach Abschluss des TCP-Handshakes authentifiziert der Connector die Anmeldung anhand des eingegebenen Benutzernamens und Passworts.

• Abfrage-Cache: Nach dem Empfang einer Ausführungsanforderung sucht MySQL zunächst im Abfrage-Cache, ob diese SQL-Anweisung zuvor ausgeführt wurde. Die zuvor ausgeführten Anweisungen und Ergebnisse werden in Form eines Schlüsselwerts gespeichert Paare. Der Schlüssel ist die Abfrageanweisung und der Wert ist das Ergebnis der Abfrage. Wenn diese SQL-Anweisung über den Schlüssel gefunden werden kann, wird das SQL-Ausführungsergebnis direkt zurückgegeben. Wenn es nicht im Cache vorhanden ist, wird die nachfolgende Ausführungsphase fortgesetzt. Nach Abschluss der Ausführung werden die Ausführungsergebnisse im Abfragecache abgelegt. Der Vorteil ist eine hohe Effizienz. Die Verwendung des Abfragecaches wird jedoch nicht empfohlen, da bei der Aktualisierung einer bestimmten Tabelle in MySQL alle Abfragecaches ungültig werden. Bei Datenbanken, die häufig aktualisiert werden, ist die Trefferquote des Abfragecaches sehr gering. Hinweis: In MySQL Version 8.0 wurde die Abfrage-Cache-Funktion gelöscht und es gibt keine Abfrage-Cache-Funktion. MySQL Es wird gemäß der SQL-Anweisung analysiert. Der Analysator führt zunächst eine lexikalische Analyse durch, die aus mehreren Zeichenfolgen und Leerzeichen besteht, um zu identifizieren, was die darin enthaltenen Zeichenfolgen sind.

• Grammatische Analyse:

  Führen Sie dann eine grammatikalische Analyse durch. Basierend auf den Ergebnissen der lexikalischen Analyse ermittelt der Syntaxanalysator anhand der grammatikalischen Regeln, ob die eingegebene SQL-Anweisung die MySQL-Syntax erfüllt. Wenn die SQL-Anweisung falsch ist, wird Folgendes angezeigt: Sie haben einen Fehler in Ihrer SQL-Suntax Für die Verarbeitung bestimmt der Optimierer, welcher Index verwendet werden soll und welche Verbindung verwendet werden soll. Die Rolle des Optimierers besteht darin, den effizientesten Ausführungsplan zu ermitteln.

  • Executor: In der Ausführungsphase ermittelt MySQL zunächst, ob eine Berechtigung zum Ausführen der Anweisung vorliegt. Wenn keine Berechtigung vorliegt, wird die Tabelle geöffnet und die Ausführung fortsetzen. Wenn eine Tabelle geöffnet wird, verwendet der Executor die von der Ziel-Engine bereitgestellte Schnittstelle gemäß der Definition der Engine. Bei Tabellen mit Indizes ist die Ausführungslogik ähnlich.
  • Nachdem wir den Ausführungsprozess der SQL-Anweisung verstanden haben, analysieren wir im Detail, wie das obige ausgeführt wird.
  Update-Anweisungsanalyse

  update T set c=c+1 where ID=2;

Beim Ausführen des
• update

  -Vorgangs wird der Abfragecache für diese Tabelle ungültig, sodass diese Anweisung alle zwischengespeicherten Ergebnisse in Tabelle T löscht. Als nächstes führt der Analysator eine Syntaxanalyse und eine lexikalische Analyse durch. Nachdem er weiß, dass es sich um eine Aktualisierungsanweisung handelt, entscheidet der Optimierer, welcher Index verwendet werden soll, und dann ist der Ausführende für die spezifische Ausführung verantwortlich. Er findet zunächst die Zeile und aktualisiert sie .

  Nach unserer üblichen Denkweise finden Sie diesen Datensatz, ändern Sie seinen Wert und speichern Sie ihn. Aber schauen wir uns die Details an. Da es sich dabei um die Änderung von Daten handelt, handelt es sich um Protokolle. Der Aktualisierungsvorgang umfasst zwei wichtige Protokollmodule. Redo-Protokoll (Redo-Protokoll), Bin-Protokoll (Archivprotokoll). Diese beiden Protokolle in MySQL müssen ebenfalls gelernt werden. redo log(重做日志)，bin log(归档日志)。MySQL中的这两个日志也是必学的。

  redo log(重做日志)

  • 在 MySQL 里，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程 IO 成本、查找成本都很高。
    MySQL里使用WAL(预写式日志)技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是 先写日志，再写磁盘。
  • 具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。
  • InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写。

  听完上面对redo log日志的介绍后，小伙伴们可能会问：redo log日志存储在哪？， 数据库信息保存在磁盘上，redo log日志也保存在磁盘上，为什么要先写到redo log中再写到数据库中呢？，redo log日志如果存满数据了怎么办？

  Redo-Protokoll (Redo-Protokoll)

  • Wenn in MySQL jeder Aktualisierungsvorgang auf die Festplatte geschrieben werden muss, muss die Festplatte auch den entsprechenden Datensatz finden und ihn dann aktualisieren Sowohl die Kosten als auch die Suchkosten sind sehr hoch.

  MySQL verwendet die WAL-Technologie (Write-Ahead-Protokollierung). Der vollständige Name von WAL ist Write-Ahead-Protokollierung. Der Kernpunkt ist:

  Schreiben Sie zuerst das Protokoll. und dann Auf die Festplatte schreiben

  .

• Wenn ein Datensatz aktualisiert werden muss, schreibt die InnoDB-Engine den Datensatz zunächst in das Redo-Protokoll 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.
• Das Redo-Protokoll von InnoDB hat eine feste Größe. Es kann beispielsweise als Satz von 4 Dateien konfiguriert werden, wobei jede Datei 1 GB groß ist und insgesamt 4 GB an Vorgängen aufgezeichnet werden können. Beginnen Sie mit dem Schreiben von Anfang an, schreiben Sie bis zum Ende, gehen Sie dann zurück zum Anfang und schreiben Sie in einer Schleife.

Nachdem Freunde sich die obige Einführung zum Redo-Log angehört haben, fragen sie sich vielleicht: Wo wird das Redo-Log gespeichert? , Die Datenbankinformationen werden auf der Festplatte gespeichert, und das Redo-Protokoll wird auch auf der Festplatte gespeichert. Warum sollten sie zuerst in das Redo-Protokoll und dann in die Datenbank geschrieben werden? , Was soll ich tun, wenn das Redo-Log voller Daten ist? Warten. Beantworten wir als nächstes diese Fragen.

Wo wird das Redo-Log gespeichert?

Die InnoDB-Engine schreibt die Datensätze zunächst in das Redo-Log. Dies ist ebenfalls ein Schreibvorgang auf die Festplatte, der sich jedoch vom Aktualisierungsprozess unterscheidet Der Aktualisierungsprozess ist eine zufällige E/A auf der Festplatte, die zeitaufwändig ist. Das Schreiben des Redo-Protokolls ist eine sequentielle E/A auf der Festplatte. Seien Sie effizient.

Redo-Log-Speicherplatz ist behoben, wird er knapp werden?

Machen Sie sich zunächst keine Sorgen, dass im Redo-Log nicht mehr genügend Speicherplatz vorhanden ist, da es recycelt ist. Beispielsweise ist das Redo-Log-Protokoll als Satz von 4 Dateien konfiguriert, jede Datei ist 1 GB groß. Der Prozess des Schreibens ist wie folgt:

Eine kurze Zusammenfassung: Redo-Log ist ein einzigartiger Mechanismus der Innodb-Speicher-Engine, der verwendet werden kann, um abnormale Wiederherstellung

,

Absturzsicher und Redo zu bewältigen kann sicherstellen, dass MySQL neu startet. Wenn nicht festgeschriebene Transaktionen zurückgesetzt werden und übermittelte Transaktionen sicher in der Datenbank abgelegt werden.

Absturzsicher:

Mit dem Redo-Log kann InnoDB sicherstellen, dass zuvor übermittelte Datensätze nicht verloren gehen. Diese Funktion wird als Absturzsicherheit bezeichnet.

🎜binlog (Archivprotokoll)🎜🎜🎜Redo-Protokoll ist ein Protokoll, das nur für die innoDB-Engine gilt. Binlog ist das Protokoll der MySQL-Serverschicht. 🎜🎜🎜Tatsächlich erschien das Bin-Protokoll früher als das Redo-Protokoll, da MySQL zunächst keine InnoDB-Speicher-Engine hatte und es vor 5.5 MyISAM war. Allerdings verfügt MyISAM 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. 🎜

redo log和bin log的总结

• redo log是为了保证innoDB引擎的crash-safe能力，也就是说在mysql异常宕机重启的时候，之前提交的事务可以保证不丢失；(因为成功提交的事务肯定是写入了redo log,可以从redo log恢复)
• bin log是归档日志，将每个更新操作都追加到日志中。这样当需要将日志恢复到某个时间点的时候，就可以根据全量备份+bin log重放实现。 如果没有开启binlog,那么数据只能恢复到全量备份的时间点，而不能恢复到任意时间点。如果连全量备份也没做，mysql宕机，磁盘也坏了，那就很尴尬了。。

redo log和bin log的区别:

• redo log 是 InnoDB 引擎特有的；bin log 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
• redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；bin log 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
• redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

InnoDB引擎部分在执行这个简单的update语句的时候的内部流程

update T set c=c+1 where ID=2;

手动用begin开启事务，然后执行update语句，再然后执行commit语句，那上面的update更新流程之前 哪些是update语句执行之后做的，哪些是commit语句执行之后做的?

事实上，redo log在内存中有一个redo log buffer,binlog 也有一个binlog cache.所以在手动开启的事务中，你执行sql语句，其实是写到redo log buffer和binlog cache中去的(肯定不可能是直接写磁盘日志，一个是性能差一个是回滚的时候不可能去回滚磁盘日志吧)，然后当你执行commit的时候，首先要将redo log的提交状态游prepare改为commit状态，然后就要把binlog cache刷新到binlog日志(可能也只是flush到操作系统的page cache，这个就看你的mysql配置)，redo log buffer刷新到redo log 日志(刷新时机也是可以配置的)。 如果你回滚的话，就只用把binlog cache和redo log buffer中的数据清除就行了。

在update过程中，mysql突然宕机，会发生什么情况?

• 如果redolog写入了，处于prepare状态，binlog还没写入，那么宕机重启后，redolog中的这个事务就直接回滚了。

• 如果redolog写入了，binlog也写入了，但redolog还没有更新为commit状态，那么宕机重启以后，mysql会去检查对应事务在binlog中是否完整。如果是，就提交事务；如果不是，就回滚事务。 (redolog处于prepare状态，binlog完整启动时就提交事务，为啥要这么设计? 主要是因为binlog写入了，那么就会被从库或者用这个binlog恢复出来的库使用，为了数据一致性就采用了这个策略)
  redo log和binlog是通过xid这个字段关联起来的。
  

推荐学习：mysql教程

Das obige ist der detaillierte Inhalt vonLassen Sie uns analysieren, wie die Update-Anweisung von MySQL ausgeführt wird.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!