准备好的SQL性能监视？

Question

我的公司正在考虑在一些应用程序中全面使用准备好的SQL。几天来，我一直试图回答“我们是否有一种方法监视性能”的问题，例如看到SQL事务具有高持续时间/CPU/IO操作，以及它为产生高负载所做的事情。我遇到的很多问题都是担心这在Microsoft中是不必要的/过时的。我对此提出了担忧，但与此同时，我仍在努力想出一种跟踪活动的方法。

我所确定的最好的是，我们可以拥有我们一直拥有的标准性能监控，但我们也需要一种“神奇解码器环”跟踪/XE会话。这必须跟踪准备/取消准备SQL操作才能获得句柄，而关联的语句完成消息才能获得每个SPID的关联查询。然后，如果我们在性能监控中遇到一个事务，会说"sp_execute、32等.“我们将查看请求此操作的SPID，获取该句柄# 32 (或其他什么)，并查看我们神奇的解码器环，以确定正在运行的参数化SQL语句是什么以进行分析。

我们目前需要使用的答案是支持SQL2008R2和up (我们现在已经部署了数百个这个版本，因为我们正开始进入下一个世代)，这就是为什么我提到了SQL跟踪，因为由于XE在SQL2012之前的局限性，我们仍然在XE上使用它来进行许多部署。

我们仍将研究准备好的SQL是否对我们是一个好主意，因为研究中出现的一些新信息表明它可能不是。我只是想问，是否有一种干净的方法可以直接监视通过准备好的SQL完成的操作，而不需要这样一个繁琐的“神奇解码器环”方法来跟踪准备好的SQL是什么。

Answer 1

您很可能需要捕获语句级事件，因为对sp_execute的“已完成”RPC调用不会显示批处理本身。

另外，您需要的不仅仅是SPID。会话ID被重用，因此它不够细粒度的密钥。您还需要连接ID，因为它更独特，也是准备语句的缓存数组绑定的对象。

最后，采取准备好的发言的动力是什么？它们的唯一好处是，如果应用程序经常发送相同的参数化查询，则可以在网络请求中保存一定数量的字节。通常更好的做法是调用存储过程，这样您就不会每次发送查询。最近有人建议，准备好的语句可能比存储过程更快，但这是一个非常具体的用例:简单的DML语句每天至少执行1-2次(也就是说，同一个INSERT INTO dbo.Table (@1, @2, @3);以不同的值执行了20亿次)。

如果您正在执行非参数化的临时查询，那么使用准备好的语句充其量是一文不值的，而在最坏的情况下，这是一种倒退，因为它们更难监控。

也请在DBA.SE上看到我对以下问题的回答：

使用SqlCommand.Prepare()有什么意义和好处？