Mysql
 sql >> Datenbank >  >> RDS >> Mysql

Was ist Big-O for SQL select?

Da Sie den ausgewählten Algorithmus nicht steuern, gibt es keine Möglichkeit, dies direkt zu erfahren. Ohne Indizes sollte ein SELECT jedoch O(n) sein (ein Tabellenscan muss jeden Datensatz untersuchen, was bedeutet, dass er mit der Größe der Tabelle skaliert).

Bei einem Index ist ein SELECT wahrscheinlich O(log(n)) (obwohl es vom für die Indizierung verwendeten Algorithmus und den Eigenschaften der Daten selbst abhängen würde, ob dies für eine echte Tabelle gilt). Um Ihre Ergebnisse für eine Tabelle oder Abfrage zu bestimmen, müssen Sie auf die Erstellung von Profilen aus realen Daten zurückgreifen, um sicherzugehen.

INSERT ohne Indizes sollte sehr schnell sein (in der Nähe von O(1)), während UPDATE zuerst die Datensätze finden muss und daher (etwas) langsamer sein wird als das SELECT, das Sie dorthin bringt.

INSERT mit Indizes wird wahrscheinlich wieder im Bereich von O(log(n^2)) liegen, wenn der Indexbaum neu ausgeglichen werden muss, ansonsten näher an O(log(n)). Die gleiche Verlangsamung tritt bei einem UPDATE auf, wenn es indizierte Zeilen betrifft, zusätzlich zu den SELECT-Kosten.

Alle Wetten sind ungültig, sobald Sie über JOIN in the Mix sprechen:Sie müssen Ihre Datenbankabfrage-Schätzungstools profilieren und verwenden, um einen Überblick darüber zu erhalten. Beachten Sie auch, dass Sie erneut sollten, wenn diese Abfrage leistungskritisch ist Profil von Zeit zu Zeit, da sich die von Ihrem Abfrageoptimierer verwendeten Algorithmen ändern, wenn sich die Datenlast ändert.

Eine andere Sache, die Sie im Hinterkopf behalten sollten ... big-O sagt Ihnen nicht, welche Fixkosten für jede Transaktion anfallen. Bei kleineren Tischen dürften diese höher sein als die eigentlichen Arbeitskosten. Als Beispiel:Die Einrichtungs-, Abbau- und Kommunikationskosten einer netzwerkübergreifenden Abfrage für eine einzelne Zeile sind sicherlich höher als die Suche nach einem indizierten Datensatz in einer kleinen Tabelle.

Aus diesem Grund habe ich festgestellt, dass die Möglichkeit, eine Gruppe zusammengehöriger Abfragen in einem Batch zu bündeln, weitaus mehr Auswirkungen auf die Leistung haben kann als jede Optimierung, die ich an der eigentlichen Datenbank vorgenommen habe.