这不是“哪个是最快的ORM”的问题，也不是“如何用ORM编写好代码”的问题。这是另一方面：代码已经编写，它已经上线，数千名用户正在使用该应用程序，但是存在整体性能问题。 SQL事件探查器跟踪只能运行很短的时间：5分钟可以产生数十万个结果。
问题很简单：使用SQL事件探查器缩小了许多慢查询（持续时间大于给定时间），有哪些技术和解决方案可以将这些SQL查询追溯到有问题的组件中？一个相关的问题是，如果某个特定区域很慢，我们如何识别该区域正在执行的SQL，以便在SQL事件探查器中对其进行适当过滤？
这背景是我们有一个相当大的应用程序，具有相当复杂的表结构，并且目前基于通过存储过程的数据访问。如果出现SQL性能问题，通常情况下是拉出SQL分析器，找出是否有任何缓慢（按持续时间过滤）或者被抱怨的区域是否缓慢（按存储过程过滤），并调整存储过程（或模式 - 通过索引）。
现在推动我们的代码从大多数sproc解决方案转移到大多数ORM解决方案，但是对于此举的重大推动是性能问题如果出现，可以追溯到有问题的代码。我已经阅读了，似乎通常情况下，它可能涉及我们需要在服务器上安装的第三方工具（像NHProf或.NET跟踪实用程序，如dottrace的ORM跟踪实用程序）。现在是否可以在实时环境中安装其他工具是另一个问题，因此如果可以在没有其他工具的情况下执行此类操作，那么这可能是一个奖励。
我最感兴趣的是使用SQL Server 2008的解决方案，但它对于任何RDBMS都可能是通用的。就ORM技术而言，我没有特别关注当前没有使用的内容，因此有兴趣了解技术如何区别（或常见）twixt nHibernate，fluent-nhibernate和Entity Framework。如果他们提供其他东西，欢迎其他ORM： - ）
我已阅读How to find and fix performance problems (...)，我认为问题只是那里的“隔离”部分。在实时系统上易于重现 的问题将难以隔离。我在第2段中引用的数字是我们可以从个人资料中获得的数量类型......
如果你有实际的ORM跟踪实际经验，那就更好了:-)
更新，2016-10-21 ：为了完整起见，我们最终通过编写代码和覆盖NHibernate方法为NHibernate解决了这个问题。我问的其他SO问题的全部细节：NHibernate and Interceptors - measuring SQL round trip times。我希望这对于许多不同的ORM来说都是类似的方法。
答案 0 :(得分：2)
存在ORM工具的分析器，例如UberProf。它找出ORM生成的哪些SQL语句可能有问题。
例如，与选择n + 1问题类似。这些工具可能会告诉您哪些ORM查询语句导致SQL代码不良，甚至可能会改进它们。
答案 1 :(得分：0)
我们有一个带有问题的Java / Hibernate应用程序，因此我们使用了具有不同值的SET CONTEXT_INFO。如果我们在WTF查询之前看到相同SPID上的0x14，我们可以将其缩小到模块x。
不是Java人，我不确切知道他们做了什么，当然它可能不适用于.net。 IIRC你必须小心何时打开/关闭连接
我们此时也可以控制客户端负载，因此我们没有太多多余的流量。
YMMV当然，但它可能有用
我刚发现这些也很有用