在早期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使用了参数@[email protected]，因为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语法的原生支持。以表就是优化前后的对比：
|
约10000元素，执行10次 |
优化前（ms） |
优化后（ms） |
|
第1次 |
163848 |
2589 |
|
第2次 |
155406 |
965 |
|
第3次 |
155255 |
959 |
测试代码如下(已清空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