10 wenig bekannte SQL-Anweisungsoptimierungen

1. Einige gängige SQL-Praktiken

(1) Negative bedingte Abfragen können keine Indizes verwenden

select * from order where status!=0 and stauts!=1

nicht vorhanden/nicht vorhanden ist keine gute Angewohnheit

Empfehlen Sie „MySQL-Video-Tutorial“

kann in der Abfrage optimiert werden:

select * from order where status in(2,3)

(2) Die führende Fuzzy-Abfrage kann den Index

select * from order where desc like '%XX'

nicht anstelle der führenden Fuzzy-Abfrage verwenden:

select * from order where desc like 'XX%'

( 3) Es ist nicht angemessen, Indizes für Felder mit geringer Datendifferenzierung zu verwenden

select * from user where sex=1

Grund: Es gibt nur männliche und weibliche Geschlechter und es werden jedes Mal nur sehr wenige Daten herausgefiltert, daher ist die Verwendung von Indizes nicht angemessen.

Als Faustregel können Indizes verwendet werden, wenn 80 % der Daten gefiltert werden können. Wenn für den Auftragsstatus nur wenige Statuswerte vorhanden sind, ist die Verwendung eines Index nicht sinnvoll. Wenn viele Statuswerte vorhanden sind und eine große Datenmenge gefiltert werden kann, sollte ein Index erstellt werden.

(4) Die Berechnung anhand von Attributen kann den Index nicht treffen

select * from order where YEAR(date) < = &#39;2017&#39;

Selbst wenn ein Index für das Datum erstellt wird, wird die vollständige Tabelle gescannt, die für die Wertberechnung optimiert werden kann:

select * from order where date < = CURDATE()

Oder:

select * from order where date < = &#39;2017-01-01&#39;

2. Nicht so bekannte SQL-Praktiken

(5) Wenn der größte Teil des Geschäfts eine einzelne Abfrage ist, ist die Die Leistung bei der Verwendung des Hash-Index ist besser, z. B. User Center

select * from user where uid=?
select * from user where login_name=?

Grund:

Die zeitliche Komplexität des B-Tree-Index beträgt O(log(n))

The Die Zeitkomplexität des Hash-Index beträgt O(1)

(6) Spalten, die null sein dürfen, haben potenzielle Fallstricke bei Abfragen

Einzelspaltige Indizes speichern keine Nullwerte, zusammengesetzte Indizes hingegen schon Wenn eine Spalte nicht alle Nullwerte speichern darf, erhalten Sie möglicherweise eine „Unerwartete“ Ergebnismenge

select * from user where name != 'shenjian'

Wenn der Name null sein darf, speichert der Index keine Nullwerte und diese Datensätze wird nicht in die Ergebnismenge aufgenommen.

Verwenden Sie daher bitte keine Null-Einschränkungen und Standardwerte.

(7) Das Präfix ganz links im zusammengesetzten Index ist nicht der Wert. Die Reihenfolge der SQL-Anweisung muss mit dem zusammengesetzten Index übereinstimmen.

Das Benutzerzentrum hat einen zusammengesetzten Index erstellt (login_name, passwd)

select * from user where login_name=? and passwd=?
select * from user where passwd=? and login_name=?

kann auf den Index zugreifen, der das Präfix ganz links im zusammengesetzten Index erfüllt.

select * from user where login_name=?

kann nicht auf den Index zugreifen Index und erfüllt nicht das ganz linke Präfix des zusammengesetzten Index

( 8) Verwenden Sie ENUM anstelle einer Zeichenfolge

ENUM speichert TINYINT. Fügen Sie keine Zeichenfolgen wie „China“, „Beijing“ ein. und „Technologieabteilung“ in der Aufzählung. Der Zeichenfolgenraum ist groß und die Effizienz ist gering.

3. Nischenhafte, aber nützliche SQL-Praktiken

(9) Wenn klar ist, dass nur ein Ergebnis zurückgegeben wird, kann Limit 1 die Effizienz verbessern

select * from user where passwd=?

Kann optimiert werden auf:

select * from user where login_name=?

Grund:

Sie wissen, dass es nur ein Ergebnis gibt, aber die Datenbank weiß es nicht deutlich und lässt die Cursorbewegung aktiv stoppen

(10) Das Platzieren von Berechnungen in der Business-Schicht anstelle der Datenbankschicht spart nicht nur Daten-CPU, sondern hat auch unerwartete Auswirkungen auf die Optimierung des Abfragecaches

select * from user where login_name=? limit 1

Dies ist keine gute SQL-Praxis und sollte es auch sein optimiert werden als:

select * from order where date < = CURDATE()

Grund:

gibt die CPU der Datenbank frei

wird mehrfach aufgerufen und das eingehende SQL ist das gleiche, so dass der Abfragecache sein kann verwendet

(11) Eine erzwungene Typkonvertierung führt dazu, dass die gesamte Tabelle durchsucht wird.

$curDate = date('Y-m-d');
$res = mysql_query(
    &#39;select * from order where date < = $curDate&#39;);

Glaubst du, dass sie in den Telefonindex gelangt? Das ist ein großer Fehler. Wie kann ich diese Aussage ändern?

Abschließend noch eine Sache: Verwenden Sie nicht select *, sondern geben Sie nur die erforderlichen Spalten zurück, was den Umfang der Datenübertragung und die Speichernutzung der Datenbank erheblich reduzieren kann.

Dieser Artikel stammt von der chinesischen PHP-Website, Spalte

MySQL-Tutorial

, willkommen zum Lernen!

Das obige ist der detaillierte Inhalt von10 wenig bekannte SQL-Anweisungsoptimierungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!