Prinzipien der SQL-Anweisungsoptimierung

Methoden zur Verbesserung der Abfragegeschwindigkeit bei der Verarbeitung von Daten mit mehr als einer Million Ebenen:

1. Vermeiden Sie die Verwendung von !=- oder <>-Operationen Andernfalls gibt die Engine die Verwendung des Index auf und führt einen vollständigen Tabellenscan durch.
2. Um die Abfrage zu optimieren, versuchen Sie, vollständige Tabellenscans zu vermeiden. Erwägen Sie zunächst die Erstellung von Indizes für die beteiligten Spalten in „wo“ und „Reihenfolge nach“.
3. Vermeiden Sie es, Nullwerturteile über Felder in der where-Klausel zu fällen, da die Engine sonst die Verwendung des Index aufgibt und einen vollständigen Tabellenscan durchführt,

Zum Beispiel:
Wählen Sie die ID aus t aus, wobei die Nummer null ist
Sie können für Nummer den Standardwert 0 festlegen. Stellen Sie sicher, dass darin kein Nullwert enthalten ist die Num-Spalte in der Tabelle und fragen Sie dann wie folgt ab:
select id from t where num=0

4. Vermeiden Sie die Verwendung von oder in die where-Klausel, um Bedingungen zu verbinden, andernfalls führt dies dazu, dass die Engine die Verwendung des Index aufgibt und einen vollständigen Tabellenscan durchführt, wie zum Beispiel:
select id from t where num=10 or num=20
Sie können eine Abfrage wie folgt durchführen:
 select id from t where num=10
union all
 select id from t where num=20

5. Die folgende Abfrage führt auch zu einem vollständigen Tabellenscan: (kann nicht vor dem Prozentzeichen stehen)
Wählen Sie eine ID aus, wobei der Name etwa „�c%“ lautet.
Wenn Sie die Effizienz verbessern möchten, können Sie die Volltextsuche in Betracht ziehen.
6.in und nicht in sollte ebenfalls mit Vorsicht verwendet werden, da es sonst zu einem vollständigen Tabellenscan führt, wie zum Beispiel:
select id from t where num in(1,2, 3)
Für kontinuierliche Werte nicht in verwenden, wenn Sie zwischen verwenden können:
select id from t where num between 1 and 3

select xx,phone FROM send a JOIN (
select '13891030091' phone union select '13992085916'………… UNION SELECT '13619 100234' ) b
auf a.Ph/span>
--ersetzen Sie Folgendes, wenn viele Daten getrennt sind
in('13891030091','13992085916 ','13619100234'…………)

7. Wenn Parameter in der where-Klausel verwendet werden, führt dies auch zu einem vollständigen Tabellenscan. Da SQL lokale Variablen nur zur Laufzeit auflöst, kann der Optimierer die Auswahl eines Zugriffsplans nicht bis zur Laufzeit verschieben, sondern muss die Auswahl zur Kompilierungszeit treffen. Wenn der Zugriffsplan jedoch zur Kompilierungszeit erstellt wird, ist der Wert der Variablen noch unbekannt und kann nicht als Eingabe für die Indexauswahl verwendet werden. Die folgende Anweisung führt beispielsweise einen vollständigen Tabellenscan durch:
select id from t where num=@num Sie können es ändern, um zu erzwingen, dass die Abfrage einen Index verwendet:
select id from t with( index (index name)) where num=@num
8. Versuchen Sie, Ausdrucksoperationen auf Feldern in der where-Klausel zu vermeiden, die dazu führen, dass die Engine nachgibt Verwenden Sie den Index, um einen vollständigen Tabellenscan durchzuführen. Zum Beispiel:
select id from t where num/2=100
sollte geändert werden in:
select id from t where num= 100*2

