Nachteile und sinnvolle Verwendung des MySQL-Datenbankindex

Ein guter Index ist für ein Datenbanksystem besonders wichtig. Der Index ist sozusagen das Herz einer Datenbank. Wenn einer Datenbank ein Index fehlt, hat die Datenbank selbst wenig Bedeutung und unterscheidet sich nicht von einer gewöhnlichen Datei. Lassen Sie uns heute über MySQL-Indizes sprechen. Betrachten wir die Vorteile von B+-Baumindizes in MySQL aus einer detaillierten und praktischen Geschäftsperspektive sowie die Wissenspunkte, auf die wir bei der Verwendung von Indizes achten müssen.

Richtige Verwendung von Indizes

Bei der Arbeit können wir am direktesten feststellen, ob ein Feld in einer Datentabelle indiziert werden muss, indem wir prüfen, ob dieses Feld häufig in unseren where -Bedingungen vorkommt. Aus einer Makroperspektive ist an dieser Denkweise nichts auszusetzen, aus einer langfristigen Perspektive sind jedoch manchmal detailliertere Überlegungen erforderlich, beispielsweise darüber, ob wir mehr als nur einen Index für dieses Feld erstellen müssen. Ist es besser, einen gemeinsamen Index für mehrere Felder zu haben? Am Beispiel einer Benutzertabelle können die Felder in der Benutzertabelle den Namen des Benutzers, die ID-Nummer des Benutzers, die Privatadresse des Benutzers usw. enthalten.

1. Nachteile gewöhnlicher Indizes

Jetzt besteht die Anforderung, den Namen des Benutzers anhand der ID-Nummer des Benutzers zu finden. Zu diesem Zeitpunkt ist die erste Lösung, die mir in den Sinn kommt, einen Index für id_card zu erstellen. Streng genommen ist es ein eindeutiger Index, da die ID-Nummer eindeutig sein muss. Wenn wir also die folgende Abfrage ausführen:

Wählen Sie den Namen aus dem Benutzer aus, wobei ID-Karte = xxx ist.

Der Ablauf sollte wie folgt aussehen:

• Suchen Sie zunächst im ID_Card-Indexbaum nach der Primärschlüssel-ID, die der ID_Card entspricht.
• Durchsuchen Sie den Primärschlüsselindex nach ID und finden Sie den entsprechenden Namen

Aus Leistungssicht ist das Ergebnis in Ordnung, aber aus Effizienzsicht scheint diese Abfrage etwas teuer zu sein, da sie zwei B+-Bäume abruft. Angenommen, die Höhe eines Baums beträgt 3, dann beträgt die Höhe der beiden Bäume 6. Da sich die Stammknoten im Speicher befinden (hier zwei Stammknoten), beträgt die Anzahl der auf der Festplatte auszuführenden IOs 4. Angenommen, die durchschnittliche Zeit für eine zufällige Festplatten-IO beträgt 10 ms, dauert es am Ende 40 ms. Diese Zahl ist durchschnittlich, nicht schnell.

2. Die Fallstricke des Primärschlüsselindex

Da das Problem in der Tabellenrückgabe liegt und daher in beiden Bäumen gesucht werden muss, lautet die Kernfrage, ob die Suche nur in einem Baum möglich ist. Aus geschäftlicher Sicht haben Sie hier möglicherweise einen Durchbruch gefunden. Die ID-Nummer ist eindeutig. Können wir also einen anderen Primärschlüssel als die standardmäßige Auto-Increment-ID verwenden? Wir können den Primärschlüssel auf unsere ID-Nummer festlegen, sodass die gesamte Tabelle nur einen Index benötigt und alle erforderlichen Daten einschließlich unseres Namens über die ID-Nummer gefunden werden können. Auf den ersten Blick scheint dies sinnvoll zu sein, solange wir bei jeder Dateneingabe angeben, dass die ID die ID-Nummer ist. Wenn wir jedoch genauer darüber nachdenken, scheint es ein Problem zu geben.

Hier müssen wir über die Eigenschaften des B+-Baums sprechen. Die Daten des B+-Baums werden auf Blattknoten gespeichert und die Daten werden in Seiten verwaltet. Eine Seite ist 16 KB groß. Was bedeutet das? Selbst wenn wir jetzt eine Datenzeile haben, belegt sie eine 16K-Datenseite. Erst wenn unsere Datenseite voll ist, wird sie auf eine neue Datenseite geschrieben. Die neue Datenseite und die alte Datenseite sind nicht unbedingt physisch zusammenhängend. Und eines ist sehr kritisch: Obwohl die Datenseite physisch diskontinuierlich ist, sind die Daten logisch zusammenhängend.

