Laden...

Auswirkungen Indizes nicht nur auf Performance sondern auch auf Sortierung

Erstellt von Coooder vor 9 Jahren Letzter Beitrag vor 9 Jahren 2.989 Views
C
Coooder Themenstarter:in
180 Beiträge seit 2011
vor 9 Jahren
Auswirkungen Indizes nicht nur auf Performance sondern auch auf Sortierung

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? ^^

C
2.121 Beiträge seit 2010
vor 9 Jahren

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.

L
53 Beiträge seit 2007
vor 9 Jahren

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.

W
955 Beiträge seit 2010
vor 9 Jahren

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.

T
2.219 Beiträge seit 2008
vor 9 Jahren

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.

T
415 Beiträge seit 2007
vor 9 Jahren

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.

C
Coooder Themenstarter:in
180 Beiträge seit 2011
vor 9 Jahren

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?

W
955 Beiträge seit 2010
vor 9 Jahren

Auf welcher Spalte liegt dein Index?

C
Coooder Themenstarter:in
180 Beiträge seit 2011
vor 9 Jahren

Beim ersten beispiel lag er auf Date

bei den neuen Tabellen zumbeispiel auf Preis der Haus Tabelle

W
955 Beiträge seit 2010
vor 9 Jahren

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)

P
1.090 Beiträge seit 2011
vor 9 Jahren

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:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

F
10.010 Beiträge seit 2004
vor 9 Jahren

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.

R
74 Beiträge seit 2006
vor 9 Jahren

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