Linq to EF 中Contains的演变

标签：

    在早期Linq to EF中没有提供对Contains方法的支持， 那时候只能将所有数据获取到内存中，然后通过Linq to Object的Contains方法来达到相同的效果（如果多表筛选也可以使用Any方法实现，也可采用自定义linq的方式实现，但这里我们主要讨论使用数组筛选表的情况）。

    从Linq to EF 4.0 开始加入了对Contains的支持，使用方式如下:

    以上linq最终会被翻译为如下形式的sql语句：

SELECT

[Extent1].[Name] AS [Name]

FROM [dbo].[TbA] AS [Extent1]

WHERE [Extent1].[Name] IN (@p1, @p1, @p1, @p1, @p1)

    这句sql使用了参数@p1~@p5，因为Sql Server中参数不能超过2100个，这导致数组中元素超过2100个后，语句就无法执行。最后又只能回到使用linq to Object的Contains方法。

    在EF 4.1后，EF会将数组中的值直接嵌入到sql语句中，以解决参数过多的问题。生成的sql如下：

SELECT

[Extent1].[Name] AS [Name]

FROM [dbo].[TbA] AS [Extent1]

WHERE [Extent1].[Name] IN (N‘a‘,N‘b‘,N‘c‘,N‘d‘,N‘e‘)

    在EF 6.0之前， Contains方法生成的表达式树结构为多个DbExpression基础类使用OR的形式组合在一起的：

((1 = @p) OR (2 = @p)) OR ((3 = @p) OR (4 = @p))

    当数组中的元素过多后，EF在生成上面的表达式树以及将表达式树转换为sql语句时，消耗了大增时间，可能导致EF在解析树时发生堆栈溢出的错误。在EF 6.0后，微软对EF中Contains方法的性能做出了优化，专门加入了DbInExpression类以提供对In语法的原生支持。以表就是优化前后的对比：

    测试代码如下(已清空TbA表中的数据)：

    最后说一下：在Sql Server中，当in中的元素比较少时，in 语句与使用or拼接查询条件的sql语句是等效的；当in中的元素比较多时，Sql Server会将元素保存到hash表后再做筛选。Sql语句中使用in后，SqlServer会使用全表扫描，但当元素为常量列表并且被筛选列有索引时，SqlServer会使用索引直接查找到结果集。

参考：

https://entityframework.codeplex.com/wikipage?title=Rebuilding%20EF%20providers%20for%20EF6

http://stackoverflow.com/questions/7897630/why-does-the-contains-operator-degrade-entity-frameworks-performance-so-drama/7936350#7936350

Linq to EF 中Contains的演变

标签：

原文地址：http://www.cnblogs.com/aspark/p/4299727.html