Vielleicht fragen Sie sich, was das mit der ID-Nummer als Primärschlüssel-ID zu tun hat? Achten Sie dabei auf das Schlüsselwort „fortlaufend“. Die ID-Nummer ist nicht fortlaufend. Was bedeutet das? Wenn wir ein diskontinuierliches Datenstück einfügen, müssen wir die Daten verschieben, um die Kontinuität beizubehalten. Wenn beispielsweise die Originaldaten auf einer Seite 1->5 sind und ein Datenstück 3 eingefügt wird, müssen wir 5 hinter 3 verschieben. Sie können sagen, dass dies nicht viel kostet. Wenn jedoch die neuen Daten 3 dazu führen, dass Seite A voll ist, müssen wir prüfen, ob auf Seite B dahinter Platz ist. Wenn Platz vorhanden ist, sollten die Startdaten von Seite B das Stück sein, das von Seite A übergelaufen ist, und die entsprechenden Daten müssen ebenfalls verschoben werden.

Wenn auf Seite B zu diesem Zeitpunkt nicht genügend Platz vorhanden ist, muss eine neue Seite C beantragt werden, und dann müssen einige der Daten auf diese neue Seite C verschoben werden. Die Beziehung zwischen Seite A und Seite B wird unterbrochen und Seite C wird zwischen den beiden eingefügt. Aus Codesicht dient dies dazu, den Zeiger der verknüpften Liste umzuschalten.

Zusammenfassend lässt sich sagen, dass die Verwendung diskontinuierlicher ID-Nummern als Primärschlüssel zu einem Mehraufwand im Zusammenhang mit der Seitendatenverschiebung, zufälliger E/A und häufigen Anforderungen für neue Seiten führen kann. Wenn wir einen automatisch inkrementierenden Primärschlüssel verwenden, muss die ID sequenziell sein, es darf kein Problem der Datenbewegung aufgrund zufälliger E/A geben und der Einfügeaufwand muss relativ gering sein.

Tatsächlich gibt es noch einen weiteren Grund, warum es nicht empfehlenswert ist, die ID-Nummer als Primärschlüssel zu verwenden: Die ID-Nummer ist als Zahl zu groß und muss daher in Bigint gespeichert werden. Normalerweise reicht int für die Schüler einer Schule aus. Wir wissen, dass eine Seite 16 KB speichern kann. Je mehr Platz ein Index selbst belegt, desto weniger Daten können auf einer Seite gespeichert werden. Daher erfordert die Verwendung von Bigint bei einer bestimmten Datenmenge mehr Seiten als int, was mehr Speicherplatz bedeutet.

3. Speer und Schild des gemeinsamen Index

Aus den beiden obigen Schlussfolgerungen können wir ziehen:

• Versuchen Sie, nicht an den Tisch zurückzukehren
• Die ID-Nummer ist nicht als Primärschlüsselindex geeignet

Daher habe ich natürlich an den gemeinsamen Index gedacht und einen gemeinsamen Index aus [ID-Nummer + Name] erstellt. Achten Sie auf die Reihenfolge des gemeinsamen Index, die dem Prinzip „ganz links“ entsprechen muss. Wenn wir also das folgende SQL ausführen:

Wählen Sie den Namen des Benutzers aus, bei dem die ID-Karte = xxx ist.

Wir können das benötigte Namensfeld abrufen, ohne zur Tabelle zurückkehren zu müssen. Das Problem, dass die ID-Kartennummer selbst zu viel Platz einnimmt, wurde jedoch nicht gelöst. Dies ist ein Problem mit den Geschäftsdaten selbst. Wenn Sie es lösen möchten, können wir einige Konvertierungsalgorithmen verwenden, um die ursprünglichen großen Daten in kleine Daten umzuwandeln, z. B. crc32:

crc32.PrüfsummeIEEE([]byte("341124199408203232"))

Die ID-Nummer, die ursprünglich 8 Byte Speicherplatz benötigte, kann durch einen 4-Byte-CRC-Code ersetzt werden. Daher muss unsere Datenbank ein weiteres Feld crc_id_card hinzufügen und den gemeinsamen Index von [ID-Nummer + Name] in [crc32 (ID-Nummer) + Name] ändern, wodurch der vom gemeinsamen Index belegte Speicherplatz kleiner wird. Doch diese Umstellung hat auch ihren Preis:

