LINQ to SQL 与 ADO.NET - 哪个更快？
由于 LINQ to SQL 基本上是 ADO.NET 之上的一层，因此需要进行一些转换。这是否意味着直接使用 ADO.NET 比 LINQ 更快？或者差异太小以至于无关紧要？
Since LINQ to SQL basically is a layer on top of ADO.NET it requires some translation. Does this mean that using ADO.NET directly is faster than LINQ? Or is the difference so small that it is irrelevant?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
从技术上讲，是的，存在一些开销，并且 Linq2Sql 有时会生成一些不太理想的 SQL，但除非您正在进行高性能或高吞吐量工作，否则您可能不太可能注意到它。
我的建议是选择最适合您要求的 DA 技术并采用它。请记住，Linq2SQL 或 EF 之类的优点是减少了开发人员编写重复 DA 层的时间，并减少了代码（因此理论上可能会减少错误并减少维护 - 尽管这是有争议的）。然后稍后分析性能，如果检测到瓶颈，则可以开始优化特定查询，如果绝对必要，导致大瓶颈的非常重要的查询可以转换为普通的 ado.net
Technically, yes there is some overhead, and Linq2Sql can generate some less that optimal SQL sometimes, but unless you are doing high performance or high throughput work you are probably unlikely to notice it.
My advice would be pick the DA technology that suits your requirements the most and go with it. Remember the advantages of things like Linq2SQL or EF is decreased developer time spent writing repetitive DA layers, and reduced code (so in theory perhaps reduced bugs and less maintenance - although that's debatable). Then profile for performance later and if you detect a bottle neck, you can start optimising specific queries then, and if absolutely necessary, very important queries that are causing big bottle necks can be converted to just plain ado.net
确实，LINQ to SQL 是 ADO.NET 之上的一层。但允许您将结果保存在内存中的其他选项也是如此。如果您的目的是在检索后立即对数据进行操作，那么最好在循环中使用 ADO.NET DataReader 以获得更好的性能。但是，如果您需要对数据进行进一步处理，则需要使用某种变量（例如 LINQ to SQL 实体或 DataTable）将其保存在内存中。这两个内存变量基本上都是以相同的方式生成的。鉴于这一事实，我想说每个选项在内存中可用的速度并不像您计划如何处理数据那么重要。
It is true that LINQ to SQL is a layer on top of ADO.NET. But so are other options that allow you to hold the results in memory. If your intent is to act on the data immediately after retrieval you are better off to work with ADO.NET DataReader within a loop for better performance. However, if you need to do further processing on the data you will need to hold in it memory using some sort of variable such as an LINQ to SQL Entity or DataTable. Both of these memory variables are basically generated the same way under the covers. Given this fact, I’d say that the speed of which each option is available in memory is not as import as how you plan on working with the data.
这确实意味着 ADO.NET 更快。它还为您提供了更多的自由来优化 SQL 查询（从技术上讲，您可以仅将 LINQ to SQL 与存储过程结合使用，但您会错过整个要点）。
事实是，如果您真的确实需要优化以获得最佳性能，那么没有人真正建议使用 OR/M。在性能方面，OR/M:s 有很多考虑因素。但是很多站点实际上并不需要为性能进行那么多优化，就像我们可以用 .NET 而不是汇编程序进行编程一样，尽管这与与使用较低级语言编写代码相比。
使用 LINQ to SQL 或 NHibernate 或任何其他 OR/M 的要点在于（与 .NET 类比）它会给您带来很多便利，并且会节省您大量的开发时间，并使重构和其他后续更改变得更加简单。
It does mean that ADO.NET is faster. It also gives you heaps of more freedom to optimize your SQL queries (well technically, you could use LINQ to SQL with stored procedures only, but you'd miss out on the whole point).
The fact is that if you really really really need to optimize for best performance, then nobody really recommends using an OR/M. There are heaps of considerations with OR/M:s, performance-wise. But a lot of sites do not really need to optimize that much for performance, in much the same way that we can afford programming in .NET rather than assembler, even though that is the same kind of overhead as compared to writing code in a lower level language.
The point of using LINQ to SQL or NHibernate, or really any other OR/M is that (as with the .NET analogy) it'll give you a whole lot of convenience, and it'll save you a lot of time developing, and make refactoring and other later changes a much simpler task.
在执行过程中，速度要慢一些。然而，恕我直言，Linq to SQL 节省了开发人员的时间，这是它的主要好处。
In execution it is fractionally slower. However, Linq to SQL saves developer time which is its main benefit, IMHO.