Ich stimme Cade Roux zu.
Dieser Artikel sollte Sie auf den richtigen Weg bringen:
- Indizes in SQL Server 2005/2008 – Best Practices, Teil 1
- Indizes in SQL Server 2005/2008 – Teil 2 – Interna
Beachten Sie, dass Clustered-Indizes einen eindeutigen Schlüssel (eine Identitätsspalte, die ich empfehlen würde) als erste Spalte haben sollten. Im Grunde hilft es Ihren Daten, am Ende des Index einzufügen und nicht viele Festplatten-E/A und Seitenaufteilungen zu verursachen.
Zweitens, wenn Sie andere Indizes für Ihre Daten erstellen und diese clever konstruiert sind, werden sie wiederverwendet.
z.B. Stellen Sie sich vor, Sie durchsuchen eine Tabelle in drei Spalten
Staat, Bezirk, Postleitzahl.
- Manchmal suchen Sie nur nach Staat.
- Manchmal suchen Sie nach Staat und Landkreis.
- Sie suchen häufig nach Staat, Landkreis oder Postleitzahl.
Dann ein Index mit Staat, Landkreis, Postleitzahl. wird bei allen drei Suchvorgängen verwendet.
Wenn Sie häufig nur nach Postleitzahl suchen, wird der obige Index nicht verwendet (von SQL Server sowieso), da Zip der dritte Teil dieses Index ist und der Abfrageoptimierer diesen Index nicht als hilfreich ansieht.
Sie könnten dann einen Index nur für Zip erstellen, der in diesem Fall verwendet wird.
Übrigens können wir die Tatsache ausnutzen, dass bei der Multi-Column-Indizierung immer die erste Indexspalte für die Suche verwendbar ist und wenn Sie nur nach 'State' suchen, ist dies zwar effizient, aber nicht so effizient wie der Single-Column-Index auf 'State' '
Ich denke, die Antwort, nach der Sie suchen, ist, dass dies von Ihren Where-Klauseln Ihrer häufig verwendeten Abfragen und auch von Ihren Group Bys abhängt.
Der Artikel wird sehr helfen. :-)
