Plan de requête Cache gonflée par des requêtes ad hoc, même avec «Optimiser pour les charges de travail ad-hoc»

Question

J'ai remarqué ce que je pensais être des problèmes inhabituels avec notre cache de plan de requête, où les plans dans la cache n'étaient jamais plus d'un jour.

En exécutant la requête suivante (gracieuseté de Kimberly Tripp), il a montré que la majorité des plans (4,5 Go de plans en cache de 6 Go ou 44813 de ~ 50000), étaient des requêtes ad hoc qui avaient un nombre d'utilisation de 1.

SELECT objtype AS [CacheType]
    , count_big(*) AS [Total Plans]
    , sum(cast(size_in_bytes as decimal(18,2)))/1024/1024 AS [Total MBs]
    , avg(usecounts) AS [Avg Use Count]
    , sum(cast((CASE WHEN usecounts = 1 THEN size_in_bytes ELSE 0 END) as decimal(18,2)))/1024/1024 AS [Total MBs - USE Count 1]
    , sum(CASE WHEN usecounts = 1 THEN 1 ELSE 0 END) AS [Total Plans - USE Count 1]
FROM sys.dm_exec_cached_plans
GROUP BY objtype
ORDER BY [Total MBs - USE Count 1] DESC

J'ai déterminé la requête du problème (dynamique, avec un EXEC, bien sûr ...), ce qui est plutôt hideux, mais aussi compliqué de «réparer», donc je cherchais des améliorations immédiates qui pourraient être apportées.

L'instance est déjà définie pour utiliser Optimiser pour les charges de travail ad hoc, mais le CacheObjType de sys.dm_exec_cached_plans sont tous Plan compilé plutôt que Stume de plan compilé.

Lorsque vous utilisez le mode de charge de travail ad hoc, si les plans ne sont pas Stume de plan compilé jusqu'à leur usecounts sont supérieurs à 1? Ou n'est-ce pas ainsi que cela fonctionne?

Il y a aussi un refcounts Field que personne ne semble se référer lorsqu'il parle de requêtes ADHOC. Les refroits sont toujours 1 lorsque le type est Stume de plan compilé et 2 quand le type est Plan compilé. Même en lecture Bol, Je ne suis pas entièrement sûr de ce que ce domaine signifie. Quelqu'un peut-il clarifier?