SQL Server 2008 a quelque peu facilité le contrôle des plans d’exécutions de requêtes grâce au « conseil » FORCESEEK. Ce mot clé permet d’indiquer au moteur que l’on souhaite utiliser pleinement la structure des index pour aller chercher les données, au lieu de parcourir l’ensemble de la table.

SQL Server 2012 apporte désormais le mot clé symétrique, FORCESCAN, qui permet d’indiquer au moteur qu’il n’est pas question d’aller chercher les éléments un par un, mais qu’il est, selon l’avis du développeur en tout cas, préférable de parcourir l’ensemble de la table.

Tout d’abord, revenons brièvement sur ce que sont un SEEK et un SCAN. Pour cela, au final, le plus simple est de s’appuyer sur les icônes représentant ces opérations dans un plan d’exécution.

Dans un premier temps, l’Index Scan () consiste à commencer à la première page de niveau feuille de l’index, et ensuite à parcourir l’ensemble des données, de page en page suivante, jusqu’au bout de l’ensemble de données.

L’Index Seek (), quant à lui, exploite pleinement l’arbre B de l’index et atteint directement le ou les enregistrements recherchés, à partir du prédicat de recherche qui correspond à la clé de l’index (ou au moins à son début).

Ce nouvel hint, FORCESCAN, peut donc forcer un plan d’exécution à utiliser un scan, là où le moteur choisirait éventuellement un Seek.

USE tempdb
SET NOCOUNT ON
CREATE TABLE TableTest (Id int PRIMARY KEY, Valeur varchar(Max))
GO
INSERT INTO TableTest (Id, Valeur) select isnull(Max(Id),0)+1,convert(varchar(max),isnull(Max(Id),0)+1) FROM TableTest
GO 100000

Bien sûr, sur cet exemple, je tairai le comparatif des performances dans ce cas d’école.

Mais dans des cas de statistiques ne reflétant pas certaines particularités de répartition des données, il est tout à fait possible que ce mot-clé puisse améliorer les performances d’une requête particulière…