MySQL-Optimierung: So schreiben Sie hochwertige SQL-Anweisungen

Vorwort

Im Internet gibt es zahlreiche Informationen und Methoden zur Datenbankoptimierung. Allerdings ist die Qualität vieler dieser Informationen unterschiedlich, die Zusammenfassungen sind teilweise nicht gründlich und die Inhalte redundant. In diesem Artikel erhalten Sie eine detaillierte Einführung in 26 Optimierungsvorschläge. Schauen wir sie uns einmal an.

1. Versuchen Sie bei SQL-Abfragen nicht die vollständige Suche mit „select *“, sondern „select + bestimmte Felder“ zu verwenden.

Gegenbeispiel:

wähle * vom Studenten;

Positives Beispiel:

Wählen Sie ID, Name und Alter des Schülers aus;

Grund:

• Um Ressourcen zu sparen und den CPU-, IO- und Netzwerk-Overhead zu reduzieren, werden nur die erforderlichen Felder ausgefüllt.
• Bei Abfragen mit „Select *“ kann der überdeckende Index nicht verwendet werden, was zu einer Tabellenrückgabeabfrage führt.
• Durch die Verwendung spezifischer Felder können die Auswirkungen von Änderungen in der Tabellenstruktur reduziert werden.
  

2. Verwenden Sie vorbereitete Anweisungen für Datenbankoperationen

Grund:

• Vorkompilierte Anweisungen können Pläne wiederverwenden und die für die SQL-Kompilierung erforderliche Zeit verkürzen
• Kann das durch dynamisches SQL verursachte SQL-Injection-Problem lösen
• Die reine Parameterübergabe ist effizienter als die Übergabe von SQL-Anweisungen.
• Dieselbe Anweisung kann einmal analysiert und mehrfach verwendet werden, um die Verarbeitungseffizienz zu verbessern
  

3. Verwenden Sie keine Insert-Anweisungen ohne Feldliste

Gegenbeispiel:

in Werte einfügen ('a', 'b', 'c');

Positives Beispiel:

in t(a, b, c) Werte einfügen ('a', 'b', 'c');

Grund:

• Bei Einfügeanweisungen ohne Feldnamen ist es schwierig zu unterscheiden, welchen Feldern sie entsprechen, und es können nur vollständige Werte eingefügt werden, was die Lesbarkeit beeinträchtigt.
• Sobald sich die Tabellenstruktur ändert, ist eine Anpassung schwierig.
  

4. Vermeiden Sie die Verwendung von oder zum Verbinden von Bedingungen in der Where-Klausel

Beispiel: Erstellen Sie eine neue Benutzertabelle mit einem gemeinsamen Index userId. Die Tabellenstruktur ist wie folgt:

CREATE TABLE `Benutzer` (  
`id` int(11) NICHT NULL AUTO_INCREMENT,  
`user_id` int(11) NICHT NULL,  
`Alter` int(11) NICHT NULL,  
`name` varchar(30) NICHT NULL,  
Primärschlüssel (`id`),  
SCHLÜSSEL `idx_userId` (`userId`)
)ENGINE=InnoDB STANDARD-CHARSET=utf8;

Abfrage von Benutzern, deren Benutzer-ID 1 ist oder deren Alter 18 Jahre ist

Gegenbeispiel:

Wählen Sie ID, Benutzer-ID, Alter und Namen des Benutzers aus, wobei Benutzer-ID = 1 oder Alter = 18 ist.

Positives Beispiel:

# Verwenden von union all 
wähle ID, Benutzer-ID, Alter, Name vom Benutzer, bei dem Benutzer-ID=1, alles vereinige, wähle * vom Benutzer, bei dem Alter = 18
# Oder schreiben Sie zwei separate SQL-Anweisungen: select id, user_id, age, name from user where userid=1; select * from user where age = 18

Grund:

• Die Verwendung von oder kann den Index ungültig machen, was zu einem vollständigen Tabellenscan führt.
• Für oder + Felder ohne Index, wie z. B. Alter oben, wird angenommen, dass der Benutzer-ID-Index verwendet wird. Wenn es jedoch um die Abfragebedingung Alter geht, muss die gesamte Tabelle gescannt werden. Dazu sind drei Schritte erforderlich: vollständiger Tabellenscan + Indexscan + Zusammenführen. Wenn mit einem vollständigen Tabellenscan begonnen wird, kann dies in einem Scan durchgeführt werden.
• MySQL verfügt über einen Optimierer. Aus Effizienz- und Kostengründen kann der Index bei einer ODER-Bedingung ungültig werden, was sinnvoll erscheint.