• Jeder zusätzliche CRC erfordert mehr CPU-Ressourcen
• Die zusätzlichen Felder verringern zwar den Platzbedarf des Indexes, beanspruchen jedoch selbst auch Platz.
• Es besteht die Wahrscheinlichkeit eines Konflikts im CRC, weshalb wir die Daten abfragen und dann entsprechend der ID-Karte filtern müssen. Die Kosten der Filterung hängen von der Anzahl der doppelten Daten ab. Je mehr Duplikate, desto langsamer die Filterung.

Bezüglich der Speicheroptimierung des gemeinsamen Indexes hier ein kleines Detail. Angenommen, es gibt zwei Felder A und B, die jeweils 8 Bytes und 20 Bytes belegen. Wenn der gemeinsame Index bereits [A, B] ist, müssen wir auch separate Abfragen von B unterstützen. Daher erstellen wir natürlich einen Index für B. Dann beträgt der von den beiden Indizes belegte Speicherplatz 8+20+20=48. Jetzt können wir den Index verwenden, unabhängig davon, ob wir über A oder B abfragen. Wenn das Geschäft es zulässt, können wir dann Indizes [B, A] und A erstellen? Auf diese Weise können wir den Index nicht nur verwenden, um Daten nur über A oder B abzufragen, sondern belegen auch weniger Speicherplatz: 20+8+8=36.

4. Der Präfixindex ist kurz und leistungsstark

Manchmal ist das Feld, das wir indizieren müssen, vom Typ String und dieser String ist sehr lang. Wir möchten diesem Feld einen Index hinzufügen, aber wir möchten nicht, dass dieser Index zu viel Platz einnimmt. In diesem Fall können wir erwägen, einen Präfixindex zu erstellen und einen Index mit dem ersten Teil der Zeichen dieses Felds zu erstellen. Auf diese Weise können wir den Index nutzen und Platz sparen. Hierbei ist zu beachten, dass bei einer hohen Präfixwiederholungsrate ein Geschwindigkeitsunterschied zwischen dem Präfixindex und dem normalen Index bestehen sollte.

alter table xx add index(name(7));#Erstellen Sie einen Index basierend auf den ersten 7 Zeichen des Namens select xx from xx where name="JamesBond"

5. Die Geschwindigkeit und Langsamkeit des eindeutigen Index

Bevor wir über eindeutige Indizes sprechen, wollen wir zunächst die Merkmale gewöhnlicher Indizes verstehen. Wir wissen, dass bei B + -Bäumen die Daten der Blattknoten geordnet sind.

Angenommen, wir möchten jetzt die Daten 2 abfragen. Wenn 2 über den Indexbaum gefunden wird, stoppt die Speicher-Engine die Suche nicht, da es mehrere 2en geben kann. Dies bedeutet, dass die Speicher-Engine die Suche rückwärts auf dem Blattknoten fortsetzt. Stoppt sie, nachdem sie die zweite 2 gefunden hat? Die Antwort ist nein, da die Speicher-Engine nicht weiß, ob sich noch weitere 2en dahinter befinden. Sie muss also weiter rückwärts suchen, bis sie die ersten Daten findet, die nicht 2 sind, sondern 3. Nachdem sie 3 gefunden hat, beendet sie die Suche. Dies ist der Abrufvorgang eines normalen Index.

Der eindeutige Index ist anders. Aufgrund seiner Einzigartigkeit können keine doppelten Daten vorhanden sein. Daher werden unsere Zieldaten nach dem Abrufen direkt zurückgegeben, ohne dass wir wie bei einem normalen Index noch einmal zurücksuchen müssen. Aus dieser Perspektive ist der eindeutige Index schneller als der normale Index. Wenn sich die Daten des normalen Index jedoch alle auf einer Seite befinden, ist er nicht viel schneller. In Bezug auf das Einfügen von Daten sind eindeutige Indizes aufgrund ihrer Eindeutigkeit möglicherweise etwas unterlegen. Bei jedem Einfügen muss ermittelt werden, ob die einzufügenden Daten bereits vorhanden sind, während gewöhnliche Indizes diese Logik nicht erfordern. Darüber hinaus ist ein sehr wichtiger Punkt, dass eindeutige Indizes den Änderungspuffer nicht verwenden (siehe unten).

6. Fügen Sie nicht blind Indizes hinzu

