Mehrere Prinzipien der MySQL-Indexoptimierung
1. Der MySQL-Index minimiert den Vorgang der Rückkehr zur Tabelle.
Beispielsweise enthält eine Tabelle Felder wie ID, Name und Geschlecht, aber der Name ist nur indiziert (ohne den Index abzudecken). Wählen Sie * aus der Tabelle aus, wobei Name = „a“ ist. Diese SQL-Abfrage umfasst die Rückkehr zur Tabelle It findet zuerst den Blattknoten mit dem Namen = „a“ (der die ID der Daten enthält) und geht dann zurück, um alle Daten der ID gemäß der ID zu finden, was einem erneuten Durchlaufen des Index entspricht, um die zu finden Wert des Geschlechtsfeldes. Wenn Sie diese hintere Tabelle lösen möchten, erstellen Sie einen abdeckenden Index (gemeinsamen Index). Das heißt, Name und Geschlecht werden beim Erstellen des Index zu einem Index zusammengefasst, sodass Sie den gruppierten Index für Name und Geschlecht gleichzeitig finden können (den Standard ist der Primärschlüssel, wenn nicht festgelegt, nicht null oder eindeutiges Feld): Es enthält alle Felder der Daten.
2. Wie werden die großen und kleinen Tabellen beim Abfragen der zugehörigen Tabelle platziert? (Verwenden Sie kurze Indizes, um die E/A-Effizienz beim Indexzugriff zu verbessern.)
Der kleine Tisch treibt den großen Tisch an. Warum treibt der kleine Tisch den großen Tisch schnell an?
2.1, Multi-Table-Join, ähnlich der Schleifenverschachtelung, die äußere Schleife ist 5-mal und die innere Schleife ist 1000-mal. Wenn das Ergebnis der kleinen Schleife außerhalb liegt, stellen Sie die Datenbankverbindung nur 5-mal her und führen Sie 5000 Vorgänge aus. Wenn Das große Schleifenergebnis Draußen muss die Datenbank 1000 Mal verbunden werden, was Ressourcen verschwendet und den Verbrauch erhöht.
Wählen Sie beispielsweise die Abteilungstabelle dept (id) (die Tabelle mit großen Datenmengen) und die Mitarbeitertabelle emp (id, dept_id) * aus emp, dept aus, wobei emp.dept_id=dept.id Beim Abfragen der Datenbank ist dept.id Priorität gegeben und dann mit emp.dept_id kombiniert, um Gleichheit zu erzielen, was den Übereinstimmungsbereich einschränkt und die Sucheffizienz verbessert.
3. Die Like-Abfrage folgt dem Matching-Prinzip ganz links.
Versuchen Sie, keine Berechnungen für das abgefragte Feld durchzuführen, die den Wert nicht ermitteln können. Beispielsweise führt die Fuzzy-Suche nicht unbedingt zu einem Indexfehler. Wir können die zugrunde liegende Datenstruktur des Index analysieren. Es handelt sich um eine B+-Baumstruktur, und B+-Bäume haben eine Merkmal: Der Wert des linken Teilbaums ist kleiner als der Wert des rechten Teilbaums. Dies ist eine Möglichkeit, die von Ihnen im Baum gespeicherten Daten entsprechend der Reihenfolge eines bestimmten Bereichs anzuordnen. Wenn wir einen bestimmten Wert abfragen, wird der Wert angezeigt Der Hash wird zuerst berechnet. Nach der Berechnung einfach aus dem Baum abgleichen. Wenn % von like am Anfang steht, z. B. (%es), wissen Sie nicht, wie Sie im Baum nach Daten suchen sollen, sodass Sie sie nicht finden können. Wenn Sie zum Index gehen möchten, müssen Sie dies tun Folgen Sie der Übereinstimmung ganz links. Darüber hinaus sind einige Werte, die berechnet werden müssen, unsicher, sodass Sie nicht herausfinden können, in welchen Bereich des Baums sie fallen, sodass Sie nicht zum Index gehen können.
4. Beim Abfragen in Seiten wird das Limit am Ende immer langsamer;
Der Grund dafür, dass es immer langsamer wird, liegt darin, dass zum Beispiel bei Limit 10, 10 die ersten 10 Artikel gescannt, verworfen und dann 10 Artikel gefunden werden müssen, dann bei Limit 100, 10 100 Artikel gescannt werden müssen. Je mehr Scans, desto mehr io wird es geben. Wenn Sie also möchten, können Sie mit der Methode zum Index gehen. Beispielsweise ist die Tabelle selbstinkrementierend. Wenn wir limit100000, 10 abfragen, können wir den Namen aus emp und die ID auswählen > (Die Größe des letzten Mals beträgt hier beispielsweise 10.000) ist auf 10 begrenzt, sodass die Effizienz sehr hoch ist
5. Verwenden Sie so oft wie möglich Varchar anstelle von Char.
char是一种固定长度的类型，varchar则是一种可变长度的类型
尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间，
其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。6. Versuchen Sie, die Verwendung von or zu vermeiden, um Bedingungen in der where-Klausel zu verbinden.
Wenn ein Feld einen Index hat und ein Feld keinen Index hat, führt dies dazu, dass die Engine die Verwendung des Index aufgibt und einen vollständigen Tabellenscan durchführt.
7. Vermeiden Sie die Verwendung des Operators != oder <> in der where-Klausel, da die Engine sonst die Verwendung des Index aufgibt und einen vollständigen Tabellenscan durchführt.
8. Führen Sie keine Spaltenoperationen aus: wobei Alter + 1 = 10;
Jeder Vorgang an der Spalte führt zu einem Tabellenscan, der Datenbank-Tutorialfunktionen, Berechnungsausdrücke usw. umfasst und den Index ungültig macht.
9. Lösen Sie das Problem, dass der Zeichensatz des zugehörigen Felds beim Abfragen der gemeinsamen Tabelle unterschiedlich ist (Fehler wird gemeldet).
10. Vermeiden Sie Unterabfragen so weit wie möglich und optimieren Sie Unterabfragen für Abfragen mit mehreren Tabellen.
Im Allgemeinen ist die Verbindungsabfrage effizienter, da die Unterabfrage die Daten mehrmals durchläuft, während die Verbindungsabfrage nur einmal durchläuft. Wenn die Datenmenge jedoch gering ist, ist die Unterabfrage einfacher zu steuern. Wenn die Datenmenge jedoch groß ist, ist der Unterschied zwischen beiden offensichtlich: Bei einer großen Datenmenge muss die Verbindungsabfrage schneller sein.
11. Warum ist es nicht geeignet, Indizes zu Feldern mit geringer Unterscheidung hinzuzufügen? Wie speichert der Index B+?
MySQL ist ein B + -Speicher. Der Index dient dazu, die Effizienz des Datenabrufs zu verbessern und die Geschwindigkeit von Festplatten-IO zu verringern, da unsere Daten auf der Festplatte vorhanden sind um eine der Festplatten-Io-Zeiten zu verkürzen und so die Leistung zu verbessern. Warum dann nicht B-Tree, sondern B+ verwenden, er muss eine Funktion unserer relationalen MySQL-Datenbank selbst berücksichtigen, um nicht zu sagen, dass B-Tree nicht gut ist, es ist besser, B-Tree als MangoDB zu verwenden, die Technologie ist nicht gut oder schlecht, also ist es hier B+. Die Vorteile sind: 1. Wenn wir eine Bereichssuche durchführen können, ist dies bequemer, da der B+-Baum nur die Blattknoten durchlaufen muss, um die Durchquerung des gesamten Baums zu realisieren, während der B Der Baum muss vom Wurzelknoten von oben nach unten durchlaufen. 2. Reduzieren Sie die Anzahl der Festplatten-IOs, da B+-Nicht-Blattknoten Daten in einer Indexstruktur speichern und Blattknoten tatsächliche Daten speichern, während B-Baum-Nicht-Blattknoten und Blattknoten speichern tatsächliche Daten. MySQL hat eine Seitengröße von 16 KB, und B + -Bäume sind Nicht-Blatt-Bäume. Je kleiner das Datenvolumen des Knotens ist, desto geringer ist die Höhe und desto geringer ist die Anzahl der Festplatten-IO-Zugriffe möglich;
Wenn ein Feld mit einem geringen Diskriminierungsgrad als Index verwendet wird, kann dies dazu führen, dass jeder Zweig des gesamten B + -Baums durchlaufen wird. Wenn Sie beispielsweise einen Index mit Geschlecht sowie Männern und Frauen zum Feld hinzufügen, bedeutet dies, dass die Daten von Männern und Frauen verwendet werden Frauen werden genauso existieren, also wird es existieren Im B+-Baum werden viele Zweige in einem Speicher gespeichert, was zu Leistungseinbußen führt.