Mysql-Clustered-Index-Fallanalyse mit langsamer Sortierung

Warum sollte die Mysiam-Engine verwendet werden, wenn viele Selects ausgeführt werden? Vor allem, wenn es einen Index gibt

Dieser Artikel basiert auf einer praktischen Anwendung und analysiert diese.

1. Ich habe online ein interessantes Phänomen gesehen, das unterschiedliche Orderby-Bedingungen und Abfragezeiten ausführt ein echtes Problem in der Praxis? ? Warum?

2. Analyse

a. Es gibt eine Primärschlüssel-ID, einen gemeinsamen Index (ID, Version). ); Die Verwendung des ersteren für die Orderby-Abfrage ist langsam, während die Verwendung des letzteren für die Orderby-Abfrage sehr schnell ist.

3 ist der Hauptindex, und die Felder für die Auswahlabfrage sind ebenfalls vorhanden. Wenn nur eine ID vorhanden ist, wird sie vom Index abgedeckt. Sie müssen nicht auf die physische Festplatte gehen, um die gewünschten Daten abzurufen auf den Index, aber die Abfrage, die schneller sein sollte, ist langsamer. Mysql-Index-Abdeckung

b). , weil Was im Index gespeichert ist, ist die Adresse einer physischen Zeile, und die tatsächlich belegte Datenmenge ist nicht groß. Anders verhält es sich jedoch, wenn es sich um innodb handelt. Alle Daten der Zeile werden unter ihrem Hauptindex gespeichert.

c). Schlussfolgerung:

1. Der Hauptgrund: Die verwendete Innodb-Engine

ist ein Clustered-Index und der Primärschlüssel-ID-Index ist ebenfalls mit der Zeile verknüpft. Andere Daten, daher müssen Sie beim Sortieren entlang der ID viele kleine Blöcke durchqueren, um jede ID abzufragen und zu durchlaufen (unter Mysiam gibt es nicht so viele Daten, es ist schneller, denselben Datenblock zu durchqueren und mehr Zeilen zu durchlaufen). 🎜>

2. Grund: Die Datenmenge in mehreren Bereichen ist relativ groß, das heißt, es gibt viele Menschen, die ihre Familien mitbringen, und die Datenmenge ist relativ groß. Die Datenmenge in jeder Zeile ist groß und nimmt beim Speichern auf der Festplatte viele Blöcke ein

3 Dieses Problem bestand zu diesem Zeitpunkt in der Mysiam-Engine nicht

d). Fazit:

Wenn viele Selects ausgeführt werden, sollte die Mysiam-Engine verwendet werden

Wenn viele Einfügungen und Aktualisierungen ausgeführt werden, sollte die Innodb-Engine verwendet werden 🎜>Weitere Schlussfolgerungen finden Sie unter: Mysql-Index-Zusammenfassung

3. Simulationstest

Stellen Sie die oben genannten Bedingungen wieder her, erstellen Sie zwei Tabellen und steuern Sie die Variablen Andere Bedingungen sind gleich, Primärschlüssel-ID, Primärindex, gemeinsamer Index (id, ver).

1. Erstellen Sie eine neue Tabelle t7, Mysiam-Engine

2. Fügen Sie nach dem Zufallsprinzip 10.000 Daten ein

3. Führen Sie die Abfrageanweisung aus und überprüfen Sie die Zeit

Offensichtlich Der Zeitunterschied ist nicht zu groß, alle sind gleich groß.

4. Erstellen Sie eine neue Tabelle t8, Innodb-Engine

5. Fügen Sie nach dem Zufallsprinzip 10.000 Daten ein

Kurz gesagt, bei der Ausführung der Anweisung gemäß obigem Skript ist die Wartezeit sehr lang. Da es sich um einen Clustered-Index mit einer Primärschlüssel-Index-ID handelt, wird beim Erstellen des Primärschlüssel-Index eine große Anzahl von Zeilendatenblöcken verschoben, und es bleibt Zeit für die Aufteilung und Verschiebung.

Der Vorgang besteht darin, zuerst die Primärschlüssel-Index-ID zu löschen, die Daten einzufügen und dann den Primärschlüssel (ID) hinzuzufügen und dann die Primärschlüssel-Indexstruktur zu erstellen

6. Führen Sie die Abfrageanweisung aus und überprüfen Sie die Zeit

Offensichtlich ist der Zeitunterschied sehr unterschiedlich.

Grund: Beide Anweisungen verwenden einen Clustered-Index, aber der Primärschlüssel umfasst zu viele Blöcke, während der gemeinsame Index ein Sekundärindex ohne darunterliegende Daten, weniger Blöcke und schnelles Durchlaufen ist.

7. Insgesamt dauert die Sortierung der t8-Tabelle (innodb) nach dem Primärschlüsselindex lange, der Rest ist in Ordnung

Fazit zur Zeitsortierung: innodb. Sekundärindex mysiam

Wo liegt das Problem?

1. Der Hauptgrund ist die Sortierung nach dem Primärschlüssel. Die Abfrage erstreckt sich über viele Blöcke auf der Seite, und die Zeit verlängert sich.

2 Bei langen Zeichenfeldern ist der Datenblock nicht groß, was keinen so großen Unterschied verursacht.

Wenn Sie beispielsweise die Felder str1, str2 und str3 in der Tabelle löschen, beträgt die Abfragezeit stark reduziert, und der Unterschied wird nicht offensichtlich sein

Das Obige ist der Inhalt der langsamen Fallanalyse des MySQL-Clustered-Index. Weitere verwandte Inhalte finden Sie in PHP Chinesische Website (www.php.cn)!