Une requête connaissant un ralentissement significatif lors de l'utilisation d'une expression de date dans une clause WHERE par rapport à une valeur littérale de chaîne pose un dilemme en termes de performances de requête. Approfondissons le problème et cherchons une solution.
L'écart de performances est dû à un bug dans SQL Server 2008, qui affecte les estimations de cardinalité lors de l'utilisation d'une expression de date dans un Clause OÙ. Le bug entraîne des estimations incorrectes du nombre de lignes correspondantes.
Pour contourner ce bug, la requête optimisée suivante est suggérée :
Where FK.DT = cast(getdate() + 1 - datepart(day, getdate()) as date)
Cette expression renvoie le début du mois en cours, qui est probablement le critère de sélection souhaité dans ce scénario.
Alternativement, l'indicateur de trace 4199 peut être activé pour forcer des estimations précises de cardinalité. Avec l'indicateur de trace 4199 activé, la requête suivante produira également le plan souhaité :
Where FK.DT = CAST(DATEADD(m, DATEDIFF(m, 0, getdate()), 0) as DATE) OPTION (QUERYTRACEON 4199)
Par exemple, avec une table appelée FK contenant une colonne appelée DT avec des valeurs représentant le début de chaque mois, les deux requêtes suivantes démontrent l'écart de performances :
-- Slow due to incorrect cardinality estimates SELECT COUNT(Filler) FROM FK WHERE FK.DT = CAST(DATEADD(m, DATEDIFF(m, 0, getdate()), 0) AS DATE) -- Fast due to accurate cardinality estimates with trace flag 4199 SELECT COUNT(Filler) FROM FK WHERE FK.DT = CAST(DATEADD(m, DATEDIFF(m, 0, getdate()), 0) AS DATE) OPTION (QUERYTRACEON 4199)
Avec l'indicateur de trace 4199 activé, la deuxième requête sera entraîne un temps d'exécution nettement plus rapide grâce au plan de requête optimisé.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!