.NET面试题系列目录

当你使用LINQ to SQL时，请使用工具(比如LINQPad)查看系统生成的SQL语句，这会帮你发现问题可能发生在何处。

当我们仅需要一个资料的时候，我们可以考虑使用First / FirstOrDefault / Take / Any等方法，它们都会在取得合乎要求的资料后退出，而不会遍历整个序列（除非最后一个资料才是合乎要求的哈哈）。而类似ToList / Max / Last / Sum / Contain等方法显而易见会遍历整个序列。

例如你判断一个集合是否有成员时，请使用Any而不是Count==0。因为如果该集合有极多成员时，Count遍历是非常消耗时间的。

如果你在重复枚举同一个序列，你可能会收到如下的警告：

一般看到这个提示，你需要一个ToList/ToDictionary/ToArray等类似的方法。重复枚举是不必要且浪费时间的。另外，如果程序涉及多线程，或者你的序列含有随机因素，你的每次枚举的结果可能不同。我们只需要枚举同一序列一次，之后将结果储存为一个泛型集合即可。

例如我们的序列带有随机数：

此时我们会遍历序列四次。但每次序列都会不同。例如如果我们呼叫Sum方法四次，则可能会出现4个不同的和。我们必须使用ToList方法强制LINQ提前执行。

在获得序列最后一个成员时，我们有很多方法：

其中前两个方法都不是最好的。当我们调用LINQ的某些方法时，我们缓存了整个序列，而这可能是不必要的。我们根本不需要将整个序列留在内存中，只需要获得最后一个成员就可以了。

根据前面两点，我们可以总结出来何时使用ToList / ToArray / ToDictionary等方法：

• 你确定你需要整个序列的时候
• 你确定你会遍历整个序列多于一次的时候
• 如果序列不是很大的时候（因为ToList / ToArray / ToDictionary等方法将会在堆上分配一个序列对象）

是否返回IEnumerable<T>，或者返回一个List，或者数组？注意当你返回IEnumerable<T>时，你并没有开始遍历这个序列（只有当你强制LINQ执行时，才会执行这个返回IEnumerable<T>的方法）。当然如果数据来自远端，你还可以选择IQueryable<T>，它不会把资料一股脑拉下来，而是做完所有的筛选之后，才ToList，把资料从远端下载下来。所以在使用ORM时，如果它用到了IQueryable，请将你的查询也写成表达式而不是委托的形式。参考：http://www.cnblogs.com/SieAppler/p/3501475.html

另外，我们可以通过返回IEnumerable<T>而不是List或数组，来给予呼叫者最大的便利。（给他一个最General类型的返回）

假设你有一个父表（例如：汽车），其关联一个子表，例如*（一对多）。现在你想对于所有的父表汽车，遍历所有汽车，然后打印出来所有*的信息。默认的做法将是：

SELECT CarId FROM Cars;

然后对于每个汽车：

SELECT * FROM Wheel WHERE CarId = ?

这会SELECT 2个表一共N（子表的行数）+1（父表）次，故称为SELECT N+1问题。

考察下面的代码。假设album是一个表，artist是另外一个表，album和artist是一对多的关系：

我们知道foreach会强制LINQ执行，于是，我们可以想象这也是一个SELECT N+1问题的例子：先获得所有album（SELECT * FROM ALBUM），然后遍历，对每一个album的Title，检查其是否包含关键字，如果符合，再去SELECT 表artist，共SELECT N+1次。我们可以通过LINQPAD或其他方式检查编译器生成的SELECT语句数目，一定会是N+1条SQL语句。

解决方法：使用一个匿名对象作为中间表格，预先将两个表join到一起：

生成的SQL将只有一句话！

这篇文章中的第三点，就是一个典型的SELECT N+1问题。在代码中，选择了前100个score（一条SQL），然后对所有score进行遍历，从表Student中获得Name的值（100条SQL）。

解决方法也在文章中给出了，就是将两个表连到一起。该文章的“联表查询统计”这一节，说的还是这个问题。简单说，还是每次都用LINQPad工具，看看最终生成的SQL到底长啥样。（当然还有很多其他工具，或者最基本的就是用SQL Profiler不过比较麻烦）

提升从数据库中拿数据的速度，可以参考以下几种方法：

