Discussion :

[chouffe59]

Bonjour,

Ma requête initiale :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT monchamp 
FROM matable
WHERE madate1=madate2 OR (madate1 is null AND madate2 is NULL)

Ma requête modifiée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT monchamp
FROM matable
WHERE ISNULL(madate1,GETDATE())=ISNULL(madate2,GETDATE())

Actuellement les deux requêtes me retournent le même résultat.

Question 1 : Est-il possible que lorsque madate1 et madate2 sont nulles, le test suivant soit FAUX ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ISNULL(madate1,GETDATE())=ISNULL(madate2,GETDATE())

Question 2 : Sur ma base, la seconde requête semble être plus rapide. Puis-je généraliser cette écriture pour améliorer les performances ?

Merci pour vos réponses.

[aieeeuuuuu]

Bonjour

Pour la question 1, la réponse est non.
Si madate1 est null, et madate2 est null, alors la comparaison revient à :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
GETDATE() = GETDATE()

ce qui sera toujours vrai
(la fonction GETDATE() est évaluée une seule fois par le moteur, et aura toujours la même valeur, même si ta requete mets plusieurs secondes à s'exécuter, car je crois que c'était le fond de ta question )


Pour la seconde question, le fait d'utiliser OR dans ton filtre empêche le le moteur de tirer parti des index.
De façon générale, il vaut mieux écrire :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
SELECT macolonne
FROM matable
WHERE UneColonne = X
UNION ALL
SELECT macolonne
FROM matable
WHERE UneColonne = Y

plutôt que

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
SELECT macolonne
FROM matable
WHERE UneColonne = X
OR UneColonne = Y

[Waldar]

Pour la seconde question, le fait d'utiliser OR dans ton filtre empêche le le moteur de tirer parti des index.

Vous généralisez un peu trop quand même, ce que vous dites est vrai sur des conditions complexes combinées par des OR, mais sûrement pas dans le cas de figure que vous exposez où l'emploi du OR (ou d'un IN) se justifie pleinement.

[zeus]

Bonjour,

utiliser l'opérateur OR n'interdit en rien de solliciter un index.
Une simple consultation du plan d'exécution de vos requête pourra vous en convaincre.

Je vous conseille de vous documenter :
1- structure des indexes
2- fonctionnement de l'optimiseur SQL Server

Le fonctionnement est bien compliqué. Aussi optimiser une requête ne dois pas relever du hasard.


@+

[SQLpro]

Effectivement un OR est souvent "transformé" en UNION ALL automatiquement et de manière transparente par SQL Server, afin de bénéficier des index s'il y en a....

A +

[aieeeuuuuu]

Vous généralisez un peu trop quand même, ce que vous dites est vrai sur des conditions complexes combinées par des OR, mais sûrement pas dans le cas de figure que vous exposez où l'emploi du OR (ou d'un IN) se justifie pleinement.

Oui, vous avez parfaitement raison.
Surtout qu'en relisant de plus près, dans la requete de chouffe59, il s'agit de comparer deux colonnes de la même table, ma requete engendrera donc même sans doute deux scans de la table...

Bonjour,
Le fonctionnement est bien compliqué. Aussi optimiser une requête ne dois pas relever du hasard.

Ha bon ??? j'ai toujours procédé ainsi pourtant
"plus on rate, plus on a de chance de réussir..."

Merci pour le scoop en tout cas !

@chouffe59 :
Qu'est-ce qui te fait dire que ta deuxième requete est plus rapide ? Si tu les exécutes l'une après l'autre, il est possible que la deuxième requête "semble" plus rapide car les données ont été mises en cache lors de la première, ce qui fausse les résultats si tu ne te bases que sur le temps de réponse de la requête...

[zeus]

[...] en relisant de plus près, dans la requete de chouffe59, il s'agit de comparer deux colonnes de la même table, ma requete engendrera donc même sans doute deux scans de la table...

A nouveau, je ne suis pas d'accord avec ce que vous dites
L'éventualité d'un balayage d'index n'est pas à éliminer.
Il n'y aura pas forcément de table scan.
Tous est fonction de l'indexation, de l'état des statistique calculées, de la volumétrie, etc.
Par exemple sur une table de très faible volumétrie, le table scan est souvent privilégié à un index scan. Ce n'est qu'une question de coût et de choix de l'optimiseur.

@+