Dies ist der Anfang einer Reihe von "Best Practice" Beiträgen. Mehr noch als bei anderen Beiträgen würde ich mir hier Feedback wünschen, das dann in den Beitrag einfließen kann. Ziel soll es sein, einen Rahmen zu bilden mit allgemein anerkannten und zugestimmten Richtlinien, Empfehlungen, Tips. Aus diesem Anspruch heraus wird deutlich, daß dies weder ich, noch irgendjemand anderes allein auf die Beine bringen kann; vielmehr muss dies eine Teamarbeit einer Community werden. Ich mache jetzt einmal lediglich den Anfang mit ein paar Richtlinien zur Indexerstellung.

Allgemeine Empfehlungen:

Indexes können Daten Retrieval Operationen deutlich beschleunigen. Soweit zur positiven Seite. Indexes können aber auch Datenmanipulationsoperationen deutlich verlangsamen, da sie bei jedem UPDATE, INSERT und DELETE gepflegt werden müssen. Daher ist der umsichtige Einsatz von Indexes eine der Schlüsselstellen, die über eine gute oder schlechte Performance entscheiden. Man mag vieles vielleicht durch leistungsstärkere Hardware kaschieren; irgendwann einmal aber kommt man an den Punkt, an dem dies nicht mehr möglich ist. Daher sollte von Anfang an Wert auf ein gutes Schema und sinnvolle Indexes gelegt werden. 

Empfehlungen zur Erstellung von Gruppierten Indexes (Clustered Indexes):

SQL Server erstellt automatisch einen PRIMARY KEY als clustered, sofern dies nicht explizit anders (NONCLUSTERED) angegeben wird. Obwohl dies idR besser ist, als überhaupt keinen clustered Index auf einer Tabelle zu haben, hat die Wahl des clustered Index entscheidenden Einfluß auf die Performance und häufig gibt es bessere Kandidaten für den clustered Index als den PRIMARY KEY.

Jede Tabelle kann nur einen clustered Index besitzen; was die Auswahl teilweise schwierig machen kann. Man muß berücksichtigen, welche Abfragen über diese Tabelle laufen ung ggfs. Tests der Performance unter verschiedenen clustered Indexes durchführen.

Empfehlungen zur Erstellung von Multi-Spalten Indexes (Composite Indexes):

Die Reihenfolge der Spalten sollte von der Spalte mit der höchsten Eindeutigkeit abwärts zur Spalte mit der geringsten Eindeutigkeit lauten, da die Statistiken nur für die erste Spalte gespeichert werden.

Composite Indexes sollten nach Möglichkeit nicht als clustered erstellt werden. Grund dafür ist, das sämtlichen nonclustered Indexes auf dieser Tabellen die clustered Index Schlüssel als Bookmark mitführen. Je weiter also nun der clustered Index ist, umso weiter sind nun auch die nonclustered Indexes; belegen also mehr Platz. Dies wiederum führt dazu, daß weniger Indexdaten auf eine Seite passen und SQL Server u.U. mehr I/O Operationen durchführen muß.

Sucht man häufig nach einer Spalte des composite Index, die nicht an erster Stelle im Index steht und damit die Sortierreihenfolgt bestimmt, macht ein separater Index auf dieser Spalte u.U. Sinn