为什么Entity Framework生成缓慢过度编程的SQL？

Question

我有这个代码:

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

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

最后一行输出生成的SQL.这是我得到的:

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

你看,有SELECT-from- SELECT虽然它完全是多余的-一个SELECT是刚刚够.使用EF的代码运行时间超过半分钟,并且该查询超时,尽管表格相当小.

为什么会生成这种过度设计的SQL查询,如何使EF生成更好的查询？

Answer 1

它通过转换表达式树来生成结果SQL.它似乎过度设计(例如,使用子查询)作为转换完成方式的副作用.转换的细节是专有的和复杂的,结果不应该是人类可读的.

问题并不完全清楚 - 你正试图解决一个我认为可能不是问题的问题.尝试比较生成的查询和您自己的查询 - 我猜想查询优化器将做出如此简单的优化的简短工作.

我的猜测(这可能是你可以得到的最好的答案,除非LINQ to Entities MS dev出现)是他们正在做的那样:产生最有效的查询,但留下令人头疼的困难工作将查询优化到他们已经将数百或数千个工作日放入的位:SQL Server中的查询优化器.