Eine kurze Erläuterung des Prinzips des flachen Einstiegs und tiefen Ausstiegs von MySQL

1. Übersicht der Seite

Die Daten, die wir in MySQL einfügen, werden letztendlich auf der Seite gespeichert. Beim Design von InnoDB sind die Seiten über eine doppelt verknüpfte Liste verbunden.

Die auf der Seite gespeicherten Datenzeilen sind durch eine einfach verkettete Liste verbunden.

Der Bereich User Records in der obigen Abbildung wird zum Speichern von Zeilendaten verwendet. Warum ist InnoDB so konzipiert? Angenommen, wir kennen das Konzept von Seiten nicht, wie können wir bei einer Abfrage schnell Tausende von Daten abfragen und Ergebnisse dafür erhalten? Wie wir alle wissen, weist MySQL eine gute Leistung auf, aber ohne Seiten können wir die Daten nur einzeln durchlaufen.

Wie ermöglicht diese Seite eine Schnellsuche? Auf der aktuellen Seite können Sie die einzelne verknüpfte Liste durchlaufen, die alle Datensätze in User Records verbindet. Wenn der Datensatz auf der aktuellen Seite nicht gefunden wird, können Sie über den Zeiger auf die nächste Seite schnell zur nächsten Seite springen und dort eine Abfrage durchführen.

2. Infimum und Supremum

Jemand könnte sagen, dass Sie das Problem durch das Durchsuchen User Records nicht gelöst haben, sondern lediglich die Daten in Gruppen aufgeteilt haben. Wenn meine Daten überhaupt nicht auf der aktuellen Seite stehen, muss ich dann trotzdem alle Daten auf der vorherigen Seite durchlaufen? Das ist zu ineffizient.

Natürlich hat MySQL auch dieses Problem berücksichtigt, daher gibt es auf der Seite tatsächlich einen Bereich mit dem Namen The Infimum and Supremum Records .

Mit Infimum Record und Supremum Record muss die Abfrage nun nicht mehr alle User Records auf einer bestimmten Seite durchlaufen, sondern muss nur diese beiden Datensätze mit dem abzufragenden Zieldatensatz vergleichen. Wenn die Daten id = 101 , befindet sie sich offensichtlich nicht auf der aktuellen Seite. Anschließend können Sie über den Weiter-Seitenzeiger zur nächsten Seite springen und diese aufrufen.

3. Seitenverzeichnis verwenden

Jemand könnte fragen: Sind alle Ihre User Records nicht einfach verknüpfte Listen? Auch wenn ich weiß, dass sich die gesuchten Daten auf der aktuellen Seite befinden, muss ich im schlimmsten Fall nicht trotzdem jede Seite 100 Mal durchlaufen, um die gesuchten Daten zu finden? Das nennen Sie effizient?

Ich muss sagen, dass dies tatsächlich ein Problem ist, MySQL hat dieses Problem jedoch bereits berücksichtigt. Ja, das Durchlaufen einzeln ist in der Tat sehr ineffizient. Um dieses Problem zu lösen, fügt MySQL der Seite einen weiteren Bereich hinzu Page Directory .

Wie der Name schon sagt, ist Page Directory ein Verzeichnis mit vielen Steckplätzen, von denen jeder auf einen Datensatz in User Records verweist. Wie Sie sehen, wird alle paar Daten ein Slot erstellt. Tatsächlich entsprechen die Daten, die ich in der Abbildung angegeben habe, sehr genau ihren Einstellungen. Auf einer vollständigen Seite gibt es für jeweils 6 Daten einen Steckplatz.

Das Design des Seitenverzeichnisses erinnert an eine andere Datenstruktur, die Skip-Liste, mit dem Unterschied, dass hier nur eine Indexebene abstrahiert wird.