Bei der Arbeit kann Ihnen eine Situation wie diese begegnen: Muss ich diesem Feld einen Index hinzufügen? . Bei diesem Problem beurteilen wir normalerweise, ob die Abfrage dieses Feld verwendet. Wenn dieses Feld häufig in den Abfragebedingungen enthalten ist, können wir das Hinzufügen eines Indexes in Betracht ziehen. Wenn Sie Ihre Beurteilung jedoch ausschließlich auf Grundlage dieser Bedingung vornehmen, fügen Sie möglicherweise einen falschen Index hinzu. Nehmen wir ein Beispiel: Angenommen, es gibt eine Benutzertabelle mit etwa 1 Million Daten. In der Benutzertabelle gibt es ein Geschlechtsfeld, um Männer und Frauen anzugeben, und Männer und Frauen machen etwa die Hälfte der Gesamtzahl aus. Jetzt möchten wir die Informationen aller Männer zählen, und dann fügen wir dem Geschlechtsfeld einen Index hinzu und schreiben das SQL wie folgt:

Wählen Sie * vom Benutzer aus, wobei „Geschlecht“ steht

Wenn nichts Unerwartetes passiert, wählt InnoDB den Geschlechtsindex nicht aus. Wenn der Geschlechtsindex verwendet wird, muss die Tabelle zurückgegeben werden. Welche Konsequenzen hat die Rückgabe, wenn die Datenmenge groß ist? Ich poste mal ein Bild ähnlich dem oben, das kennt sicher jeder:

Das Wichtigste ist eine große Menge an IO. Ein Datenelement benötigt das Vierfache, was ist also mit 500.000 Datenelementen? Das Ergebnis ist vorhersehbar. Daher führt der MySQL-Optimierer in diesem Fall wahrscheinlich einen vollständigen Tabellenscan durch und scannt direkt den Primärschlüsselindex, da dies zu einer besseren Leistung führen kann.

7. Indexfehler

In manchen Fällen kann MySQL den Index aufgrund von unsachgemäßer Verwendung nicht verwenden. Dies passiert normalerweise leicht bei der Typkonvertierung. Vielleicht fragen Sie sich, ob MySQL nicht bereits implizite Konvertierungen unterstützt? Beispielsweise haben wir ein ganzzahliges user_id-Indexfeld. Wir haben bei der Abfrage nicht darauf geachtet und geschrieben:

Wählen Sie xx vom Benutzer aus, wobei user_id="1234"

Beachten Sie, dass dies das Zeichen 1234 ist. Wenn dies geschieht, ist MySQL tatsächlich intelligent genug, um das Zeichen 1234 in die Zahl 1234 umzuwandeln und dann problemlos den Benutzer-ID-Index zu verwenden. Wenn wir jedoch ein user_id-Indexfeld vom Zeichentyp haben oder weil wir bei der Abfrage nicht aufgepasst haben, haben wir es folgendermaßen geschrieben:

Wählen Sie xx vom Benutzer aus, wobei Benutzer-ID = 1234 ist.

Zu diesem Zeitpunkt liegt ein Problem vor und der Index wird nicht verwendet. Sie fragen sich vielleicht, warum MySQL ihn zu diesem Zeitpunkt nicht konvertiert? Reicht es nicht aus, die Zahl 1234 in den Zeichentyp 1234 umzuwandeln? Hier müssen wir die Konvertierungsregeln erklären. Denken Sie beim Vergleichen von Zeichenfolgen und Zahlen daran, dass MySQL Zeichenfolgen in Zahlen umwandelt. Sie fragen sich vielleicht: Warum wird der Index nicht benötigt, nachdem das zeichenartige Feld user_id in eine Zahl umgewandelt wurde? Dies hängt mit der Struktur des B+-Baumindex zusammen. Wir wissen, dass der Index des B+-Baums gegabelt und entsprechend dem Indexwert sortiert ist. Wenn wir den Indexfeldtyp umwandeln, ändert sich der Wert. Wenn der ursprüngliche Wert beispielsweise A ist und eine Ganzzahlumwandlung durchgeführt wird, kann dies einem B-Wert entsprechen (int(A)=B). In diesem Fall kann der Indexbaum nicht verwendet werden, da der Indexbaum gemäß A und nicht B aufgebaut ist, sodass der Index nicht verwendet wird.

Indexoptimierung

1. Puffer ändern