5. Wenn Sie Where-Bedingungen zum Abfragen verwenden, beschränken Sie die abzufragenden Daten, um die Rückgabe redundanter Zeilen und eine implizite Konvertierung von Datentypen zu vermeiden.

Angenommen, die ID ist vom Typ int, fragen Sie die Daten mit der ID = 1 ab

Gegenbeispiel:

Wählen Sie ID und Name des Studenten aus, wobei ID = „1“ ist.

Positives Beispiel:

Wählen Sie ID und Name des Studenten aus, wobei ID = 1;

Grund:

• Fragen Sie nur die Daten ab, die Sie benötigen, vermeiden Sie die Rückgabe unnötiger Daten und sparen Sie Kosten.
• Implizite Konvertierung führt zur Ungültigkeit des Index
  

6. Führen Sie Ausdrucksoperationen oder Funktionskonvertierungen für Felder in der Where-Klausel aus. Dadurch gibt das System die Verwendung von Indizes auf und führt einen vollständigen Tabellenscan durch

Nehmen wir an, dass das Feld „Alter“ der Benutzertabelle indiziert ist, und fragen Sie dessen Daten ab

Gegenbeispiel:

Wählen Sie Name und Alter des Benutzers aus, wobei Alter - 1 = 20;

Positives Beispiel:

Wählen Sie Name und Alter des Benutzers aus, wobei Alter = 21 ist.

Grund:

• Dem Alter wird ein Index hinzugefügt, aber aufgrund der darauf ausgeführten Abfrage ist der Index nicht wirksam, was die Effizienz erheblich verringert.
  

7. Vermeiden Sie möglichst die Verwendung der Operatoren != oder <> in der Where-Klausel. Andernfalls gibt die Engine die Verwendung des Indexes auf und führt einen vollständigen Tabellenscan durch.

(Anwendbar in MySQL)

Gegenbeispiel:

Wählen Sie Alter und Namen des Benutzers aus, wobei Alter <> 18 ist.

Positives Beispiel:

# Sie können zwei separate SQL-Anweisungen schreiben: select age,name from user where age < 18;
Wählen Sie Alter und Namen des Benutzers aus, sofern das Alter > 18 ist.

Grund:

• Die Verwendung von != und <> macht den Index wahrscheinlich ungültig
  

8. Zur Abfrageoptimierung sollten Sie die Erstellung von Indizes für die an „Where“ und „Order By“ beteiligten Spalten in Erwägung ziehen, um vollständige Tabellenscans möglichst zu vermeiden.

Gegenbeispiel:

Wählen Sie Name, Alter und Adresse des Benutzers aus, wobei Adresse = „Alter“, sortiert nach Alter;

Positives Beispiel: Index hinzufügen und dann abfragen

alter table user add index idx_address_age (Adresse, Alter)

9. Erwägen Sie die Verwendung von Standardwerten anstelle von Null in Where-Klauseln

Gegenbeispiel: (Dadurch werden alle Daten überprüft)

Wählen Sie Benutzer-ID, Name und Alter des Benutzers aus, bei dem das Alter nicht null ist.

Positives Beispiel:

# Setzen Sie das Tabellenfeld Alter auf 0 als Standardwert statt auf null
Wählen Sie Benutzer-ID, Name und Alter des Benutzers aus, bei dem das Alter > 0 ist.
1
2

Grund:

• Wenn null oder ungleich null verwendet wird, bedeutet dies nicht, dass der Index nicht verwendet wird. Dies hängt mit der MySQL-Version und den Abfragekosten zusammen.
• Wenn der MySQL-Optimierer feststellt, dass die Kosten für die Verwendung des Index höher sind als die Kosten für die Nichtverwendung des Index, wird er den Index definitiv aufgeben. Diese Bedingungen !=, > isnull, is not null machen den Index häufig ungültig. Tatsächlich liegt dies daran, dass die Abfragekosten im Allgemeinen hoch sind und der Optimierer den Index automatisch aufgibt.
• Wenn der Nullwert durch den Standardwert ersetzt wird, ist es oft möglich, den Index zu verwenden, und die Bedeutung ist relativ klar.
  

