Discussion :

[François DORIN]

Car d'un point de vue performances, entre comparer une valeur à N valeurs, ou lui appliquer un masque binaire et vérifier si le résultat est différent de zéro, c'est le jour et la nuit !

On est quand même dans le cas très particulier où N=2 et où la table personne comprend 3 colonnes (si on reprend ta définition). Le résultat serait sans doute différent si N > 2 et/ou si la table contenait plus de colonnes. Je vois une raison pour laquelle l'optimiseur n'utilise pas l'index : il voit qu'il n'y a que 2 valeurs. L'index lui indique une répartition 50/50 (à peu près hein). Avec l'index, il récupère 2 des 3 colonnes de la table personne. Dans ce cas précis, il pourrait donc être plus coûteux d'utiliser l'index que de ne pas l'utiliser ! Car s'il utilise l'index, il est ensuite obligé d'aller chercher la moitié des enregistrements dans la table, donc lire la moité de la table. Comme il y a des chances que l'index sur le sexe ne soit plas CLUSTERED, statistiquement, il sera obligé de lire quasiment toutes les pages. Donc, autant ne pas l'utiliser.

Un test à faire, se serait de recréer l'index en incluant la colonne "nom" (je dis bien incluse, pas faisant partie de). Là, il se pourrait qu'il y ait un bénéfice pour les recherches "homme" ou "femme" (mais pas les deux, puisque cela reviendrait à renvoyer tous les enregistrements).

[aieeeuuuuu]

C'est pire que cela:
ce n'est pas que l'optimiseur estimera que l'utilisation de l'index sera plus couteuse, c'est qu'il ne peut pas l'utiliser, car il ne sait pas quoi chercher !

il est obligé de récupérer toutes les valeurs pour cette colonne, pour y appliquer l'opération bit à bit avant de pouvoir faire la comparaison

La raison de non utilisation de l'index indiquée par dorinf serait plutôt justement dans le cas d'un In ou d'un OR.

[François DORIN]

ce n'est pas que l'optimiseur estimera que l'utilisation de l'index sera plus couteuse, c'est qu'il ne peut pas l'utiliser, car il ne sait pas quoi chercher !

C'est là où j'ai un doute. Je m'explique : l'optimiseur, quand il voit la requête, il se rend compte qu'il y a une opération à effectuer avec une colonne qui est indexée. L'index connait les différentes valeurs contenues dans la colonne. Il est donc tout à fait possible de réaliser les calculs en utilisant l'index. Ainsi, le calcul est effectué... 2x uniquement pour le cas qui nous intéresse ! Une pour chaque valeur de l'index. Bon, ça c'est en théorie, en pratique, il y a peut être des limitations qui font que ce n'est pas possible.

[aieeeuuuuu]

. L'index connais les différentes valeurs contenues dans la colonne. Il est donc tout à fait possible de réaliser les calculs en utilisant l'index.

tout à fait.
Quand je disais qu'il n'était pas possible d'utiliser l'index, je voulais parler d'une recherche d'index.

Mais en effet, l'optimiseur pourra faire le choix de scanner l'index plutôt que la table afin de réduire le nombre de pages nécessaires pour répondre au besoin (et si l'index est couvrant, l'index a en effet toutes les chances d'être utilisé... mais il sera lu intégralement ce qui réduit l’intérêt)

[François DORIN]

Ah d'accord, c'est plus clair pour moi ainsi Merci.