Wir wissen, dass wir beim Aktualisieren eines Datenelements zunächst feststellen müssen, ob sich die Seite dieser Daten im Speicher befindet. Wenn ja, aktualisieren wir direkt die entsprechende Speicherseite. Wenn nicht, können wir nur auf die Festplatte gehen, um die entsprechende Datenseite in den Speicher zu lesen und sie dann zu aktualisieren. Welche Probleme werden dadurch verursacht?

• Der Lesevorgang auf die Festplatte ist etwas langsam.
• Wenn viele Daten gleichzeitig aktualisiert werden, können viele diskrete E/A-Vorgänge auftreten.

Um das Geschwindigkeitsproblem in dieser Situation zu lösen, wurde der Änderungspuffer eingeführt. Lassen Sie sich zunächst nicht vom Wort Puffer täuschen. Der Änderungspuffer befindet sich nicht nur im öffentlichen Pufferpool, sondern wird auch auf der Festplatte gespeichert. Wenn wir nach dem Erstellen des Änderungspuffers während des Aktualisierungsvorgangs feststellen, dass die entsprechende Datenseite nicht im Speicher vorhanden ist, lesen wir die entsprechende Datenseite nicht von der Festplatte, sondern legen die zu aktualisierenden Daten in den Änderungspuffer. Wann werden die Daten im Änderungspuffer mit der Festplatte synchronisiert? Was passiert, wenn zu diesem Zeitpunkt eine Leseaktion erfolgt? Erstens gibt es im Hintergrund einen Thread, der die Änderungspufferdaten regelmäßig mit der Festplatte synchronisiert. Wenn der Thread keine Zeit zum Synchronisieren hatte, aber ein Lesevorgang auftritt, löst er auch ein Ereignis aus, um die Änderungspufferdaten mit der Festplatte zusammenzuführen.

Es ist zu beachten, dass nicht alle Indizes den Changer-Puffer verwenden können. Primärschlüsselindizes und eindeutige Indizes können ihn nicht verwenden. Aufgrund der Eindeutigkeit müssen sie beim Aktualisieren feststellen, ob die Daten vorhanden sind. Wenn sich die Datenseite nicht im Speicher befindet, muss die entsprechende Datenseite von der Festplatte in den Speicher gelesen werden. Dies ist bei normalen Indizes kein Problem und es besteht keine Notwendigkeit, die Eindeutigkeit zu überprüfen. Je größer der Änderungspuffer, desto größer ist der theoretische Nutzen. Denn erstens wird der diskrete Lese-IO reduziert und zweitens müssen mehrere Änderungen auf einer Datenseite nur einmal auf der Platte zusammengeführt werden. Natürlich sind nicht alle Szenarien für den Changer-Buffer geeignet. Wenn Ihr Unternehmen unmittelbar nach dem Update lesen muss, ist der Changer-Buffer kontraproduktiv, da die Zusammenführungsaktion kontinuierlich ausgelöst werden muss, was dazu führt, dass die Anzahl der zufälligen IOs nicht abnimmt, sondern den Aufwand für die Wartung des Changer-Buffer erhöht.

2. Index-Pushdown

Wir haben bereits über gemeinsame Indizes gesprochen. Gemeinsame Indizes müssen dem Prinzip „ganz links“ entsprechen. Das heißt, wenn der gemeinsame Index [A, B] ist, können wir den Index über das folgende SQL verwenden:

Wählen Sie * aus der Tabelle, in der A = "xx"
Wählen Sie * aus der Tabelle, in der A="xx" UND B="xx"

Tatsächlich kann der gemeinsame Index auch das Prinzip des ganz linken Präfixes verwenden, das heißt:

Wählen Sie * aus der Tabelle, wobei A wie "赵%" und B="沪" aussieht.

Hier ist jedoch zu beachten, dass, da ein Teil von A verwendet wird, das obige SQL vor MySQL5.6 sofort zur Tabelle zurückkehrt (mithilfe von select *), nachdem alle Daten abgerufen wurden, bei denen A mit „Zhao“ beginnt, und dann B vergleicht, um festzustellen, ob es „Shanghai City“ ist. Ist das nicht ein bisschen verwirrend? Warum trifft B die Entscheidung nicht direkt auf der Grundlage des gemeinsamen Indexes? Würde das nicht die Anzahl der Tabellenrückgaben verringern? Der Grund für dieses Problem liegt immer noch in der Verwendung des Präfixes ganz links. Infolgedessen kann der Index zwar einen Teil von A verwenden, aber B überhaupt nicht. Das sieht ein bisschen „dumm“ aus. Daher erschien nach MySQL5.6 die Index-Pushdown-Optimierung (Index Condition Pushdown). Mit dieser Funktion ist es, obwohl das Präfix ganz links verwendet wird, auch möglich, nach Daten zu suchen, die A% im gemeinsamen Index erfüllen, während Nicht-B-Daten herausgefiltert werden, wodurch die Anzahl der Tabellenrückgaben erheblich reduziert wird.

