为什么这个 hql 比使用标准快得多？

Question

我使用 nhibernate 作为 ORM。我的选择之一是令人难以置信的慢。问题是，生成 sql 需要很长时间。我确定不是 sql 查询本身很慢，因为我使用 sql profiler 对查询本身进行了计时。它表明在开始执行 nhibernate 代码和实际发送到数据库的查询之间存在约 15 秒的间隔。生成的 SQL 查询本身与我预期的一样快。

选择代码（在存储库中）如下

public IEnumerable<Document> GetAllDocumentsReadyForDeletion()
{
    return from doc in _session.Query<Document>()
           where doc.StorageType == 'D'
           select doc;
}

我也试过了：

return _session.CreateCriteria<Document>()
        .Add(Restrictions.Eq("StorageType", 'D'))
        .List<Document>();

wich 是等价的（对吗？）。但是，它们的性能大致相同（很慢，比如生成 sql 查询需要 15 秒）

但是，它的执行速度与我希望的一样快，但我不知道为什么：

return _session.CreateQuery(
        "from Document doc where doc.StorageType = 'D'")
        .List<Document>();

我真的很想使用 linq to nhibernate 版本。知道为什么代码执行不同吗？ （如果您需要更多详细信息，请询问！）

编辑1

哦，伙计，我犯了一个愚蠢的错误还是什么..我错误地读取了 sql profiler 中的错误列.. 嗯，前两个的实际执行时间约为 18 秒，第三个约为 0 秒。我正在尝试查找 sql atm 中的差异...

编辑2

这实际上变成了一个完全不同的问题。结果查询几乎完全相同，除了前两个被包装在“exec sp_executesql”中

现在我用查询分析器跟踪了一下，慢查询有一个步骤：

clustered index scan.

快速查询分两步：

Index seek
Bookmark lookup

有类似的经验吗？

Answer 1

它们实际上生成不同的 sql。其中一个使用索引，而一个不使用。这就是为什么。为什么其中一个使用索引而另一个不使用索引是下一个问题的内容。

（简体）生成的 SQL

快速版本：

SELECT Id, Name FROM documents WHERE StorageType = 'D'

慢版本（linq 和条件）（从内存 atm 输入，稍后检查）：

sp_execsql N'SELECT Id, Name FROM documents WHERE StorageType = @p0', N'@p0 nchar(1)', N'D'

请注意，“StorageType”是 varchar(1) 类型。 This 博客文章解释了为什么这很慢

这里的问题是@p0 作为 NCHAR(1)（又名 Unicode 字符）传递，它与非 Unicode 列的索引不匹配。这就是索引扫描。

显然，对该表的索引扫描大约需要 17 秒。

Answer 2

它们是 NHibernate 中获取相同数据的不同路径。他们使用不同的代码构建查询。有关于 NHibernate 的 linq 提供程序的问题的讨论。我最终编写了自己的 LINQ 提供程序，将 LINQ 提供给 NHibernate，它只在第二个示例中创建字符串，然后使用它来获取数据。