Discussion :

[alavoler]

Bonjour à tous,

Je voudrais m'assurer de 2 optimisations : (mythe ou réalité ?)

1. Il faut éviter d’utiliser la fonction ISNULL sur les clauses ON et WHERE, en général cela se traduit par un table SCAN ou un INDEX SCAN

Typiquement il faut remplacer:
ON t.Code = t2.Code AND ISNULL(t2.Type,0) IN (4,8)
Par
ON t.Code = t2.Code AND (t2.Type IN(4,8) AND Type IS NOT NULL)

2. Il faut utiliser les partitions de tables. En s'appuyant sur le champs sur lequel on s'appuye pour faire les partitions.

Or si on met un ISNULL sur ce champ, on scan toutes les partitions, et on perd l'interet des partitions.

Typiquement il faut remplacer:
AND ISNULL(date1,getdate()) >= date2

Par
AND (date1 >= date2 OR date1 IS NULL)


Est ce que les recommandations 1. et 2. sont une bonne pratique et est ce une réelle optimisation ?

Car j'ai essayé d'évaluer le cout en IO (SET STATISTICS IO ON) sur une requete, et j'ai remarqué que cette "optimisation" faisait gonfler légerement les Nombre d'analyses et les lectures logiques !

Merci pour votre éclairage

[StringBuilder]

Plutôt que de répondre à la question par des explications du moteur de SQL Server, je dirais avant tout :
- ISNULL ne fait pas partie de la norme. Privilégiez dans tous les cas COALESCE, qui en plus à la même syntaxe, en plus complète !
- Dans votre premier exemple, le test de nullité ne sert à rien, puisque NULL ne fait pas partie du IN, dans tous les cas : pas la peine de le remplacer par une valeur bidon ou de le tester explicitement
- A partir du moment où il y a un OR dans votre condition, de toute façon, l'optimiseur est mis à mal, donc à tester au cas pas cas, mais pas certain que vos "optimisations" apportent quoi que ce soit.

Accessoirement, une base de données ne devrait jamais contenir de NULL.
La présence de cette non valeur dans vos tables met en valeur des erreurs notables de conception. Commencez par rechercher de ce côté !

Habituellement, les tests sur la nullabilité ne servent que d'aiguillages dans des requêtes de type OUTER JOIN, ou pour de la mise en forme dans le SELECT. Mais pas comme critère de recherche !

[SQLpro]

2. Il faut utiliser les partitions de tables. En s'appuyant sur le champs sur lequel on s'appuye pour faire les partitions.

Pas clair...

De toutes les façons le partitionnement n'a d'intérêt en pratique que si deux conditions sont réunies simultanément :
1) le volume global de la table (en octets) soit très important (supérieure à la RAM par exemple)
2) le critère de partitionnement fasse partie de la clause WHERE ou ON (de l'opérateur JOIN), pour une très grandes majorité de requête.
Pour le 2, mieux vaut donc avoir prévu cela à la conception de votre BD dans votre MCD ! Sans cela, un partitionnement sauvage sans étude préalable, risque de produire l'effet inverse !

A +