小编典典

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

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


阅读 180

收藏
2021-04-07

共1个答案

小编典典

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

问题尚不完全清楚-您正在尝试解决一个我认为可能不是问题的问题。尝试将生成的查询与您自己的查询进行比较-我猜想查询优化器将使这种简单的优化工作变得简短。

我的猜测(除非出现LINQ to Entities
MS开发人员,否则这可能是您可以得到的最好的答案)是他们确实在这样做:生成最有效的查询,但是却要将查询优化到他们已经花了数百或数千个工作日的时间:SQL
Server中的查询优化器。

2021-04-07