10. Wenn das Abfrageergebnis nur einen Datensatz enthält oder nur ein Datensatz benötigt wird (möglicherweise der Maximal-/Minimalwert), wird empfohlen, das Limit 1 zu verwenden

Angenommen, es gibt einen Studententisch und wir möchten eine Person namens Tom finden.

CREATE TABLE `student` (  
`id` int(11) NICHT NULL,  
`name` varchar(50) DEFAULT NULL,  
`Alter` int(11) DEFAULT NULL,  
`date` Datum/Uhrzeit DEFAULT NULL,  
`sex` int(1) DEFAULT NULL,  
PRIMÄRSCHLÜSSEL (`id`)
)ENGINE=InnoDB STANDARD-CHARSET=utf8mb4;

Gegenbeispiel:

Wählen Sie ID, Name vom Studenten, wobei Name = "Tom"

Positives Beispiel

Wählen Sie ID, Name vom Mitarbeiter, wobei Name = ‚Tom‘, Limit 1;

Grund:

Nach dem Hinzufügen der Paging-Grenze 1 wird der Scan nicht fortgesetzt, sobald ein entsprechender Datensatz gefunden wird, und die Effizienz wird erheblich verbessert.
Wenn Name der einzige Index ist, muss kein Limit 1 hinzugefügt werden, da das Limit hauptsächlich dazu dient, einen vollständigen Tabellenscan zu verhindern und so die Leistung zu verbessern. Wenn eine Anweisung selbst vorhersagen kann, dass kein vollständiger Tabellenscan erforderlich ist, gibt es mit oder ohne Limit kaum einen Leistungsunterschied.

11. Optimieren Sie Limit-Paging-Anweisungen

Beim täglichen Paging verwenden wir normalerweise ein Limit, um dies zu erreichen. Wenn der Offset jedoch besonders groß ist, verringert sich die Abfrageeffizienz.

Gegenbeispiel:

Wählen Sie ID, Name, Alter aus dem Studentenlimit 10000,10

Positives Beispiel:

# Lösung 1: Gibt den maximalen Datensatz (Offset) der letzten Abfrage zurück
Wählen Sie ID und Namen des Studenten, wobei die ID > 10.000, Limit 10, ist.

# Lösung 2: Sortieren nach + Index, wähle ID, Name vom Studenten, Sortieren nach ID-Limit 10000,10;

# Option 3: Begrenzen Sie die Seitenzahl, sofern das Unternehmen dies zulässt:

Grund:

• Wenn der Offset groß ist, ist die Abfrageeffizienz geringer, da MySQL den Offset nicht überspringt und die nachfolgenden Daten direkt abruft, sondern zuerst den Offset + die Anzahl der abzurufenden Einträge addiert und dann die Daten im vorherigen Offsetabschnitt verwirft, bevor es zurückkehrt.
• Wenn Sie Optimierungslösung 1 verwenden, wird der letzte maximale Abfragedatensatz (Offset) zurückgegeben, sodass der Offset übersprungen werden kann, was die Effizienz erheblich verbessert.
• Lösung 2 verwendet „Order by + Index“, was ebenfalls die Abfrageeffizienz verbessern kann.
• Bei Option 3 empfiehlt es sich, mit dem Betrieb abzuklären, ob eine nachträgliche Überprüfung der Paging-Funktion notwendig ist. Weil die meisten Benutzer nicht zu viele Seiten zurückblättern.
  

12. Vermeiden Sie die Rückgabe zu vieler Daten an den Client und verwenden Sie Limit Paging

Nehmen wir an, die Geschäftsanforderung besteht darin, dass der Benutzer die Anzeige der Filmdaten anfordert, die er im letzten Jahr angesehen hat.

Gegenbeispiel:

# Alle Daten auf einmal abfragen select * from LivingInfo 
wobei watchId = useId 
und watchTime >= Date_sub(jetzt(),Intervall 1 J)

Positives Beispiel:

