Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Soll ich ein Bitfeld in SQL Server indizieren?

Überlegen Sie, was ein Index in SQL ist - und Index ist wirklich ein Teil des Speichers, der auf andere Teile des Speichers zeigt (dh Zeiger auf Zeilen). Der Index ist in Seiten unterteilt, sodass Teile des Index je nach Verwendung aus dem Speicher geladen und entladen werden können.

Wenn Sie nach einer Reihe von Zeilen fragen, verwendet SQL den Index, um die Zeilen schneller zu finden als das Scannen von Tabellen (wobei jede Zeile untersucht wird).

SQL hat geclusterte und nicht geclusterte Indizes. Mein Verständnis von Clustered-Indizes ist, dass sie ähnliche Indexwerte auf derselben Seite gruppieren. Auf diese Weise kann SQL, wenn Sie nach allen Zeilen fragen, die mit einem Indexwert übereinstimmen, diese Zeilen aus einer gruppierten Speicherseite zurückgeben. Aus diesem Grund ist der Versuch, eine GUID-Spalte zu gruppieren, eine schlechte Idee - Sie versuchen nicht, zufällige Werte zu gruppieren.

Wenn Sie eine ganzzahlige Spalte indizieren, enthält der SQL-Index eine Reihe von Zeilen für jeden Indexwert. Wenn Sie einen Bereich von 1 bis 10 haben, dann hätten Sie 10 Indexzeiger. Je nachdem, wie viele Zeilen vorhanden sind, kann dies unterschiedlich ausgelagert werden. Wenn Ihre Abfrage nach dem Index sucht, der mit „1“ übereinstimmt, und dann, wo Name „Fred“ enthält (vorausgesetzt, die Spalte „Name“ ist nicht indiziert), ruft SQL sehr schnell den Satz von Zeilen ab, die mit „1“ übereinstimmen, und scannt dann die Tabelle, um den Rest zu finden.

Was SQL also wirklich tut, ist zu versuchen, den Arbeitssatz (Anzahl der Zeilen) zu reduzieren, über den es iterieren muss.

Wenn Sie ein Bitfeld (oder einen engen Bereich) indizieren, reduzieren Sie den Arbeitssatz nur um die Anzahl der Zeilen, die diesem Wert entsprechen. Wenn Sie eine kleine Anzahl von übereinstimmenden Zeilen haben, würde dies Ihren Arbeitssatz erheblich reduzieren. Bei einer großen Anzahl von Zeilen mit einer 50/50-Verteilung können Sie möglicherweise nur einen sehr geringen Leistungsgewinn erzielen, anstatt den Index auf dem neuesten Stand zu halten.

Der Grund, warum alle zum Testen sagen, ist, dass SQL einen sehr cleveren und komplexen Optimierer enthält, der einen Index ignorieren kann, wenn er entscheidet, dass das Scannen von Tabellen schneller ist, oder eine Sortierung verwendet oder Speicherseiten organisiert, wie es ihm verdammt gut gefällt.