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

Question

I'm using nhibernate as ORM. And one of my selections is incredible slow. The thing is, that it takes a long time to generate the sql. I'm sure it's not the sql query itself that's slow, because I timed the query itself with sql profiler. And it showed that there is a ~15 sec gap between starting to execute the nhibernate code, and the query being actually sent to the db. The generated SQL query itself is as fast as I'd expect it to be.

The selection code (in a repository) is as follows

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

I also tried:

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

wich is the equivalent (right?). However, they both perform about the same (slow, like 15 secs to generate the sql query)

This however, performs as fast as I want it to be, and I have no clue why:

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

I really want to use the linq to nhibernate version. Any idea why the code performs differently? (If you need more details, just ask!)

Edit1

Oh man, did I make a stupid mistake or what.. I mistakenly read the wrong column in the sql profiler.. The ehm, actual execution time for the first two are ~18 seconds, the 3rd is ~0 secs. I'm trying to find the differences in sql atm...

Edit2

This is actually becoming a whole different question. The resulting queries are almost exactly the same, except for that the first two are wrapped inside a "exec sp_executesql"

Now I've traced this a bit with query analyser, and the slow query has one step:

clustered index scan.

The fast query has two steps:

Index seek
Bookmark lookup

Any experiences with something like this?

Answer 1

They actually generate different sql. One of wich uses the index, and one of wich doesn't. That's why. Why one of those uses the index and the other doesn't is content for a next question.

(Simplified) Generated SQL

Fast version:

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

Slow version (both linq and criteria)(typing from memory atm, will check later):

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

note that 'StorageType' is of type varchar(1). This blog post explains why this is slow

The problem here is that @p0 is passed as NCHAR(1) (aka a Unicode char) which does not match the index of the column with is non-Unicode. This cases the index scan.

Apparently, an index scan takes about 17 secs on this table.

Answer 2

They are different paths in NHibernate to get the same data. They construct the queries using different code. There are discussions about the problem with NHibernate's linq provider. I ended up writing my own LINQ provider to give me LINQ into NHibernate that just creates the string in the second example then uses that to get the data.