Ecriture requête et performance

[chouffe59]

Bonjour,

Ma requête initiale :

Code :

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

Ma requête modifiée :

Code :

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 :

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 :

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 :

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 :

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

[Waldar]

Envoyé par aieeeuuuuu

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]

Envoyé par Waldar

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...

Envoyé par zeus

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]

Envoyé par aieeeuuuuu

[...] 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.

@+

[aieeeuuuuu]

Envoyé par zeus

L'éventualité d'un balayage d'index n'est pas à éliminer.

Je ne l'élimine pas...
bien sûr, si un index adéquat existe, le balayage pourra être effectué sur cet index plutôt que sur la table, mais cela restera un balayage.
Je faisais simplement remarquer que dans le cas de la requete de chouffe59, UNION ALL, ne permettrait effectivement pas une recherche d'index (ce qui était le but de l'UNION ALL que je proposait initialement, mais ça, je pensais que vous l'aviez compris...) mais qu'il s'agirait bien de balayage, et que ce balayage pourrait en plus avoir lieu deux fois, ce qui au final pourrait être pire que mieux...