Considérez ce qu'est un index en SQL - et l'index est vraiment un morceau de mémoire pointant vers d'autres morceaux de mémoire (c'est-à-dire des pointeurs vers des lignes). L'index est divisé en pages afin que des parties de l'index puissent être chargées et déchargées de la mémoire en fonction de l'utilisation.
Lorsque vous demandez un ensemble de lignes, SQL utilise l'index pour trouver les lignes plus rapidement qu'en parcourant la table (en examinant chaque ligne).
SQL a des index clusterisés et non clusterisés. Ma compréhension des index clusterisés est qu'ils regroupent des valeurs d'index similaires dans la même page. De cette façon, lorsque vous demandez toutes les lignes correspondant à une valeur d'index, SQL peut renvoyer ces lignes à partir d'une page de mémoire en cluster. C'est pourquoi essayer d'indexer en cluster une colonne GUID est une mauvaise idée - vous n'essayez pas de regrouper des valeurs aléatoires.
Lorsque vous indexez une colonne d'entiers, l'index SQL contient un ensemble de lignes pour chaque valeur d'index. Si vous avez une plage de 1 à 10, alors vous auriez 10 pointeurs d'index. Selon le nombre de lignes, cela peut être paginé différemment. Si votre requête recherche l'index correspondant à "1", puis où Name contient "Fred" (en supposant que la colonne Name n'est pas indexée), SQL obtient très rapidement l'ensemble de lignes correspondant à "1", puis la table analyse pour trouver le reste.
Donc, ce que SQL fait vraiment, c'est essayer de réduire l'ensemble de travail (nombre de lignes) sur lequel il doit itérer.
Lorsque vous indexez un champ de bits (ou une plage étroite), vous ne réduisez le jeu de travail que du nombre de lignes correspondant à cette valeur. Si vous avez un petit nombre de lignes correspondantes, cela réduirait considérablement votre ensemble de travail. Pour un grand nombre de lignes avec une distribution 50/50, cela peut vous faire gagner très peu de performances par rapport à la mise à jour de l'index.
La raison pour laquelle tout le monde dit de tester est que SQL contient un optimiseur très intelligent et complexe qui peut ignorer un index s'il décide que l'analyse de la table est plus rapide, ou peut utiliser un tri, ou peut organiser les pages mémoire comme bon lui semble.
