Die allgemeine Regeln zusammengefasst
Die folgenden Regeln zeigen meist erst bei großen Datenmengen bzw. Tabellen ihre Wirkung. Bei kleinen Datenbanken wird man wohl kein Unterschied merken.
- Das Sternchen bei SELECT * FROM.. sollte vermieden werden. (mehr infos s.u.)
- LEFT JOIN und RIGHT JOIN bei großen Tabellen und Datenmengen vermeiden. Möglichst ein JOIN ersetzen und mit Unterabfragen (Subselect) versuchen das gleiche Ergebniss zu erhalten. Hinweis: Nicht immer Möglich
- Beachtung des Datentypes bei der Angabe der WHERE Bedingungen in der SQL Abfrage. Wenn die Spalte z.B. VAHRCHAR als Datentyp hat, den Wert bei der Abfrage unbedingt in Anführungsstriche setzen. Wirkung: Nutzung des Indexes
- Zeitliche Bereiche und Filter bei WHERE-BEdingungen optimieren.
SELECT * FROM…
Das Sternchen welches man gerne bei einfachen Abfragen in der Form SELECT * FROM.. benutzt sollte man mit bedacht einsetzen. Besser ist es immer die Spalten anzugeben die man auch benötigt. Unnötigen Transfer von Daten wird daurch vermieden. Wenn man sehr viele Ergebnisse erwartet, kann das schon bei der Abfragegeschwindigkeit sehr viel ausmachen.
JOIN vs. LEFT JOIN bzw. RIGHT JOIN
Bei der Abfrage von großen Datenmengen sollte wenn möglich die Verwendung von LEFT JOIN und RIGHT JOIN vermieden werden. Die Verwendung eines normalen JOIN erhöht die Abfragegeschwindigkeit meistens deutlich.
In einigen Fällen wird aber die Verwendung von LEFT/RIGHT JOINs zwingend notwendig um ein gewünschtes Ergebnis zu erhalten. In den meisten Fällen kann man aber auch das gewünschtes Ergebnis durch den geschickten Einsatz von Unterabfragen (Subselect) erhalten. Beispiele folgen später…
Beachtung des Datentypes bei WHERE-Bedingungen
Bei einer Abfrage sollte man immer den Datentyp beachten, weil sonst ein möglicher Index der auf die Spalte gesetzt wurde nicht benutzt wird. Beispiel: In der Datenbank stehen Artikeldaten mit EAN Codes. Angenommen die Spalte mit den EAN Code ist als VARCHAR(13) definiert und habt einen gesetzten Index.
Wenn man nun in der SQL Abfrage fälschlicherweise die EAN als Integer behandelt (Es sind ja eigentlich auch nur zahlen) wird der Index der Tabelle gar nicht benutzt. Allein dadurch, das man die EAN Zahl in Anführungsstriche setzt (als String behandelt) sorgt dafür das der Index wie gewünscht benutzt wird. Allgemein kann man sagen. Wenn eine Spalte als VARCHAR oder Text definiert ist, bei der Abfrage auch den Wert als String behandeln, sonst wird der Index nicht benutzt.
|
1 2 3 4 5 |
// So Nicht!! Langsame Abfrage Weil Anführungsstriche fehlen SELECT * FROM articles WHERE ean = 8427328010115 // Besser die EAN als String behandeln, dann wird auch der Index benutzt SELECT * FROM articles WHERE ean = '8427328010115' |
Zeitliche Bereiche und Filter bei WHERE-Bedingungen optimieren
Wenn z.B. das Ergebnis anhand einer Date oder Datetime Spalte auf ein bestimmtes Jahr einschränken werden soll, findet man häufig die folgende Lösung:
|
1 2 3 |
SELECT * FROM eventcalendar WHERE DATE_FORMAT(event_date, '%Y') = 2008 ORDER BY event_date DESC |
Die folgende Query liefert das selbe Ergebnis ist aber deutlich schneller:
|
1 2 3 |
SELECT * FROM eventcalendar WHERE event_date between '2007-01-01 00:00:00' AND '2008-01-01 00:00:00' ORDER BY event_date DESC |
Weitere Beispiele sind hier im Artikel zu finden: MySQL und der Datum/Zeit Vergleich.
Die Nutzung des Indexes bei Datumsberechnungen zeigt folgender Artikel: SQL richtig schreiben: Ausnutzung von Indizes
Umgang mit großen Ergebnismengen
Den folgenden Satz habe ich irgendwo mal auf geschnappt. Ich habe das auch noch nie ausprobiert ob dies sinnvoll oder nützlich ist oder ob es funktioniert. Ich will ihn aber trotzdem mal hier festhalten: „The SELECT option SQL_BUFFER_RESULT will force MySQL to create a temporary table for the results and unlock the other tables involved
in the query as soon as all rows have been fetched.“