这不是一个“哪个是最快的 ORM”问题，也不是关于“如何使用 ORM 编写优秀代码”的问题。这是另一个方面：代码已经编写好了，已经上线，数千个用户正在访问应用程序，但存在一个总体性能问题。SQL Profiler 跟踪只能运行短时间：5 分钟就会产生数十万条结果。
问题很简单：在使用 SQL Profiler 缩小了一些缓慢查询（持续时间大于给定时间）之后，有哪些技术和解决方案可用于将这些 SQL 查询追溯回到具有问题的组件？相关问题是，如果特定区域很慢，我们如何识别该区域执行的 SQL 以便在 SQL Profiler 中适当过滤？
背景是我们有一个相当复杂的表结构的大型应用程序，目前基于存储过程进行数据访问。如果出现 SQL 性能问题，则通常是使用 SQL Profiler，查找是否有任何缓慢的地方（按持续时间过滤）或者被投诉的区域很慢（按存储过程过滤），然后调整存储过程（或架构-通过索引）。
现在有一个推动，将我们的代码从主要的存储过程解决方案转移到主要的ORM解决方案，但是对移动的大力推动是如何追踪性能问题，如果出现问题，可以追溯到有问题的代码。我读了一些资料，似乎往往涉及第三方工具（ORM跟踪实用程序，如NHProf或.NET跟踪实用程序，如dottrace），我们需要在服务器上安装这些工具。现在是否可以在实时环境中安装其他工具是另一个问题，因此，如果可以在没有其他工具的情况下执行此类操作，则可能会有额外的奖励。
我主要对SQL Server 2008的解决方案感兴趣，但它可能足够普遍适用于任何RDBMS。至于ORM技术，在这方面我没有特定的重点，因为目前没有使用任何东西，所以很想听听nHibernate、fluent-nhibernate和Entity Framework之间的技术差异（或者是共同点）。其他ORM如果提供其他功能也是可以接受的 :-)
我已经阅读了如何找到和解决性能问题...，我认为问题仅仅在于其中的“隔离”部分。一个只在实际系统中容易重现的问题将会很难被隔离。我在第二段引用的数字是我们可以从配置文件中获取的数据类型...
问题很简单：在使用 SQL Profiler 缩小了一些缓慢查询（持续时间大于给定时间）之后，有哪些技术和解决方案可用于将这些 SQL 查询追溯回到具有问题的组件？相关问题是，如果特定区域很慢，我们如何识别该区域执行的 SQL 以便在 SQL Profiler 中适当过滤？
背景是我们有一个相当复杂的表结构的大型应用程序，目前基于存储过程进行数据访问。如果出现 SQL 性能问题，则通常是使用 SQL Profiler，查找是否有任何缓慢的地方（按持续时间过滤）或者被投诉的区域很慢（按存储过程过滤），然后调整存储过程（或架构-通过索引）。
现在有一个推动，将我们的代码从主要的存储过程解决方案转移到主要的ORM解决方案，但是对移动的大力推动是如何追踪性能问题，如果出现问题，可以追溯到有问题的代码。我读了一些资料，似乎往往涉及第三方工具（ORM跟踪实用程序，如NHProf或.NET跟踪实用程序，如dottrace），我们需要在服务器上安装这些工具。现在是否可以在实时环境中安装其他工具是另一个问题，因此，如果可以在没有其他工具的情况下执行此类操作，则可能会有额外的奖励。
我主要对SQL Server 2008的解决方案感兴趣，但它可能足够普遍适用于任何RDBMS。至于ORM技术，在这方面我没有特定的重点，因为目前没有使用任何东西，所以很想听听nHibernate、fluent-nhibernate和Entity Framework之间的技术差异（或者是共同点）。其他ORM如果提供其他功能也是可以接受的 :-)
我已经阅读了如何找到和解决性能问题...，我认为问题仅仅在于其中的“隔离”部分。一个只在实际系统中容易重现的问题将会很难被隔离。我在第二段引用的数字是我们可以从配置文件中获取的数据类型...
如果你有ORM追踪实际经验，那就更好了:-)
更新，2016-10-21：为了完整起见，我们最终通过编写代码并覆盖NHibernate方法来解决了这个问题。有关完整详细信息，请参阅我提出的这个其他SO问题：NHibernate和拦截器-测量SQL往返时间。我相信这对许多不同的ORM都是一种类似的方法。