实体框架COUNT正在对所有记录进行SELECT

Question

Profiling my code because it is taking a long time to execute, it is generating a SELECT instead of a COUNT and as there are 20,000 records it is very very slow.

This is the code:

var catViewModel= new CatViewModel();

var catContext = new CatEntities();

var catAccount = catContext.Account.Single(c => c.AccountId == accountId);

catViewModel.NumberOfCats = catAccount.Cats.Count();

It is straightforward stuff, but the code that the profiler is showing is:

exec sp_executesql N'SELECT 
[Extent1].xxxxx AS yyyyy, 
[Extent1].xxxxx AS yyyyy, 
[Extent1].xxxxx AS yyyyy, 
[Extent1].xxxxx AS yyyyy // You get the idea
FROM [dbo].[Cats] AS [Extent1]
WHERE Cats.[AccountId] = @EntityKeyValue1',N'@EntityKeyValue1 int',@EntityKeyValue1=7

I've never seen this behaviour before, any ideas?

Edit: It is fixed if I simply do this instead:

catViewModel.NumberOfRecords = catContext.Cats.Where(c => c.AccountId == accountId).Count();

I'd still like to know why the former didn't work though.

Answer 1

So you have 2 completely separate queries going on here and I think I can explain why you get different results. Let's look at the first one

// pull a single account record
var catAccount = catContext.Account.Single(c => c.AccountId == accountId);
// count all the associated Cat records against said account
catViewModel.NumberOfCats = catAccount.Cats.Count();

Going on the assumption that Cats has a 0..* relationship with Account and assuming you are leveraging the frameworks ability to lazily load foreign tables then your first call to catAccounts.Cats is going to result in a SELECT for all the associated Cat records for that particular account. This results in the table being brought into memory therefore the call to Count() would result in an internal check of the Count property of the in-memory collection (hence no COUNT SQL generated).

The second query

catViewModel.NumberOfRecords = 
    catContext.Cats.Where(c => c.AccountId == accountId).Count();

Is directly against the Cats table (which would be IQueryable<T> ) therefore the only operations performed against the table are Where / Count , and both of these will be evaluated on the DB-side before execution so it's obviously a lot more efficient than the first.

However, if you need both Account and Cats then I would recommend you eager load the data on the fetch, that way you take the hit upfront once

var catAccount = catContext.Account.Include(a => a.Cats).Single(...);

Answer 2

Most times, when somebody accesses a sub-collection of an entity, it is because there are a limited number of records, and it is acceptable to populate the collection . Thus, when you access:

catAccount.Cats

(regardless of what you do next), it is filling that collection . Your .Count() is then operating on the local in-memory collection. The problem is that you don't want that. Now you have two options:

• check whether your provider offer some mechanism to make that a query rather than a collection
• build the query dynamically
• access the core data-model instead

I'm pretty confident that if you did:

catViewModel.NumberOfRecords =
    catContext.Cats.Count(c => c.AccountId == accountId);

it will work just fine. Less convenient? Sure. But "works" is better than "convenient".