# Paginierungsabfrage wählen Sie * aus LivingInfo 
wobei watchId = useId 
und watchTime>= Date_sub(jetzt(),Intervall 1 J) 
Grenzoffset, Seitengröße

# Wenn es sich um Front-End-Paging handelt, können Sie zuerst die ersten 200 Datensätze abfragen, da der durchschnittliche Benutzer nicht zu viele Seiten nach unten scrollen sollte. Wählen Sie * aus LivingInfo aus. 
wobei watchId = useId 
und watchTime>= Date_sub(jetzt(),Intervall 1 J) 
Grenze 200;

13. Like-Aussagen optimieren

Bei der unscharfen Schlüsselwortsuche mit LIKE besteht die Möglichkeit, dass LIKE den Index ungültig macht.

Gegenbeispiel:

Wählen Sie * aus Student
WO Name WIE '%strive_day';
-- Oder verwenden Sie % zum Umschließen von SELECT * FROM student
WO Name WIE '%strive_day%';

Positives Beispiel:

Wählen Sie * aus Student
WO Name WIE 'strive_day%';

Grund:

• Wenn Sie „%“ davor setzen, wird die Indexsuche nicht verwendet.
• Wenn Sie nach einem Schlüsselwort ein % setzen, wird die Suche über den Index durchgeführt.
• Das Umschließen von Schlüsselwörtern mit % führt nicht zu einer Indexsuche.
• Ohne führendes %, nur nachfolgendes % führt zur Indexabfrage
  

14. Vermeiden Sie die Verwendung integrierter MySQL-Funktionen für Indexspalten

Beispiel: Abfrage von Benutzern, die sich in den letzten sieben Tagen angemeldet haben (vorausgesetzt, das Feld loginTime ist indiziert)

Gegenbeispiel:

SELECT * FROM system_user Benutzer
WHERE Date_ADD(Benutzer.Anmeldezeit,Intervall 7 TAGE) >= jetzt();

Positives Beispiel:

SELECT * FROM system_user Benutzer
WO user.loginTime >= Date_ADD(JETZT(),INTERVALL - 7 TAGE);

Grund:

• Wenn Sie MySQL-integrierte Funktionen auf die Indexspalte anwenden, wird der Index ungültig
• Wenn die Indexspalte keine eingebaute Funktion hat, wird die Indexabfrage ausgeführt
  

15. Achten Sie bei Verwendung eines gemeinsamen Index auf die Reihenfolge der Indexspalten. Befolgen Sie im Allgemeinen das Übereinstimmungsprinzip ganz links

Angenommen, es gibt einen gemeinsamen Index (Benutzer-ID, Alter), bei dem die Benutzer-ID vorne und das Alter hinten steht.

Gegenbeispiel:

Wählen Sie Benutzer-ID, Name und Alter des Benutzers aus, wobei Alter = 10 ist.

Positives Beispiel:

# Wählen Sie gemäß dem ganz links stehenden Übereinstimmungsprinzip Benutzer-ID, Name und Alter des Benutzers aus, wobei Benutzer-ID = 1 und Alter = 21 ist.
# Wählen Sie gemäß dem ganz links stehenden Übereinstimmungsprinzip Benutzer-ID, Name und Alter des Benutzers aus, bei dem Benutzer-ID = 1 ist.

Grund:

• Wenn wir einen gemeinsamen Index erstellen, beispielsweise (k1, k2, k3), entspricht dies der Erstellung von drei Indizes: (k1), (k1, k2) und (k1, k2, k3). Dies ist das Prinzip der Übereinstimmung ganz links.
• Der gemeinsame Index erfüllt nicht das Prinzip „ganz links“ und der Index wird im Allgemeinen ungültig. Dies hängt jedoch auch mit dem MySQL-Optimierer zusammen.
  

16. Verwenden Sie ggf. abdeckende Indizes.

Durch das Abdecken von Indizes müssen Ihre SQL-Anweisungen nicht zur Tabelle zurückkehren. Sie können alle erforderlichen Daten abrufen, indem Sie einfach auf den Index zugreifen, was die Abfrageeffizienz erheblich verbessert.

Gegenbeispiel:

# Wie Fuzzy-Abfrage, keine Indexauswahl Benutzer-ID, Name, Alter vom Benutzer, wobei Benutzer-ID wie „%123%“ ist