MySQL erstellt den entsprechenden Slot, wenn neue Daten hinzugefügt werden. Mit Page Directory können Sie eine grobe binäre Suche in den Daten einer Seite durchführen. Was den Grund für die Schwierigkeit betrifft, so enthält Page Directory keine vollständigen Daten und das Ergebnis der binären Suche kann nur ein ungefährer Standort sein. Nachdem dieser ungefähre Standort gefunden wurde, muss zu User Records zurückgekehrt werden, um sie weiter zu durchlaufen und nacheinander abzugleichen.

Diese Effizienz ist jedoch viel höher als die der Originalversion, über die wir gerade gesprochen haben.

4. Das wahre Erscheinungsbild der Seite

Wenn ich die einzelnen Bestandteile und Konzepte der Seite gleich zu Beginn über Bord werfe, kann ich das selbst nicht akzeptieren, da es mir dann doch sehr starr erscheint. Zweitens verstehen Personen, die mit der Seite nicht vertraut sind, möglicherweise nicht, warum die Seite auf diese Weise gestaltet ist. Ich habe Ihnen also das allgemeine Erscheinungsbild der Seite entsprechend einer Reihe von Ideen zum Abfragen von Daten vorgestellt.

Tatsächlich sind auf der Seite noch viele weitere Felder und Bereiche gespeichert, diese haben jedoch keinen Einfluss auf unser Verständnis der Seite. Nachdem wir uns nun ein besseres Bild von der Seite gemacht haben, können wir uns nun ansehen, wie die tatsächliche Seite aussieht.

Das obige Bild zeigt die tatsächliche Zusammensetzung der Seite. Zusätzlich zu dem, was wir zuvor erwähnt haben, gibt es noch einige weitere, über die wir bisher nicht gesprochen haben, wie z. B. File Header , Page Header , Free Space und File Tailer . Sehen wir sie uns einzeln an.

4.1, Dateikopf

Tatsächlich wurde File Header oben bereits besprochen, er hat jedoch nicht diesen Namen. Die oben erwähnten Zeiger auf die vorherige und die nächste Seite gehören tatsächlich zum File Header , und darüber hinaus gibt es noch viele andere Daten.

Tatsächlich sträube ich mich ziemlich dagegen, eine Reihe von Parametern aufzulisten und Ihnen die Größe dieses einen und den Verwendungszweck jenes anderen mitzuteilen. Für diejenigen unter uns, die die Seite im Detail verstehen müssen, reicht es vorerst aus, nur zwei Dinge zu kennen, und zwar:

• FIL_PAGE_PREV
• FIL_PAGE_NEXT

Diese beiden Variablen sind der oben erwähnte Zeiger auf die vorherige Seite und der Zeiger auf die nächste Seite. Sie werden der Einfachheit halber Zeiger genannt. Tatsächlich sind sie der Offset der Seite auf der Festplatte.

4.2 Seitenkopf

Im Vergleich zum File Header sind uns die Daten im Page Header vertrauter. Ich habe hier ein Bild gezeichnet, um den Inhalt detailliert aufzulisten.

Sie sind alle hier aufgeführt, weil das Verständnis der Bedeutung dieser Parameter und warum wir sie festlegen müssen, uns helfen kann, die Prinzipien und die Struktur der Seite besser zu verstehen. Die Details können durch Betrachten der Bilder erklärt werden.

Auch ich möchte hier mal etwas bemängeln. Zu viele Blogs sind in ihrer Schreibweise zu starr. Beispielsweise der Parameter PAGE_HEAP_TOP , viele Blogs nennen einfach HEAP den Heap. Das ist so, als würde man einen Kommentar Init schreiben und ihn Initialisierung nennen. Es ist besser, ihn nicht zu schreiben. Wenn Sie es genauer untersuchen, werden Sie feststellen, dass sich der Heap hier tatsächlich auf Benutzerdatensätze bezieht.

Es gibt zwei Parameter, die etwas verwirrend sein können, nämlich PAGE_N_HEAP und PAGE_N_RECS . Beide geben die Anzahl der Datensätze in den aktuellen User Records an. Der einzige Unterschied besteht darin, dass PAGE_N_HEAP zum Löschen markierte Datensätze enthält, während PAGE_N_RECS alle Daten enthält, die wir tatsächlich abfragen können.

