Donc, j'ai dirigé le script de Brentozar qui a identifié 10195 plans pour la même requête !!! La requête est ci-dessous:
SELECT *
FROM [table1]
INNER JOIN [table2]
ON [table1].[versionId] = [table2].[VersionId]
INNER JOIN [table3]
ON [table2].[ContentId] = [table3].[nodeId]
INNER JOIN [table4]
ON [table3].[nodeId] = [table4].[id]
WHERE ([table4].[nodeObjectType] = 'abcde123-fgh3-4ijk-8lmn-424f222332ff')
AND ([table1].[published] = 0
AND [table1].[releaseDate] <= '2017-07-22 17:43:47')
AND ([table1].[newest]=1)
ORDER BY [table2].[VersionDate] DESC, [table4].[sortOrder]
La seule différence entre tous les 10195 d'entre eux est le champ de date (relainé). valeur qui a une date différente de chaque plan.
En ce qui concerne les index, ce qui suit s'applique:
Toute personne des idées Quelle est la meilleure façon de résoudre ce problème car il s'agit d'un grand ridicule!
Merci d'avance!
Vous pouvez définir l'option paramétrisation forcée au niveau de la base de données pour éviter ce problème, mais il dispose d'un inconvénient dans ces requêtes pourraient désormais expérimenter des problèmes de reniflement des paramètres. L'utilisation de la CPU devrait diminuer à la suite du changement. J'ai consulté sur un système qui avait une très haute utilisation du processeur et des compilations très élevées par seconde. L'activation du paramétrage forcé a chuté l'utilisation de la CPU d'environ 50%. Un autre système avait une modification minimale de l'utilisation du processeur puisque leurs compilations par seconde n'étaient pas si élevées. Dans les deux cas, la taille du cache de plan a diminué à mesure que les requêtes réutilisaient désormais des plans dans le cache plutôt que de compiler un nouveau plan de requête à chaque fois.
Sinon, vous pouvez modifier l'application afin qu'elle envoie des requêtes paramétrées/des énoncés préparés au lieu de Adhoc SQL. Ou utiliser des procédures stockées.