SQL-Leistungsoptimierung

Vorwort: Heute werde ich Ihnen ein wichtigeres Thema vorstellen: die SQL-Leistungsoptimierung.

Wie man SQL-Anweisungen beim Betrieb der Datenbank effizienter macht, ist ein sehr wichtiges Thema. Im Folgenden fasse ich die Probleme der Leistungsoptimierung für Sie zusammen.

SQL-Leistungsoptimierung

1. Die SELECT-Anweisung muss den Feldnamen angeben

SELECT * wird stark erhöht unnötiger Verbrauch (CPU, IO, Speicher, Netzwerkbandbreite); erhöht die Möglichkeit, abdeckende Indizes zu verwenden.

Wenn sich die Tabellenstruktur ändert, muss auch die vorherige Pause aktualisiert werden. Daher ist es erforderlich, den Feldnamen direkt nach der Auswahl hinzuzufügen.

2. Der in IN in der SQL-Anweisung enthaltene Wert sollte nicht zu groß sein.

MySQL hat entsprechende Optimierungen für IN vorgenommen, d. h. alle Konstanten in IN werden in einem Array gespeichert. und dieses Array ist in Ordnung.

Aber wenn der Wert groß ist, wird der Verbrauch relativ hoch sein. Verwenden Sie für kontinuierliche Werte nicht „in“, wenn Sie „between“ verwenden können, oder verwenden Sie stattdessen „connection“.

3. Unterscheiden Sie zwischen in und existiert, nicht in und nicht existiert

select * from 表A 
where id in (select id from 表B)

ist äquivalent zu

select * from 表A 
where exists(select * from 表B where 表B.id=表A.id)

Der Unterschied zwischen in und existiert ist hauptsächlich verursacht durch Fahren Die Reihenfolge ändert sich (dies ist der Schlüssel zu Leistungsänderungen). Wenn vorhanden, ist die äußere Tabelle die treibende Tabelle, auf die zuerst zugegriffen wird. Wenn sie IN ist, wird zuerst die Unterabfrage ausgeführt.

So eignet sich IN für Situationen, in denen die Außenfläche groß, aber die Innenfläche klein ist; EXISTS eignet sich für Situationen, in denen die Außenfläche klein, aber die Innenfläche groß ist.

4. Es wird nicht empfohlen, die %-Präfix-Fuzzy-Abfrage zu verwenden.

Zum Beispiel LIKE „%name“ oder LIKE „%name%“, diese Art von Abfrage führt zu einem Indexfehler. Aber LIKE „name%“ kann verwendet werden.

Implizite Typkonvertierung vermeiden:

Typkonvertierung erfolgt, wenn der Typ des Spaltenfelds in der where-Klausel nicht mit dem Typ des übergebenen Parameters übereinstimmt. Dies wird empfohlen um den ersten Parametertyp zu bestimmen, wobei

5. Für den gemeinsamen Index sollte die Präfixregel ganz links befolgt werden

Der Index enthält beispielsweise die Felder ID, Name, Schule , Sie können das ID-Feld direkt oder in der Reihenfolge ID, Name verwenden, aber die Schule kann diesen Index nicht verwenden.

Beim Erstellen eines gemeinsamen Indexes müssen Sie also auf die Reihenfolge der Indexfelder achten.

Um die obigen Vorschläge zusammenzufassen:

1. Vermeiden Sie Berechnungsoperationen für Indexfelder

2. Vermeiden Sie die Verwendung von „not a8093152e673feb7aba1828c43532094“ !=

3 🎜>

3. Vermeiden Sie die Datentypkonvertierung für Indexfelder

4. Vermeiden Sie die Verwendung von Nullwerten in indizierten Spalten

6. Anweisungsregeln für WHERE

7 Vermeiden Sie die Verwendung von „in“, „not in“ oder „with in“ in der WHERE-Klausel. Sie können „exist“, „not exist“ anstelle von „in, not in“ verwenden . Deklarieren Sie keine Zahlen im Zeichenformat, deklarieren Sie keine Zeichenwerte im numerischen Format, da sonst der Index ungültig wird

Die oben genannten Probleme sind für alle zusammengefasst. Weitere Fragen finden Sie in den entsprechenden Tutorials auf der chinesischen PHP-Website:

https://www.php.cn/course/list/51/type/2.html

Das obige ist der detaillierte Inhalt vonSQL-Leistungsoptimierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!