266
Chapitre 8. Optimisation du code SQL
est stocké dans la clé de l’index. Toute modification de colonne dans l’expression,
comme par exemple une concaténation, un passage dans une fonction, ou un changement de collation à la volée, empêchera toute utilisation d’index, et forcera par
conséquent le scan. C’est donc à éviter. Exemples de choses à ne pas faire :
SELECT FirstName, LastName
FROM Person.Contact
WHERE LastName COLLATE Latin1_General_CI_AI = 'Jimenez';
SELECT FirstName, LastName
FROM Person.Contact
WHERE LEFT(LastName, 2) = 'AG';
SELECT FirstName, LastName
FROM Person.Contact
WHERE LastName + FirstName = 'AlamedaLili';
écrivez donc vos filtres plutôt comme ceci :
SELECT FirstName, LastName
FROM Person.Contact
WHERE LastName LIKE 'Jim[eé]nez';
SELECT FirstName, LastName
FROM Person.Contact
WHERE LastName LIKE 'AG%';
SELECT FirstName, LastName
FROM Person.Contact
WHERE LastName = 'Alameda' AND FirstName = 'Lili';
L’opérateur LIKE permet l’utilisation de l’index, à condition que le début de la
chaîne soit fixe. Il correspond ainsi au début de la clé de l’index, et est donc SARGable, comme on peut chercher efficacement dans un annuaire en ne connaissant que
les quelques premières lettres d’un nom.
Cette règle est valable aussi pour les opérations arithmétiques. SQL Server n’est
pas capable de modifier une expression contenant des opérations sur des constantes
pour la simplifier, une opération connue en compilation sous le nom de constant folding. Prenons un exemple :
SELECT *
FROM Person.Contact
WHERE ContactId + 3 = 34;
SELECT *
FROM Person.Contact
WHERE ContactId = 37;
Il n’est pas très difficile pour un compilateur de transformer automatiquement la
première clause en la seconde. Pourtant, SQL Server ne le fait pas, comme nous le
voyons dans les plans d’exécution en figure 8.11.