Я нахожусь в постоянной ситуации: запрос, который мгновенно запускается через SSMS с небольшим числом операций чтения, но достаточно медленный, чтобы выдерживать тысячи операций чтения при запуске через ADO.NET. В отличие от другие вопросы, которые я мог найти в StackOverflow, очистка кэша запросов (или принуждение к использованию того, что использует SSMS), похоже, не работают.
Обычно, когда другиесообщили об этой ситуации в StackOverflow, у них были поврежденные кэши запросов.Во всех этих случаях исправлением было либо выполнение запросов ADO.NET с SET ARITHABORT ON (в соответствии с настройками сеанса, используемыми SSMS), либо запуск DBCC DROPCLEANBUFFERS и DBCC FREEPROCCACHE, чтобы принудительно перестроить кэш запросов.,Эти методы не имеют никакого значения в моем приложении, заставляя меня поверить, что происходит нечто более фундаментальное.
Вопрос, о котором идет речь, таков (настоящий дословный запрос, захваченный SQL Profiler, очищен только для форматирования):
declare @p5 xml
set @p5=convert(xml,N'<r>
<n v="66ebc21b3bcb31e9a5ecbfb4b29fd2a47c37994c"/>
<n v="665919306fb23d9e685638a2d199e1e623745305"/>
<n v="a080c3b4e0c86e37b4d494d5efc09cebe20c6929"/>
<n v="245cb49bdeca9e37ef9bbd55877e21ade14e6282"/>
<n v="297650a6be65be332c1bb2aab426331a156ee342"/>
<n v="6a2668c8ab64fecf3b6925c7be613c61cef4dd7c"/>
<n v="09923f25f8b1de19f693bca1111bfa50d617856e"/>
<n v="0a7836d8e4e34f4ea92b2105eea5a99029949428"/></r>')
exec sp_executesql N'
SELECT ixChangesetTag, ixRepo, ixChangeset, sTag, fBookmark
FROM ChangesetTag
INNER JOIN @p2.nodes(''/r/n'') X(n) ON X.n.value(''xs:hexBinary(@v)'', ''binary(20)'') = ixChangeset
WHERE ixRepo = @p0 AND ixCustomer = @p1',N'@p0 bigint,@p1 int,@p2 xml',@p0=2,@p1=23363,@p2=@p5
(Параметр XML предназначен для того, чтобы разрешить использование параметризованного запроса, в котором у меня обычно бывают проблемы с этим, поскольку число объектов, которые я хочу передать, варьируется. Табличными процедурами будет 2008способ сделать это, но некоторые из наших клиентов работают в 2005 году.)
Запускается через SSMS, фактический используемый план запроса выглядит соответствующим (поиск индекса) и занимает около 200 операций чтения в течение 4 мс.Запустите веб-приложение, за секунду уйдет около 4500 операций чтения.
Что мне здесь не хватает?Может ли что-то восстанавливать неверный план запросов при запуске через веб-приложение, несмотря на вызовы DBCC и настройки ARITHABORT?