Worauf bezieht sich die schmutzige MySQL-Seite?

Wenn der Inhalt der Speicherdatenseite und der Festplattendatenseite in MySQL unterschiedlich ist, wird diese Speicherseite als schmutzige Seite bezeichnet. Szenario zum Löschen schmutziger Seiten: 1. Wenn das Redo-Protokoll voll ist, unterbricht MySQL alle Aktualisierungsvorgänge und synchronisiert die diesem Teil des Protokolls entsprechenden schmutzigen Seiten mit der Festplatte. 2. Wenn der Systemspeicher nicht ausreicht, werden einige Datenseiten benötigt Wenn es sich um schmutzige Seiten handelt, müssen Sie diese zunächst mit der Festplatte synchronisieren. 3. MySQL geht davon aus, dass die Speicherdaten mit der Festplatte synchronisiert werden, wenn sie im Leerlauf sind Eine Chance. In diesem Fall liegt kein Leistungsproblem vor.

Verschmutzte Seite (Speicherseite)

• Saubere Seite: Die Daten im Speicher und auf der Festplatte sind konsistent

• Verschmutzte Seite: Die Daten im Speicher und auf der Festplatte sind inkonsistent

Warum verschmutzte Seiten? erscheinen

Normalerweise werden bei sehr schnellen Aktualisierungsvorgängen alle in den Speicher und in die Protokolle geschrieben. Es wird nicht sofort mit der Festplattendatenseite synchronisiert. Zu diesem Zeitpunkt sind die Inhalte der Speicherdatenseite und der Festplattendatenseite inkonsistent, was wir als schmutzige Seite bezeichnen. 不会马上同步到磁盘数据页,这时内存数据页跟磁盘数据页内容不一致,我们称之为脏页。

这里面就涉及 mysql 的内存管理机制

内存管理机制简述

缓冲区中包含这三大类列表。分别为：LRUList、FreeList、FlushList。

在数据库刚启动时，LRUlist中没有数据页。FreeList存放空闲页。

• 当需要读取某个页时，会从FreeList中获取一个空闲页，读入数据后，放入LRUlist中

• 如果FreeList中没有空闲页了，那么根据LRU算法淘汰Lru列表中末位的页

• 当LRUlist中的页被修改后，页就变成了脏页，这个页也会被加入FlushList中

注意：这时这个页既在LRUlist中，又在FlushList中。

总结：LRUList（管理已经被读取的页）和FreeList（管理空闲的页）用来管理页的可用性；FlushList（管理脏页）用来管理脏页的刷新

在脏页数据同步到磁盘过程中，如果对该磁盘数据页执行 SQL 语句。执行速度就会变慢

数据修改和读取只依赖缓冲区行不行

假如只有缓存区用来进行数据修改和读取，一旦数据库宕机，缓存区中的数据将会丢失。因此，MySQL利用之前介绍过的redo日志来实现在异常重启时的数据恢复。

以简单的方式解释，就是在更新缓冲区之前，将操作记录在redo log中，以确保在出现异常重启的情况下，仍然可以恢复缓冲区中的数据。

为什么脏页一定要刷新

• 上面说了 数据只放在缓冲区，会出现数据库宕机，内存数据丢失。所以需要刷新到磁盘。

• redo log如果无限大或者有许多个文件的话，系统中有大量的修改操作，一旦宕机，恢复的时间也会非常长。

所以自然而然，我们就一定需要把内存中的脏页按照某种规则刷新到磁盘中，有了刷新这个操作，缓冲区的大小问题和redo log的大小问题都可以解决。

• 缓冲区不需要无限大了，因为可以持久化到磁盘

• 因为一旦redo log中的数据被持久化到磁盘上，对应的部分数据就可以被释放，所以无需设置redo log过大。

刷脏页有下面4种场景

undefined会造成的影响

如果是 redo log 写满了

要尽量避免redo log 写满。否则整个系统的更新都会停止。此时写的性能变为 0，必须等待该日志对应脏页同步完成

Hierbei handelt es sich um den Speicherverwaltungsmechanismus von MySQL🎜

🎜Kurze Beschreibung des Speicherverwaltungsmechanismus🎜

