为什么实体框架会生成缓慢的过度设计的 SQL？

我有这个代码：

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 生成更好的查询？

它通过转换表达式树生成结果 SQL。它似乎是过度设计的（例如，使用子查询），这是它完成转换的方式的副作用。 转换的细节是专有的且复杂的，并且结果不应该是人类可读的。

这个问题并不完全清楚 - 你正在试图解决一个我认为可能不是问题的问题。尝试将生成的查询与您自己的查询进行比较 - 我猜查询优化器将很快完成如此简单的优化。

我的猜测（这可能是您可以在这里得到的最好的答案，除非 LINQ to Entities MS 开发人员出现）是他们正在这样做：生成最有效的查询，但留下了令人头疼的困难工作将查询优化到他们已经投入数百或数千个工日的程度：SQL Server 中的查询优化器。