# Wenn die ID der Primärschlüssel ist, handelt es sich um einen normalen Index, d. h. einen überlagernden Index.
Wählen Sie Benutzer-ID, Name und Alter des Benutzers aus, dessen Benutzer-ID beispielsweise „%123%“ lautet.

17. Entfernen Sie redundante und doppelte Indizes

Gegenbeispiel:

  SCHLÜSSEL `idx_userId` (`userId`)
  SCHLÜSSEL `idx_userId_age` (`userId`,`age`)

Positives Beispiel:

  SCHLÜSSEL `idx_userId_age` (`userId`,`age`)
# Löschen Sie den Index der Benutzer-ID (SCHLÜSSEL `idx_userId_age` (`userId`,`age`))
# Weil der kombinierte Index (A, B) gleichbedeutend mit der Erstellung der beiden Indizes (A) und (A, B) ist.

Grund:

• Doppelte Indizes müssen beibehalten werden und der Optimierer muss sie bei der Optimierung von Abfragen einzeln berücksichtigen, was sich auf die Leistung auswirkt.
  

18. Inner Join, Left Join, Right Join, Inner Join wird bevorzugt. Bei Left Join sollte das Ergebnis der linken Tabelle so klein wie möglich sein.

Innerer Join: Wenn zwei Tabellen für eine Abfrage verknüpft werden, werden nur die Ergebnismengen beibehalten, die vollständig mit den beiden Tabellen übereinstimmen.

Wenn Left Join eine Join-Abfrage für zwei Tabellen ausführt, werden alle Zeilen der linken Tabelle zurückgegeben, auch wenn in der rechten Tabelle keine übereinstimmenden Datensätze vorhanden sind.

Wenn der rechte Join eine Join-Abfrage für zwei Tabellen ausführt, werden alle Zeilen der rechten Tabelle zurückgegeben, auch wenn in der linken Tabelle keine übereinstimmenden Datensätze vorhanden sind.

Unter der Voraussetzung, dass die SQL-Anforderungen erfüllt sind, ist Inner Join vorzuziehen. Bei Verwendung von Left Join sollten die Datenergebnisse der linken Tabelle möglichst klein sein und, wenn die Bedingungen es zulassen, zur Verarbeitung auf der linken Seite platziert werden.

Gegenbeispiel:

Wähle Name und Alter aus Tab1 t1 links und schließe dich Tab2 t2 an, auf t1.age = t2.age, wobei t1.id = 2;

Positives Beispiel:

Wähle Name, Alter aus (wähle * aus Tab1, wo ID = 2) t1 links, schließe dich Tab2 an, t2 an t1.Alter = t2.Alter;

Grund:

• Wenn es sich bei dem inneren Join um einen gleich großen Join handelt, kann die Anzahl der zurückgegebenen Zeilen relativ gering sein, sodass die Leistung relativ besser ist.
• Bei Verwendung eines Left Join ist das Datenergebnis der linken Tabelle so klein wie möglich und die Bedingungen werden so weit wie möglich links verarbeitet, was bedeutet, dass die Anzahl der zurückgegebenen Zeilen relativ klein sein kann.
  

19. Wenn Sie zu viele Daten einfügen, sollten Sie die Stapelverarbeitung in Betracht ziehen

Gegenbeispiel:

für (Benutzer u: Liste)
{ INSERT in Benutzer(Name, Alter) Werte(Name, Alter)}

Positives Beispiel:

