Query plus lent après la mise à niveau de SQL Server 2008R2 à 2014SP2
J'ai récemment mis à niveau à partir de SQL Server 2008R2 à 2014SP2 et a mis à niveau les bases de données au niveau de compatibilité 120.
[.____] Cette requête génère un meilleur plan d'exécution avec l'ancien estimateur de cardinalité (Traceflag 9481 activé): https://www.brentozar.com/pastetheplan/?id=hy9skv1ox
Il n'utilise que 269 lectures logiques sur objet2 et 3 sur objet3.
[.____] avec le nouvel estimateur de cardinalité, je reçois ce plan d'exécution: https://www.brentozar.com/pastetheplan/?id=bjanpxk_e
[.____] Malheureusement, cela se traduit par 269 lectures logiques sur Object2 et 68688 sur objet3.
[.____] Le serveur est configuré pour la charge de travail Adhoc.
[.____] même permettant à Traceflag 4199 n'améliore pas le plan estimations/exécution
[.____] Pourquoi le nouvel estimateur de cardinalité génère-t-il un plan aussi pire?
Pourquoi les estimations sont-elles si loin?
[.____] Que pourrais-je faire pour l'améliorer en plus de désactiver le nouvel estimateur ou d'utiliser des allumettes de requête?
Pour une raison quelconque, la nouvelle CE utilise différents index, qui donnent toutes deux une estimation de 1 rangée, d'où la jointure en boucle mal appréciée.
[.____] Êtes-vous en mesure de mettre à jour les statistiques sur les deux tables avec FullScan? Si cela ne vous aide pas, veuillez publier la table et les définitions d'index (avec seulement les noms de table/colonne/index anonymed).
Aside:
L'aliose ObjectX dans votre code d'échantillon est très déroutant, vous voudrez peut-être reconsidérer la prochaine fois que vous devez avoir besoin d'anonyme, en particulier pour une requête plus complexe. Aliasx pour tous les alias, avec x correspondant à l'ObjectX, pourrait être une amélioration.
En passant, si vous n'avez pas soigneusement examiné l'utilisation cohérente de Nolock, vous voudrez peut-être lire ceci: https://sqlperformance.com/2015/04/t-sql-queries/the-read- Niveau d'isolement non engagé