1. 在数据库中的表中定义合适的索引和键
2. 只获得你需要的列（使用ViewModel或者改进你的查询）和行（使用IQueryable<T>）
3. 尽可能使用一条查询而不是多条
4. 只为了展示数据，而不进行后续修改时，可以使用AsNoTracking。它不会影响生成的SQL，但它可以令系统少维护很多数据，从而提高性能
5. 使用Reshaper等工具，它可能会在你写出较差的代码时给出提醒

我们可以通过很多工具来获得系统产生的SQL语句，例如LINQPAD或者SQL Profiler。在EF6中，我们还可以使用这样的方法：

注意：编译器不一定能够将你的LINQ语句翻译为SQL，例如字符串的IndexOf方法就不被支持。

LinqOptimizer可以通过nuget获得。你可以通过在IEnumerable<T>上调用AsQueryExpr方法来令LinqOptimizer优化你的LINQ语句。使用Run方法执行：

在没有找到性能瓶颈之前，不要过早优化。

1. 是否存在需要长时间运行的LINQ语句？
2. 是否在数据库上取得数据，并运行LINQ语句？（这意味着存在一个LINQ语句到SQL的表达式转换）
3. 数据规模是否巨大？
4. 是否需要重复极其多次运行相同的LINQ语句？

在什么情况下，LINQ反而不如Foreach表现好？两者的性能差距是怎样的？下面的例子的序列有一千万个成员，我们对它们做些简单运算。

结果：

可以看到Foreach的表现稍好一点。LINQ的额外开销在于将lambda表达式转换为委托的形式，而foreach不需要。虽然这一点点额外开销对于普通的情况基本可以忽略，但如果重复一千万次，则性能可能会有较为明显的差异。

显而易见，如果我们重复运行相同的任务，且任务之间又没有什么关系（不需要对结果进行汇总），此时我们可以想到用多线程来解决问题，重复利用系统的资源：

执行后只用了423毫秒。通常来说，执行的结果将等于Foreach的时间，除以系统CPU的核数量。当CPU为双核时，速度大概可以提升一倍。当然，对于单核机器来说，PLINQ是没有意义的。

当你的机器拥有多核，并且你处理相同的任务时（例如从不同的网站下载内容，并做相同的处理），可以考虑使用PLINQ。不过PLINQ也需要一些额外开销：它访问线程池，新建线程，将任务分配到各个线程中，然后还要收集任务的结果。所以，你需要测量PLINQ是否真的可以加快你的代码的运行速度。

通常，只有在如下情况下才会考虑将自己写的ORM投入生产使用：

• 存在一些特定的复杂查询，在项目中广泛出现，此时自己写的ORM做了很多优化，表现好于EF
• 存在一些特定的业务逻辑，例如将表达式解析为XML等，EF没有对应的功能
• 你的项目对性能要求达到了非常苛刻的程度，导致EF的一些性能可以接受的方法在你这里变成了不能接受。例如EF使用了反射，但如果你的ORM只用于你开发的软件，所有的情况你都可以事先预计，那你也可以不用反射

而大部分ORM开发出来的目标仅仅是：

• 令查询语法更加接近SQL
• 加入了若干语法糖或代码生成快捷方式，令编写代码速度稍微加快
• 性能和EF相差无几，有些甚至还不如EF
• 没有经过彻底的测试
• 自学使用

通常，自己开发一套ORM需要很长的时间，才能保证没有错误，并用于生产环境。大部分情况下，EF已经是一个不错的选择。性能是双刃剑，它可能也会毁了你的代码，让你的代码难以维护。

• 使用LINQPad等工具观察生成的SQL。当你优化之后，再次在LINQPad上运行看看是否造成了可观的性能提升。
• 是否需要在数据库上筛选数据，并运行LINQ语句？如果是的话，考虑返回IQueryable<T>，并考察编译器构建的中间SQL语句。
• 数据规模是否巨大？避免过早的ToList，返回IEnumerable/ IQueryable<T>类型的巨大规模的数据。
• 是否需要重复极其多次运行相同的LINQ语句？考虑使用foreach或者PLINQ来优化性能。
• 使用LinqOptimizer来优化LINQ语句。
• 使用Reshaper等工具，它可能会在你写出较差的代码时给出提醒。
• 上MSDN，nuget查询是否已经有了现成的方法（例如获得最后一个元素）。
• 撰写单元测试来保证你的优化的正确性。