4.3. Infimum- und Supremum-Aufzeichnungen

Wie oben erwähnt, zeichnen Infimum & Supremum Records die maximalen und minimalen Datensätze der aktuellen Seite auf. Tatsächlich ist es nicht genau. Eine genauere Beschreibung ist das Öffnungsintervall der Minimal- und Maximalaufzeichnungen. Denn tatsächlich werden Infimum Records kleiner sein als der Minimalwert auf der aktuellen Seite und Supremum Records werden größer sein als der Maximalwert auf der aktuellen Seite.

4.4 Benutzerdatensätze

Man kann sagen, dass User Records der Teil sind, mit dem wir am häufigsten in Kontakt kommen, denn hier befinden sich letztendlich unsere Daten. Nachdem die Seite initialisiert wurde, befinden sich keine Daten in User Records . Während das System ausgeführt wird und Daten generiert werden, werden die Daten in User Records weiter erweitert und der entsprechende Free Space nimmt allmählich ab.

Wir haben die Konzepte bereits in User Records besprochen. Ich werde hier nur auf einen Punkt eingehen, der mir sehr wichtig erscheint, nämlich die Reihenfolge.

Wir wissen, dass in einem gruppierten Index der Schlüssel tatsächlich in der Reihenfolge Primary Key angeordnet ist. Ist dies auch bei User Records der Fall? Wenn wir neue Daten in User Records einfügen, werden die vorhandenen Daten dann entsprechend der Reihenfolge des Primary Key neu geordnet?

Die Antwort ist nein, da dies die Effizienz der MySQL-Verarbeitung verringert.

Die Daten in User Records werden durch die Ausrichtung des einzelnen verknüpften Listenzeigers garantiert, d. h. die tatsächliche Ausführung der Zeilendaten auf der Festplatte wird entsprechend der Einfügereihenfolge in die Warteschlange gestellt, wobei die ersten Daten vorne und die späteren Daten hinten stehen. Es ist lediglich so, dass eine einzelne verknüpfte Liste zwischen den Zeilendaten in User Records eine Reihenfolge bildet, die gemäß Primary Key angeordnet ist.

In einem Diagramm ausgedrückt sieht es ungefähr so ​​aus:

4.5 Freier Speicherplatz

Dieser Teil wird eigentlich in anderen Modulen verdeckt besprochen. Anfangs sind User Records vollständig leer. Wenn neue Daten eingehen, wird Speicherplatz im Free Space angefordert. Wenn Free Space kein Speicherplatz vorhanden ist, bedeutet dies, dass eine neue Seite angefordert werden muss. Daran ist nichts Besonderes.

4.6 Seitenverzeichnis

Dies unterscheidet sich nicht wesentlich von dem oben Besprochenen, daher werde ich es überspringen.

4.7 Dateitrailer

Dies dient hauptsächlich dazu, zu verhindern, dass die Seite während des Vorgangs zum Leeren auf die Festplatte aufgrund extremer unerwarteter Situationen (Netzwerkprobleme, Feuer, Naturkatastrophen) ausfällt, was zu Dateninkonsistenzen, d. h. zur Bildung schmutziger Seiten, führen kann.

Es gibt nur eine Komponente darin:

V. Fazit

An diesem Punkt haben wir, glaube ich, alles über Seiten besprochen. Ich persönlich denke, dass das Verständnis der zugrunde liegenden Seitenprinzipien uns dabei helfen wird, MySQL benutzerfreundlicher und rationaler zu verwenden, sodass es seine optimale Leistung entfalten kann.

Oben finden Sie eine kurze Erläuterung des detaillierten Inhalts des Shallow-Entry- und Deep-Exit-Prinzips von MySQL. Weitere Informationen zum MySQL-Seitenprinzip finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!