3. Aktualisieren Sie die nebenstehende Seite

Bevor wir über das Aktualisieren benachbarter Seiten sprechen, wollen wir über schmutzige Seiten sprechen. Wir wissen, dass wir beim Aktualisieren eines Datenelements zunächst feststellen müssen, ob sich die Seite, auf der sich die Daten befinden, im Speicher befindet. Wenn nicht, müssen wir zuerst die Datenseite in den Speicher lesen und dann die Daten im Speicher aktualisieren. Zu diesem Zeitpunkt werden Sie feststellen, dass die Seite im Speicher die neuesten Daten enthält, die Seite auf der Festplatte jedoch immer noch die alten Daten enthält. Zu diesem Zeitpunkt ist die Seite im Speicher, auf der sich die Daten befinden, eine schmutzige Seite und muss auf die Festplatte geleert werden, um ihre Konsistenz zu wahren. Die Frage ist also: Wann sollte man putzen? Wie viele schmutzige Seiten sollen jedes Mal gelöscht werden? Wenn Sie die Daten nach jeder Änderung leeren, ist die Leistung sehr schlecht. Wenn Sie die Daten nach längerer Zeit leeren, sammeln sich schmutzige Seiten an, was zu weniger verfügbaren Seiten im Speicherpool führt, was sich auf die normale Funktion auswirkt. Daher darf die Leerungsgeschwindigkeit nicht zu hoch sein, sondern muss zeitgerecht erfolgen. MySQL verfügt über einen Bereinigungsthread, der regelmäßig ausgeführt wird, um sicherzustellen, dass er nicht zu schnell ist. Wenn zu viele schmutzige Seiten vorhanden sind oder das Redo-Protokoll fast voll ist, wird sofort die Leerung der Festplatte ausgelöst, um die Aktualität sicherzustellen.

Beim Löschen von Dirty Pages hat InnoDB eine Optimierung: Wenn die Nachbarseiten der zu löschenden Dirty Page ebenfalls Dirty Pages sind, werden sie gemeinsam gelöscht. Dies hat den Vorteil, dass zufällige IOs reduziert werden können. Bei mechanischen Festplatten sollte die Optimierung recht groß sein, aber es kann eine Falle geben. Wenn die Nachbarseiten der aktuellen Dirty Page gemeinsam gelöscht werden und die Nachbarseiten dann aufgrund von Datenänderungen sofort wieder Dirty Pages werden, fühlt sich dies wie ein redundanter Schritt an und es verschwendet Zeit und Geld. Noch schlimmer ist es, wenn der Nachbar der Nachbarseite ebenfalls schmutzig ist. Dann kann diese Kettenreaktion kurzfristige Leistungsprobleme verursachen.

4.MRR

Im tatsächlichen Geschäftsalltag wird uns möglicherweise gesagt, dass wir möglichst viele abdeckende Indizes verwenden und nicht zur Tabelle zurückkehren sollen, da die Rückkehr zur Tabelle mehr IO erfordert und länger dauert. Manchmal müssen wir jedoch zur Tabelle zurückkehren. Die Rückkehr zur Tabelle führt nicht nur zu zu vielen IO, sondern – was noch schlimmer ist – zu vielen diskreten IO.

Wählen Sie * vom Benutzer, wobei die Note zwischen 60 und 70 liegt

Jetzt müssen wir die Benutzerinformationen abfragen, deren Noten zwischen 60 und 70 liegen, so dass unser SQL wie page_no_2 grade page_no_1 die id=1 = id=2 entspricht Grade = 62. s zufälliges IO, das ist page_no_1 . Nach der Verwendung von MRR kehrt der Hilfsindex nicht sofort zur Tabelle zurück, sondern legt die erhaltene Primärschlüssel-ID in einen Puffer und sortiert sie dann. Nach dem Sortieren wird der Primärschlüsselindex sequenziell gelesen, was die diskrete IO erheblich reduziert.

endlich

Oben sind die Fallstricke des MySQL-Datenbankindex und seine sinnvolle Verwendung im Detail beschrieben. Weitere Informationen zu den Fallstricken und der sinnvollen Verwendung von MySQL-Indizes finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!