//Fügen Sie jeweils 500 Werte ein und fügen Sie sie stapelweise in die Benutzerwerte (Name, Alter) ein.
<foreach Sammlung="Liste" Element="Element" Index="Index" Trennzeichen=",">
 (#{item.name},#{item.alter})
</foreach>

Grund:

• Das Einfügen in Stapelverarbeitung weist eine gute Leistung auf und reduziert den Zeitverlust.
  

20. Verwenden Sie das Schlüsselwort „distinct“ so wenig wie möglich

Das Schlüsselwort „distinct“ wird im Allgemeinen verwendet, um doppelte Datensätze herauszufiltern und nicht doppelte Datensätze zurückzugeben. Bei der Abfrage eines oder weniger Felder bringt es Optimierungseffekte für die Abfrage. Bei vielen Feldern verringert sich die Abfrageeffizienz jedoch erheblich.

Gegenbeispiel:

# Doppelte Felder entfernen SELECT DISTINCT * from user;

Positives Beispiel:

Wählen Sie einen UNTERSCHIEDLICHEN Namen vom Benutzer aus.

Grund:

• Die CPU-Zeit und die belegte Zeit der Anweisung mit Distinct sind höher als die der Anweisung ohne Distinct.
• Denn wenn bei der Abfrage vieler Felder „distinct“ verwendet wird, vergleicht die Datenbank-Engine die Daten und filtert doppelte Daten heraus. Dieser Vergleichs- und Filtervorgang beansprucht jedoch Systemressourcen und CPU-Zeit.

21. Verwenden Sie nicht mehr als 5 Tabellenverknüpfungen

Grund:

• Je mehr verknüpfte Tabellen vorhanden sind, desto länger ist die Kompilierungszeit und der Mehraufwand.
• Die Lesbarkeit der verknüpften Tabelle ist schlecht. Die Aufteilung der verknüpften Tabelle in mehrere kleinere Ausführungen verbessert die Lesbarkeit.
  

22. So optimieren Sie Aktualisierungsanweisungen bei großen Datenmengen.

Bei großen Datenmengen muss darauf geachtet werden, dass nicht zu viele Daten gleichzeitig geändert oder gelöscht werden. Dies führt zu einer übermäßigen CPU-Auslastung und beeinträchtigt den Zugriff anderer Personen auf die Datenbank.

Gegenbeispiel:

# Löschen Sie 100.000 oder mehr als 1 Million Datensätze auf einmal, löschen Sie von Benutzern, bei denen die ID < 1000000 ist;
# Oder verwenden Sie eine einzelne Schleifenoperation, die ineffizient und zeitaufwändig ist für (User user: list) {delete from user;}

Positives Beispiel:

# Löschen Sie in Stapeln, z. B. jeweils 500   
Benutzer löschen, bei denen die ID < 500 ist
Benutzer löschen, bei denen ID >= 500 und ID < 1000;
...
Benutzer löschen, bei denen ID >= 999500 und ID < 1000000;

Grund:

• Wenn Sie zu viele Daten auf einmal löschen/aktualisieren, kann ein Fehler aufgrund einer Überschreitung des Wartezeitlimits für die Sperre auftreten. Daher wird empfohlen, in Stapeln vorzugehen.
  

23. Verwenden Sie vorhanden und in angemessener Weise

Angenommen, Tabelle A stellt die Mitarbeitertabelle eines Unternehmens dar und Tabelle B die Abteilungstabelle. Die SQL-Anweisung zum Abfragen aller Mitarbeiter in allen Abteilungen lautet:

Gegenbeispiel:

Wählen Sie * aus A, wo deptId in (wählen Sie deptId aus B);

Dies entspricht der Schreibweise:

Erste Abfrage Abteilungstabelle B
wähle deptId aus B
Dann fragen Sie die Mitarbeiter von A nach Abteilung deptId ab
Wählen Sie * aus A, wobei A.deptId = B.deptId

Es kann in eine Schleifenanweisung wie diese abstrahiert werden:

Liste<> Ergebnismenge;    
für(int i = 0; i < B.Länge; i++) {
 für(int j = 0; j < A.Länge; j++) {
     wenn(A[i].id == B[j].id) {
         Ergebnismenge.add(A[i]);
            brechen;          
        }       
     }    
 }

Wir können auch exists verwenden, um die gleiche Abfragefunktion zu erreichen

Wählen Sie * aus A, wo vorhanden (wählen Sie 1 aus B, wo A.deptId = B.deptId);

Der obige Code entspricht:

select * from A, loop from table A first
Wählen Sie * aus B, wobei A.deptId = B.deptId ist, und durchlaufen Sie dann Tabelle B.

Denn das Verständnis der Exist-Abfrage besteht darin, zuerst die Hauptabfrage auszuführen, die Daten abzurufen und sie dann zur Überprüfung der Bedingungen in die Unterabfrage einzufügen. Basierend auf dem Überprüfungsergebnis (wahr oder falsch) wird bestimmt, ob das Datenergebnis der Hauptabfrage beibehalten werden kann.

In ähnlicher Weise kann es in einen solchen Zyklus abstrahiert werden:

Liste<> Ergebnismenge;    
für(int i = 0; i < A.Länge; i++) {
 für(int j = 0; j < B.Länge; j++) {
     wenn(A[i].deptId == B[j].deptId) {
         Ergebnismenge.add(A[i]);
            brechen;          
            }       
        }    
    }

Grund:

• Der schwierigste Teil der Datenbank ist die Verknüpfung und Freigabe mit dem Programm. Angenommen, der Link wird zweimal verwendet und jedes Mal wird eine Abfrage für einen Datensatz von Millionen Malen durchgeführt, und dann wird dies nur zweimal durchgeführt. Im Gegenteil, wenn jedes Mal eine separate Abfrage durchgeführt wird, werden Millionen von Links erstellt und die Anwendung zum Freigeben von Links wird wiederholt wiederholt.
• Das MySQL-Optimierungsprinzip besteht darin, dass kleine Tabellen große Tabellen und kleine Datensätze große Datensätze antreiben, wodurch eine bessere Leistung erzielt wird.
• Wir müssen diejenige mit der kleinsten äußeren Schleife auswählen. Das heißt, wenn die Datenmenge in B kleiner ist als die in A, ist es für die Verwendung geeignet. Wenn die Datenmenge in B größer ist als die in A, ist es für die Verwendung geeignet.
  

24. Verwenden Sie so oft wie möglich numerische Felder. Wenn das Feld nur numerische Informationen enthält, versuchen Sie, es nicht als Zeichenfeld zu gestalten.

Gegenbeispiel:

`king_id` varchar(20) NICHT NULL KOMMENTAR '123'

Positives Beispiel:

 `king_id` int(11) NICHT NULL KOMMENTAR '123'

Grund:

• Im Vergleich zu numerischen Feldern verringern Zeichenfelder die Abfrage- und Verbindungsleistung und erhöhen den Speicheraufwand.
  

25. Versuchen Sie, union durch union all zu ersetzen

Wenn in den Suchergebnissen keine doppelten Datensätze vorhanden sind, wird empfohlen, „union“ durch „union all“ zu ersetzen.

Gegenbeispiel:

Wählen Sie * vom Benutzer aus, wobei Benutzer-ID = 1 ist.
Union
Wählen Sie * vom Benutzer, wobei Alter = 20

Positives Beispiel:

Wählen Sie * vom Benutzer aus, wobei Benutzer-ID = 1 ist.
Vereinigung alle
Wählen Sie * vom Benutzer, wobei Alter = 20

Grund:

• Wenn Sie „Union“ verwenden, wird unabhängig davon, ob die Suchergebnisse wiederholt werden oder nicht, versucht, sie zusammenzuführen und dann zu sortieren, bevor das Endergebnis ausgegeben wird.
• Wenn Sie wissen, dass die Suchergebnisse keine doppelten Datensätze enthalten, verwenden Sie zur Verbesserung der Effizienz „union all“ anstelle von „union“.

26. Wenn der Feldtyp eine Zeichenfolge ist, müssen Sie ihn bei der Verwendung von „where“ unbedingt in Anführungszeichen einschließen, da sonst der Index ungültig ist.

Gegenbeispiel:

Wählen Sie * vom Benutzer, wobei Benutzer-ID = 1 ist;

Positives Beispiel:

Wählen Sie * vom Benutzer aus, wobei Benutzer-ID = „1“ ist.

Grund:

Die erste Anweisung verwendet den Index nicht, wenn er nicht in einfache Anführungszeichen eingeschlossen ist. Dies liegt daran, dass ohne einfache Anführungszeichen die Zeichenfolge mit der Zahl verglichen wird und ihre Typen nicht übereinstimmen. MySQL führt eine implizite Typkonvertierung durch und konvertiert sie zum Vergleich in Gleitkommazahlen.

Zusammenfassen

Dies ist das Ende dieses Artikels über MySQL-Optimierung und das Schreiben hochwertiger SQL-Anweisungen. Weitere relevante Inhalte zu SQL-Anweisungen zur MySQL-Optimierung finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!