XML-запрос чрезвычайно медленный через ADO.NET, мгновенный через SSMS

Я нахожусь в постоянной ситуации: запрос, который выполняется мгновенно через 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?