Почему LINQ to Entities делает подзапрос для меня?

Question

Я использую .NET 4 и Entity Framework для создания простого запроса. Вот C# код:

return Context.Files.Where(f => f.FileHash != 40) 
        .OrderByDescending(f => f.Created) 
        .Take(5); 

Когда я проследить запрос с использованием ObjectQuery.ToTraceString(), я найти следующий подзапрос:

SELECT TOP (5) 
    [Project1].[ID] AS [ID], 
    -- <snip> lots of columns 
    [Project1].[FileHash] AS [FileHash] 
FROM (SELECT 
     [Extent1].[ID] AS [ID], 
     -- <snip> lots of columns 
     [Extent1].[FileHash] AS [FileHash] 
     FROM [dbo].[Files] AS [Extent1] 
     WHERE (LEN([Extent1].[FileHash])) <> 40 
) AS [Project1] 
ORDER BY [Project1].[Created] DESC 

FileHash определяется как NVARCHAR (255).

Это кажется странным для меня, поскольку я не вижу необходимости в подзапросе. Почему EF делает это для меня, и есть ли что-то, что я могу сделать, чтобы не взять то, что я предполагаю, - это удар производительности из такого запроса?

Answer 1

Прежде всего, я сомневаюсь, что это стоит беспокоиться. Я предполагаю, что если вы сравните план выполнения запроса с тем, что генерирует EF для «оптимального» ручного запроса, результаты будут фактически одинаковыми. Я предполагаю, что единственным вероятным штрафом является то, что сгенерированный запрос EF занимает дольше секунды для синтаксического анализа. В великой схеме вещей это, вероятно, не стоит рассматривать.

Что касается того, почему EF генерирует запрос таким образом, в первую очередь, я уверен, что он связан с присущей сложностью перевода методов LINQ в действительные SQL-запросы. Я уверен, что движок, который выполняет этот перевод, очень модульный, и каждый модуль должен генерировать часть запроса, которая может быть легко включена в окончательный, полный запрос. Хотя, конечно, можно было бы запустить окончательный «оптимизационный» проход для устранения избыточности, вероятно, очень мало вреда для делегирования этой задачи самому SQL Server.