Detaillierte Analyse von or, in, union und Indexoptimierung in MySQL

Dieser Artikel entstand aus der Hausaufgabe „Erlernen Sie Indexierungsfähigkeiten in einer Minute“.

Angenommen, die Tabellenstruktur für die Auftragsabwicklung ist:

Bestellung (oid, Datum, UID, Status, Geld, Zeit, …)

In:

• oid, Bestell-ID, Primärschlüssel
• Datum, Bestelldatum, hat einen gemeinsamen Index, und das Management-Backend fragt oft nach Datum ab
• uid, Benutzer-ID, hat einen gemeinsamen Index, Benutzer fragen ihre eigenen Bestellungen ab
• Status, Bestellstatus, haben einen gemeinsamen Index, und das Management-Backend fragt häufig nach dem Status ab
• Geld/Zeit, Bestellmenge/-zeit, abgefragtes Feld, kein Index
• …

Angenommen, eine Bestellung hat drei Zustände: 0 wurde aufgegeben, 1 wurde bezahlt und 2 wurde abgeschlossen.

Geschäftsanforderung: Abfrage nicht abgeschlossener Bestellungen, welches SQL ist schneller?

• Wählen Sie * aus der Reihenfolge, in der Status! = 2
• Wählen Sie * aus der Reihenfolge, in der Status = 0 oder Status = 1
• Wählen Sie * aus der Reihenfolge, in der der Status IN (0,1) ist
• Wählen Sie * aus der Reihenfolge, in der Status = 0 ist
  Vereinigung alle
  Wählen Sie * aus der Reihenfolge, in der Status = 1

Fazit: Lösung 1 ist die langsamste, während die Lösungen 2, 3 und 4 alle den Index treffen können.

Aber...

1: Union All kann definitiv den Index erreichen

Wählen Sie * aus der Reihenfolge, in der Status = 0 ist

Vereinigung alle

Wählen Sie * aus der Reihenfolge, in der Status = 1

veranschaulichen:

Sagen Sie MySQL direkt, was zu tun ist. MySQL verbraucht am wenigsten CPU

Programmierer schreiben SQL nicht oft auf diese Weise (alles vereinigen).

2: Einfach in kann den Index treffen

Wählen Sie * aus der Reihenfolge, in der der Status in (0,1) liegt.

veranschaulichen:

Lassen Sie MySQL nachdenken, die Abfrageoptimierung verbraucht mehr CPU als die Vereinigung aller, aber es ist vernachlässigbar

Programmierer schreiben SQL (in) oft so. In diesem Beispiel wird empfohlen, es so zu schreiben

Drei: Für oder kann die neue Version von MySQL den Index treffen

Wählen Sie * aus der Reihenfolge, in der Status = 0 oder Status = 1

veranschaulichen:

Lassen Sie MySQL nachdenken. Die Abfrageoptimierung verbraucht mehr CPU als IN. Belasten Sie MySQL nicht.

Es wird Programmierern nicht empfohlen, „oder“ häufig zu verwenden, da nicht alle „oder“ den Index treffen.

Für ältere MySQL-Versionen empfiehlt es sich,

4. Bei != treffen negative Abfragen definitiv nicht den Index

Wählen Sie * aus der Reihenfolge, in der Status! = 2

veranschaulichen:

Vollständiger Tabellenscan, die am wenigsten effiziente und langsamste aller Lösungen

Negative Lookups sind verboten

V. Weitere Optionen

Wählen Sie * aus der Reihenfolge, in der der Status < 2 ist

In diesem konkreten Beispiel ist es tatsächlich schnell, aber:

Dieses Beispiel gibt nur drei Zustände an. Das tatsächliche Geschäft hat mehr als diese drei Zustände, und der „Wert“ des Zustands erfüllt gerade die partielle Ordnungsbeziehung. Was ist, wenn Sie andere Zustände prüfen möchten? SQL sollte sich nicht auf den Wert der Aufzählung verlassen, und die Lösung ist nicht universell.

Dieses SQL ist schlecht lesbar, schlecht verständlich und schlecht wartbar. Es wird dringend davon abgeraten.

6. Hausaufgaben

Kann eine solche Abfrage den Index treffen?

Wählen Sie * aus der Reihenfolge, in der die UID in (

   Wählen Sie die UID aus der Reihenfolge, in der der Status = 0 ist.

)

select * from order where status in (0, 1) sortieren nach Datum absteigend

Wählen Sie * aus der Reihenfolge, in der Status = 0 oder Datum <= CURDATE()

Hinweis: Dies ist nur ein Beispiel. Seien Sie nicht zu pingelig, was die Rationalität des SQL für das jeweilige Unternehmen angeht.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.