由于LINQ to SQL基本上是ADO.NET之上的一层，因此需要进行一些翻译。这是否意味着直接使用ADO.NET比LINQ更快？或者差异是如此之小以至于无关紧要？
答案 0 :(得分：26)
这确实意味着ADO.NET更快。它还为您提供了更多自由来优化您的SQL查询（从技术上讲，您可以仅使用LINQ to SQL和存储过程，但是您可能会错过任何一点）。
事实是，如果你真的真的需要优化以获得最佳性能，那么没有人真正建议使用OR / M. OR / M：s有很多考虑因素，性能方面。但是很多网站并不真正需要优化 来提高性能，这与我们在.NET而不是汇编程序中提供编程的方式非常相似，即使这与开销相同。与用较低级别的语言编写代码相比。
使用LINQ to SQL或NHibernate，或者实际上任何其他OR / M是这样的（与.NET类比一样）它会给你带来很多便利，它会为你节省很多时间开发，并使重构和其他后来的更改变得更加简单。
答案 1 :(得分：5)
在执行中它的速度稍慢。但是，Linq to SQL节省了开发人员的时间，这是它的主要好处，恕我直言。
善，
丹
答案 2 :(得分：4)
从技术上讲，是的，有一些开销，Linq2Sql有时会产生一些不那么优秀的SQL，但除非你正在进行高性能或高吞吐量的工作，否则你可能不会注意到它。
我的建议是选择最符合您要求的DA技术并配合使用。记住像Linq2SQL或EF这样的东西的优点是减少了编写重复DA层所花费的开发人员时间，并减少了代码（因此理论上可能减少错误和减少维护 - 尽管这是有争议的）。然后对性能进行分析，如果检测到瓶颈，则可以开始优化特定查询，如果绝对必要，可以将导致大瓶颈的非常重要的查询转换为普通的ado.net
答案 3 :(得分：2)
LINQ to SQL确实是ADO.NET之上的一层。但是其他选项也允许您将结果保存在内存中。如果您的意图是在检索后立即对数据进行操作，最好在循环中使用ADO.NET DataReader以获得更好的性能。但是，如果需要对数据进行进一步处理，则需要使用某种变量（例如LINQ to SQL Entity或DataTable）保存内存。这两个内存变量基本上都是以相同的方式生成的。鉴于这一事实，我会说每个选项在内存中的可用速度并不像您计划使用数据那样重要。