从NHibernate应用程序执行相同的SQL查询比SQL Studio慢？

我们的应用程序发出一个NHibernate生成的SQL查询。在应用程序运行时，查询在SQL Server数据库上运行大约需要12秒钟。SQL分析器显示超过500000次读取

但是，如果我使用SQL Profiler捕获确切的查询文本，并从SQL Studio再次运行它，则需要5秒钟，并且显示的读取数少于4600次

查询使用了几个参数，这些参数的值在SQL文本的末尾提供，我读过一些关于参数嗅探和低效查询计划的内容，但我认为这与存储过程有关。也许NHibernate在实例化其实体时保持结果集打开，这可以解释较长的持续时间，但对于NHibernate执行的相同查询，有什么可以解释额外的494000次“读取”？（SQL探查器跟踪中不显示其他查询。）

使用NHibernate 3.1的LINQ功能将查询指定为LINQ查询。我没有包括这个问题本身，因为它似乎是哲学的一个基本问题：什么能解释如此巨大的差异

如果相关的话，结果中也碰巧有一个varbinary（max）列，但在我们的情况下，它总是包含null

任何洞察都将不胜感激

请务必阅读：

同样的规则适用于procs和sp_executesql。劣质计划的一个重要原因是为

varchar

字段传递

nvarchar

参数，它会导致索引扫描而不是搜索

我非常怀疑输出是否会影响这里的性能，这可能是由于发送的某个参数或基础表的选择性造成的

测试分析器的输出时，请确保包含

sp_executesql

，并确保设置匹配（如

SET ARITHABORT

），否则将生成新计划

---

您总是可以通过

sys.dm\u exec\u query\u stats

从执行缓存中挖掘出劣质的计划。参数嗅探也适用于临时参数化查询，而不仅仅是存储过程。这些计划根据第一组参数进行编译，并在后续调用中使用可能不同的参数值进行重用。您有没有发现这个问题？我遇到了同样的问题，我所有的参数都是INT，所以我不认为这是一个问题。同样的问题适用于INT vs BIGINT吗？@Phill不，在这种情况下，SQL似乎很乐意使用正确的索引好吧，酷，我们有一个原始开发人员认为很重要的遗留数据库。（数据库已有10年历史）所有新表都是INT，但外键引用为BIGINT。你让我一时担心它会导致性能问题@Phill我不认为你会遇到性能问题，但是那种设计感觉有些不对劲。是的，使用BIGINT。。。在只有不到100条记录的表上。。。我们正在慢慢地清理它。这些都是8年多前做出的设计决策。但是现在数据库>500gb，试图减少使用BIGINT之类的东西，而使用TINYINT会更好。