verwendetes Datenbanksystem: <SQL Server>
Hi leute,
ich teste gerade ein wenig mit Datenbanken rum, vor allem mit Indizes ...
Ich dachte ursprünglich das sich das auch auf die performance von abfragen auswirkt aber alles was ich sehe ist nur eine andere Sortierung
Mein Test Szenario:
Ich hab eine Tabelle mit 2 Spalten, ID und Date
Die Tabelle hab ich mit 10mio random Dates gefüllt
folgende abrfage dauerte ohne Index, mit clustered und non clustered gleich lang
SELECT *
FROM Table_2
WHERE [Date] BETWEEN '01/01/1700' AND '01/01/2014';
Hab ich da grundlegend was falsch verstanden oder sind 10mio einträge noch nich genug damit es Spürbar wird? ^^
Auf welcher Spalte liegt dein Index?
Wie sind die Datumswerte gestreut? Wenn du fast alles zurückgibst merkst du den Index nicht. Wenn du nur einen Datumsbereich suchen willst solltest du den Index sehr eindrucksvoll spüren.
Hi,
Indizes sind eine komplizierte Sache:
Durch das SELECT * hilft dir praktisch kein Index so wirklich: Selbst wenn ein Index unten greifen würde (was er vermutlich nicht tut) dann würde dadurch der SQL-Server nur die Page wissen, auf der die Daten liegen - das Suchen der Page wäre wieder eine Heap-Suche, die nicht unbedingt performant ist.
Deshalb kann man Spalten angeben die im Index eingeschlossen werden (aber nicht für die Erstellung des eigentlichen Indexes verwendet werden), dann stehen die Ergebnisse direkt im Index und man kann maximal davon profitieren.
Eine Index-Suche büber BETWEEN ist nicht unbedingt möglich. Es könnte sein, dass der SQL-Server den Index nicht berücksichtigen kann. Der Index wird meist optmiert um bestimmte Werte zu finden, nicht unbedingt um Werte zwischen zwei Eckpunkten zu finden.
Um Klarheit zu schaffen kannst Du Dir im SSMS den Ausführungsplan anzeigen lassen - dort siehst Du dann genau, welche Operationen druchgeführt werden und ob ein Index verwendet wird. Es gibt dann noch "Plan Explorer"-Tools die Dir noch die jeweils aufgewendete Rechenzeit und anderes auflisten.
Hallo,
das Holen von Daten via Index ist sehr teuer und wird nur genommen wenn die Abfrage sehr selektiv ist, sonst ist ein table scan schneller. Wiederhole Deine Anfrage mal mit einem Kriterium wo nur 2% aller Datensätze zurückgeliefert werden.
Ein Index kann die Geschwindigkeit der Abfrage schon beschleunigen.
Nur wenn du aber einen Großteil der Daten suchst, per Where Klausel dann kann dein Index nicht helfen.
Bei deiner Beispiel Tabelle ist der Index bei deiner Beispielabfrage unbrauchbar.
Besser ist ein Index wenn er Eindeutig(Bsp. PK) oder eben durch mehrere Spalten die Daten stark eingrenzt und somit auch gut greifen kann.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Hast du den Index vor oder nach dem befüllen der Daten gesetzt? Man kann dem MS SQL Server die Anweisung geben den Index neu aufzufüllen. Nach dieser Aktion kann es zu signifikanten Perfomanceverbesserungen kommen.
Hi, danke für eure ganzen Antworten
Ich habe mal nach dem Lesen eurer beiträge ein wenig weiter probiert ... Habe jetzt mehrere Tabellen
die mit einander auch Verknüpft sind ... aber dennoch ... ich merke bei keiner Abfrage einen Unterschied
Egal ob ich nach einen Bestimen Wert suche oder nach einem Bereich ....
hab die Tabellen
Haus(ID, Bezeichnung, Preis)
Kunde(ID, Name, Alter)
Makler(ID, Nummer)
KundeHaus(ID, Kunde, Haus)
MaklerHaus(ID, Makler, Haus)
Hab jetzt verschiedene Abfragen ausprobiert die mehrere tabellen einschließen mit verschiedenen WHERE klauseln .... ich bekomm da kein Unterschied
Hat einer von euch zufällig ein beispiel, bei dem man einen eindeutigen unterschied auch mal sehen kann?
Beim ersten beispiel lag er auf Date
bei den neuen Tabellen zumbeispiel auf Preis der Haus Tabelle
Wenn Du die Tabllen joinst sollten vllt in den Tabellen KundeHaus und MaklerHaus auf Kunde,Makler,Haus jeweils ein Index liegen. Und lerne den SQL-Ausführungsplan zu interpretieren, da siehst Du ob er überhaupt ein Index nimmt bzw. welche Auswirkungen das hat. (Post v. LittleBoy)
Schau dir mal den Link an.
Use The Index, Luke: Der Suchbaum (B-Tree) macht den Index schnell
Das sollte dir ein Grundlegendes Gefühl dafür geben, wann ein Index was bringt.
Wenn du dann deine Tabellen wirklich optimieren möchtest, solltest wie schon ein paar mal Vorgeschlagen in den Ausführungsplan schauen.
Sollte man mal gelesen haben:
Und wie bastelst du die Sql zusammen?
In 99% der Fälle liegt es eher daran das Du die Strings zusammenfrickelst statt die Parametercollection zu benutzen
und der Sql Server deshalb seine Ausführungspläne nicht cachen und Indizes nicht vorhalten kann.
Und wie bastelst du die Sql zusammen?
In 99% der Fälle liegt es eher daran das Du die Strings zusammenfrickelst statt die Parametercollection zu benutzen
und der Sql Server deshalb seine Ausführungspläne nicht cachen und Indizes nicht vorhalten kann.
Bei Prepared-Statements muss aber berücksichtigt werden, dass nach der
ersten Abfrage der Ausführungsplan im Cache liegt. Wenn bei dieser kein
Index verwendet wurde, wird bei den folgenden auch keiner verwendet.
In seinem Beispiel, den Index auf den Preis kann das eine Rolle spielen.
Z.B. haben 80% der Artikel ein Preis von 99.99, von den restlichen ist
kein Preis identisch.
Wenn als erste Abfrage nach Preisen 99.99 gesucht wird erfolgt mit großer
Wahrscheinlichkeit ein Tablescan. Bei allen nachfolgenden Abfragen ebenfalls.
Wenn nach dem einmalig auftretenden Preis von 67.89 gesucht wird erfolgt
ein Tablescan.
Auch um "Order By" zu verhindern, kann ein Index "missbraucht" werden.
Je nach Inhalt der indizierten Spalte wird dieser aber nicht verwendet und
die Sortierung erfolgt nicht wie gewünscht. Es muss offenbar doch Order By
eingesetzt werden, was nicht zwingend notwendig ist, denn
die Verwendung eines Indes kann erzwungen werden
SQL SERVER – Introduction to Force Index Query Hints – Index Hint