En termes de SQL Server, cela a été qualifié de point de basculement, dont le billet de blog de Kimberley est une bonne lecture. http://www.sqlskills.com/BLOGS/KIMBERLY /category/The-Tipping-Point.aspx
Le point de basculement est une ligne directrice de 25 % à 33 % du nombre total de pages dans le tableau, exprimées en lignes, par ex. 10 000 pages de données donneraient un point de basculement de 2 500 à 3 333 lignes. Selon les directives, c'est plutôt bon, et aussi bon que vous obtiendrez - rappelez-vous que le moteur de plan de requête est une boîte noire, et bien qu'il vous donne un plan de requête, il ne dit que ce qu'il a décidé, pas pourquoi.
En ce qui concerne le basculement d'un index de couverture, ce n'est en fait pas très facile, même avec 100 % des données sélectionnées, un index de couverture cherchera toujours à surscanner dans la majorité des cas.
Cela a du sens, si vous considérez que l'optimiseur de coût n'attribue aucun coût réel à la hiérarchie des pages d'index, tout ne coûte que l'accès aux pages feuilles de l'index. À ce stade, la numérisation ou la recherche de 100 % d'un index de couverture coûte le même prix.
J'ai trouvé de ma propre expérimentation (http ://sqlfascination.com/2009/11/07/can-a-covering-nc-index-be-tipped ) l'utilisation d'une clause between entraînerait une analyse, mais pas d'autres clauses where - d'après ce que j'ai pu dire, cela dépendait uniquement de la route via le moteur de requête.