9. Versuchen Sie zu vermeiden, funktionale Operationen an Feldern in der where-Klausel auszuführen, da dies dazu führen würde, dass die Engine die Verwendung des Index aufgibt und einen vollständigen Tabellenscan durchführt. Zum Beispiel:
Wählen Sie die ID aus t aus, wobei substring(name,1,3)='abc'–Namens-ID beginnt mit abc
Wählen Sie die ID aus t aus, wobei das Datum datiert ist (day,createdate,'2005-11-30′)=0–'2005-11-30′Die generierte ID
sollte geändert werden in:
auswählen ID von t, wobei der Name etwa „abc%“ ist
Wählen Sie die ID von t aus, wobei erstelltes Datum>='2005-11-30′ und erstelltes Datum<'2005-12-1′
10. Führen Sie keine Funktionen, arithmetischen Operationen oder andere Ausdrucksoperationen auf der linken Seite von „=" in der where-Klausel aus, da das System sonst den Index möglicherweise nicht korrekt verwenden kann.
11. Wenn Sie ein Indexfeld als Bedingung verwenden und der Index ein zusammengesetzter Index ist, muss das erste Feld im Index als Bedingung verwendet werden, um sicherzustellen, dass das System den Index verwendet. Andernfalls werden die Indizes nicht verwendet und die Feldreihenfolge sollte nach Möglichkeit mit der Indexreihenfolge übereinstimmen.
12. Schreiben Sie keine bedeutungslosen Abfragen, wenn Sie beispielsweise eine leere Tabellenstruktur generieren müssen:
Wählen Sie col1,col2 in #t von t aus 1=0
Dieser Codetyp gibt keine Ergebnismenge zurück, verbraucht aber Systemressourcen. Er sollte wie folgt geändert werden:
Tabelle #t erstellen (…)
13. Oft ist es eine gute Wahl, „exists“ statt „in“ zu verwenden:
select num from a where num in(select num from b)
Ersetzen Sie durch die folgende Anweisung:
select num from a where exist(select 1 from b where num=a.num)
14. Nicht alle Indizes sind für Abfragen geeignet. SQL führt eine Abfrageoptimierung basierend auf den Daten in der Tabelle durch. Wenn die Indexspalte eine große Menge doppelter Daten enthält, wird der Index möglicherweise nicht verwendet Wenn in einer Tabelle beispielsweise ein Feld „Geschlecht“ vorhanden ist, ist fast die Hälfte davon männlich und die Hälfte weiblich. Selbst wenn in der Indexspalte eine große Menge doppelter Daten vorhanden ist, hat selbst die Erstellung eines Geschlechtsindex keine Auswirkung auf die Abfrage Effizienz.
15. Je mehr Indizes, desto besser. Obwohl der Index die Effizienz der entsprechenden Auswahl verbessern kann, verringert er auch die Effizienz des Einfügens und Aktualisierens, da der Index beim Einfügen oder Aktualisieren möglicherweise neu erstellt wird Der Index erfordert eine sorgfältige und fallweise Betrachtung. Es ist am besten, nicht mehr als 6 Indizes für eine Tabelle zu haben. Wenn es zu viele sind, sollten Sie überlegen, ob es notwendig ist, Indizes für einige Spalten zu erstellen, die nicht häufig verwendet werden.
16. Sie sollten die Aktualisierung von Clustered-Index-Datenspalten so weit wie möglich vermeiden, da die Reihenfolge der Clustered-Index-Datenspalten die physische Speicherreihenfolge von Tabellendatensätzen ist. Sobald sich der Spaltenwert ändert, ändert sich die Reihenfolge Die gesamten Tabellendatensätze werden geändert. Wenn das Anwendungssystem die Datenspalten des Clustered-Index häufig aktualisieren muss, müssen Sie überlegen, ob der Index als Clustered-Index erstellt werden soll.
17. Wenn Felder nur numerische Informationen enthalten, sollten Sie versuchen, sie nicht als Zeichenfelder zu gestalten. Dies verringert die Leistung von Abfragen und Verbindungen und erhöht den Speicheraufwand. Dies liegt daran, dass die Engine bei der Verarbeitung von Abfragen und Verbindungen jedes Zeichen in der Zeichenfolge einzeln vergleicht und für numerische Typen nur ein Vergleich ausreicht.
18. Verwenden Sie so oft wie möglich varchar/nvarchar anstelle von char/nchar, da Felder mit variabler Länge erstens wenig Speicherplatz haben und zweitens für Abfragen Speicherplatz sparen können relativ kleines Feld Die interne Sucheffizienz ist offensichtlich höher.
19. Verwenden Sie „select * from t“ nirgendwo, ersetzen Sie „*“ durch eine bestimmte Feldliste und geben Sie keine nicht verwendeten Felder zurück.
20. Versuchen Sie, Tabellenvariablen anstelle von temporären Tabellen zu verwenden. Wenn die Tabellenvariable eine große Datenmenge enthält, beachten Sie, dass die Indizes sehr begrenzt sind (nur Primärschlüsselindizes).
21. Vermeiden Sie das häufige Erstellen und Löschen temporärer Tabellen, um den Verbrauch von Systemtabellenressourcen zu reduzieren.
22. Temporäre Tabellen sind nicht unbrauchbar, und ihre ordnungsgemäße Verwendung kann bestimmte Routinen effizienter machen, beispielsweise wenn Sie wiederholt auf eine große Tabelle oder einen bestimmten Datensatz in einer häufig verwendeten Tabelle verweisen müssen . Für einmalige Ereignisse ist es jedoch besser, Exporttabellen zu verwenden.
23. Wenn beim Erstellen einer temporären Tabelle die auf einmal eingefügte Datenmenge groß ist, können Sie „select into“ anstelle von „create table“ verwenden, um eine große Anzahl von Protokollen zu vermeiden und die Geschwindigkeit zu verbessern. Wenn die Datenmenge nicht groß ist, sollte die Tabelle zuerst erstellt und dann eingefügt werden, um die Ressourcen der Systemtabelle zu entlasten.
24. Wenn temporäre Tabellen verwendet werden, müssen alle temporären Tabellen am Ende der gespeicherten Prozedur explizit gelöscht werden. Dadurch kann eine langfristige Sperrung von Systemtabellen vermieden werden . .
25. Vermeiden Sie die Verwendung von Cursorn, da Cursor weniger effizient sind. Wenn die vom Cursor verarbeiteten Daten 10.000 Zeilen überschreiten, sollten Sie ein Umschreiben in Betracht ziehen.
26. Bevor Sie die Cursor-basierte Methode oder die temporäre Tabellenmethode verwenden, sollten Sie zunächst nach einer satzbasierten Lösung zur Lösung des Problems suchen. Die satzbasierte Methode ist normalerweise effektiver.
27. Cursor sind wie temporäre Tabellen nicht unbrauchbar. Die Verwendung von FAST_FORWARD-Cursoren für kleine Datensätze ist häufig anderen zeilenweisen Verarbeitungsmethoden überlegen, insbesondere wenn auf mehrere Tabellen verwiesen werden muss, um die erforderlichen Daten zu erhalten. Routinen, die „Summen“ in einen Ergebnissatz einbeziehen, sind normalerweise schneller als die Verwendung eines Cursors. Wenn es die Entwicklungszeit erlaubt, können Sie sowohl die Cursor-basierte Methode als auch die Satz-basierte Methode ausprobieren, um herauszufinden, welche Methode besser funktioniert.
28. Setzen Sie SET NOCOUNT ON am Anfang aller gespeicherten Prozeduren und Trigger und legen Sie SET NOCOUNT OFF am Ende fest. Es ist nicht erforderlich, nach jeder Anweisung gespeicherter Prozeduren und Trigger eine DONE_IN_PROC-Nachricht an den Client zu senden.
29. Vermeiden Sie die Rückgabe großer Datenmengen an den Kunden. Wenn die Datenmenge zu groß ist, sollten Sie überlegen, ob die entsprechenden Anforderungen angemessen sind.
30. Versuchen Sie, große Transaktionsvorgänge zu vermeiden und die Systemparallelität zu verbessern.

Quelle des Artikels: http://www.cnblogs.com/pepcod/archive/2013/01/01/2913496.html

Artikelreferenz zur Optimierung von SQL:

http://www.cnblogs.com/ATree/archive/2011/02/13/sql_optimize_1.html

http://blog.csdn.net/csh624366188/article/details/8457749

http://www.iteye.com/problems/100945

http://blog.itpub.net/28389881/viewspace-1301549/                                                                                                                                                                                                                     Das Obige stellt die Prinzipien der SQL-Anweisungsoptimierung vor, einschließlich Aspekten des Inhalts. Ich hoffe, dass es für Freunde hilfreich ist, die sich für PHP-Tutorials interessieren.