🎜Der Puffer enthält diese drei Kategorien von Listen. Dies sind: LRUList, FreeList, FlushList. 🎜🎜Beim ersten Start der Datenbank gibt es keine Datenseite in der LRUlist. FreeList speichert kostenlose Seiten. 🎜🎜🎜🎜Wenn eine Seite gelesen werden muss, wird eine freie Seite von FreeList abgerufen. Nach dem Lesen der Daten wird sie in die LRUlist aufgenommen.🎜🎜🎜🎜Wenn in FreeList keine freien Seiten vorhanden sind, wird dies in der LRU-Liste der Fall sein gemäß dem LRU-Algorithmus eliminiert werden Die Seite unten 🎜🎜🎜🎜Wenn die Seite in der LRUlist geändert wird, wird die Seite zu einer schmutzigen Seite und diese Seite wird auch zur FlushList hinzugefügt🎜🎜🎜🎜🎜Hinweis: Bei Dieses Mal befindet sich diese Seite bereits in der LRUlist. Wieder in der FlushList. 🎜🎜🎜Zusammenfassung: LRUList (gelesene Seiten verwalten) und FreeList (freie Seiten verwalten) werden zum Verwalten der Seitenverfügbarkeit verwendet; FlushList (verschmutzte Seiten verwalten) wird zum Verwalten der Aktualisierung schmutziger Seiten verwendet. 🎜🎜Datensynchronisierung auf schmutzigen Seiten Wenn beim Wechseln zur Festplatte die SQL-Anweisung auf der Datenseite der Festplatte ausgeführt wird. Die Ausführungsgeschwindigkeit wird langsamer🎜

🎜Ist es möglich, sich für die Datenänderung und das Lesen nur auf den Puffer zu verlassen?🎜

🎜Wenn nur der Pufferbereich für die Datenänderung verwendet wird und Lesen: Sobald die Datenbank ausfällt, gehen die Daten im Cache-Bereich verloren. Daher verwendet MySQL das zuvor eingeführte Redo-Protokoll, um bei einem abnormalen Neustart eine Datenwiederherstellung zu erreichen. 🎜🎜Einfach erklärt: Der Vorgang wird im Redo-Log aufgezeichnet, bevor der Puffer aktualisiert wird, um sicherzustellen, dass im Falle eines abnormalen Neustarts die Daten im Puffer weiterhin wiederhergestellt werden können. 🎜

🎜Warum schmutzige Seiten aktualisiert werden müssen🎜🎜🎜🎜🎜Oben wurde gesagt, dass die Daten nur im Puffer abgelegt werden und es zu Datenbankausfallzeiten und Speicher kommt Datenverlust. Es muss also auf die Festplatte geleert werden. 🎜🎜🎜🎜Wenn das Redo-Protokoll unendlich groß ist oder viele Dateien enthält, gibt es eine große Anzahl von Änderungsvorgängen im System, und wenn es einmal ausfällt, ist die Wiederherstellungszeit sehr lang. 🎜🎜🎜🎜Natürlich müssen wir die schmutzigen Seiten im Speicher nach bestimmten Regeln auf die Festplatte leeren. Mit dem Aktualisierungsvorgang können das Problem der Puffergröße und das Problem der Redo-Log-Größe gelöst werden. 🎜🎜🎜🎜Der Puffer muss nicht unendlich sein, da er auf der Festplatte gespeichert werden kann🎜🎜🎜🎜Denn sobald die Daten im Redo-Log auf der Festplatte gespeichert werden, kann der entsprechende Teil der Daten dort freigegeben werden Es ist nicht erforderlich, das Redo-Protokoll einzurichten. Zu groß. 🎜🎜🎜

🎜Es gibt unten vier Szenarien für das Bürsten schmutziger Seiten🎜🎜🎜undefiniert🎜Die Auswirkungen, die es haben wird🎜🎜🎜🎜Wenn das Redo-Log voll ist🎜🎜🎜Bitte versuchen Sie es Um dies zu vermeiden, Redo-Log ist voll. Andernfalls wird die Aktualisierung des gesamten Systems gestoppt. Zu diesem Zeitpunkt beträgt die Schreibleistung 0 und Sie müssen warten, bis das Protokoll der Dirty Page-Synchronisierung abgeschlossen ist, bevor es aktualisiert werden kann Die Ausführung von SQL-Anweisungen ist sehr langsam. 🎜

Das obige ist der detaillierte Inhalt vonWorauf bezieht sich die schmutzige MySQL-Seite?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!