Question

I have this code:

DbSet<TableName> table = ...// stored reference

var items = from n in table where
            n.Name.ToUpper().Contains(searchString.ToUpper().Trim())
            select n;
WriteToLog( items.ToString() );

The last line outputs the generated SQL. Here’s what I get:

SELECT 
    [Extent1].[Name] AS [Name],
    // all the other columns follow
FROM (SELECT 
  [TableName].[Name] AS [Name],
  // all the other columns follow
FROM [dbo].[TableName] AS [TableName]) AS [Extent1]
WHERE ( CAST(CHARINDEX(LTRIM(RTRIM(UPPER(@p__linq__0))), UPPER([Extent1].[Name])) AS int)) > 0

You see, there’s SELECT-from-SELECT although it’s completely redundant – one SELECT would be just enough. The code using EF runs longer than half a minute and time out on that query although the table is rather small.

Why is this overengineered SQL query generated and how do I make EF generate a better query?

Answer 1

It generates the resulting SQL by transforming an expression tree. It appears overengineered (for example, using a subquery) as a side-effect of the way it’s done that transformation.
The details of the transformation are proprietary and complex, and the results are not supposed to be human-readable.

The question is not entirely clear – and you are trying to solve a problem which I believe may not be a problem. Try comparing the generated query and your own – I would guess the query optimiser will make short work of such an easy optimisation.

My guess (and that’s probably the best kind of answer you can get here unless a LINQ to Entities MS dev comes along) is that they’re doing exactly that: generating the most effective query, but leaving the head-hurtingly-difficult job of optimising the query to the bit they’ve already put hundreds or thousands of man-days into: the query optimiser in SQL Server.