sql-server - 基于 XML 的查询通过 ADO.NET 极其缓慢，通过 SSMS 即时

Question

我经常遇到这样的情况:查询通过 SSMS 立即运行并进行少量读取，但在通过 ADO.NET 运行时速度慢到数千次读取时会超时。与我在 StackOverflow 上找到的其他问题不同，清除查询缓存(或强制自己使用 SSMS 使用的缓存)似乎并不能解决问题。

通常，当其他人在 StackOverflow 上报告这种情况时，他们的查询缓存已损坏。在所有这些情况下，解决方法是使用 SET ARITHABORT ON 运行 ADO.NET 查询(以匹配 SSMS 使用的 session 设置)或运行 DBCC DROPCLEANBUFFERS code> 和 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 运行，实际使用的查询计划看起来很合适(索引查找)，并且在 4 毫秒内需要大约 200 次读取。运行 Web 应用程序，每秒大约需要 4500 次读取。

我在这里缺少什么？尽管有 DBCC 调用和 ARITHABORT 设置，但通过 Web 应用程序运行时，是否可能会恢复错误的查询计划？

Answer 1

简单的修复方法是在 (ixCustomer、ixRepo、ixChangeset) 上放置多列索引。在不知道这些列实际上是什么、它们是否唯一等的情况下，很难想出更好的答案。