LINQ和存储过程之间的性能差异

Question

相关

  

LINQ-to-SQL vs stored procedures?

我已经听过很多关于预编译存储过程的优点的讨论。但是LINQ和选择，插入，更新，删除的存储过程之间的实际性能差异是什么？有没有人进行任何测试，看看是否有任何重大差异。如果更多的交易产生影响，我也很好奇。

我的猜测是LINQ语句在第一次事务之后被缓存，性能可能几乎相同。想法？

Answer 1

LINQ应该在性能上接近但我不同意上面的陈述，即LINQ更快，它不能更快​​，它可能同样快，但所有其他条件相同。

我认为不同之处在于，一个知道如何优化和使用存储过程的优秀SQL开发人员总是会在性能方面略有优势。如果你对SQL不够强，那么让Linq为你解决这个问题，你的表现很可能是可以接受的。如果您是一名强大的SQL开发人员，请使用存储过程在应用程序需要时挤出一些额外的性能。

如果你编写一个可怕的SQL来编写一些执行速度比Linq慢的存储过程，那当然是可能的，但是如果你知道你在做什么，那么存储过程和一个Datareader是无法击败的。

Answer 2

LINQ查询也可以（也应该）预编译。我没有任何基准可以与您分享，但我认为每个人都应该阅读this article以获取有关如何操作的参考。我特别感兴趣的是看到一些预编译的LINQ查询与SPROCS的比较。

Answer 3

除了LINQ在您拥有大量数据并且需要进行数据库调整时可能会降级时，没有太大区别。

Answer 4

与LINQ查询相比，存储过程更快，它们可以充分利用SQL功能。 当下次执行存储过程时，数据库使用缓存的执行计划来执行该存储过程。 而每次都编译LINQ查询。 因此，与存储过程相比，LINQ查询执行时间更长。

与LINQ相比，存储过程是编写复杂查询的最佳方法。

Answer 5

除了生成器可能无法以最佳方式优化查询的可能性之外，LINQ2SQL查询与任何其他ad-hoc参数化SQL查询的执行方式不同。

Answer 6

常见的看法是ad-hoc sql查询比存储过程执行得更好。但是，这是错误的：

  

SQL Server 2000和SQL Server版本   7.0包含许多对语句处理的更改，这些更改扩展了许多   存储的性能优势   所有SQL语句的过程。 SQL   Server 2000和SQL Server 7.0没有   保存部分编译的计划   它们存储过程   创建。存储过程是   在执行时编译，像任何一样   其他Transact-SQL语句。 SQL   Server 2000和SQL Server 7.0保留   所有SQL语句的执行计划   在过程缓存中，不只是   存储过程执行计划。

     

- SqlServer's Books Online

鉴于上述情况以及LINQ生成即席查询的事实，我的结论是存储过程与存储过程之间没有性能差异。 LINQ。而且我也很容易相信SQL Server在查询性能方面不会倒退。

Answer 7

Linq应该在sql或oracle中创建的视图之上的业务逻辑层使用。 Linq帮助您为业务逻辑插入另一层，维护由编程人员或非sql人员负责。它肯定不会像sql那样表现得好，因为它没有预编译，你可以在sps中执行很多不同的事情。 但是你绝对可以添加一个编程细节，并使用Linq将业务逻辑与核心sql表和数据库对象隔离开来。

Answer 8

请参阅LINQ-to-SQL vs stored procedures寻求帮助 - 我认为该帖子包含大部分信息。你需要。

Answer 9

除非您尝试从应用程序中获得每毫秒，否则使用存储过程或LINQ可能需要由您希望开发人员了解和维护的内容来确定。

存储过程会很快，但是当您正在积极开发应用程序时，您可能会发现使用LINQ很容易，因为您可以更快地更改查询和从LINQ创建的匿名类型。 / p>

一旦你完成了编写应用程序并知道你需要什么，并开始考虑优化它，那么你可以看看其他技术，如果你有好的单元测试，那么你应该能够比较不同的技术并确定哪种解决方案最好。

您可能会发现.NET 3.5与数据库交互的各种方法的比较很有用。 http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html

Answer 10

我认为我不想在编译代码中使用我的数据库层。它应该是一个不合并的单独层。当我开发和利用敏捷时，我不断改变数据库设计，并且过程非常快。在SQL Server中添加列，删除列或创建新表就像在Excel中键入一样简单。规范化表或去规范化在数据库级别也非常快。现在使用Linq，每次我对数据库进行更改时，我都必须更改对象表示，或者使用它不能真正反映数据的存储方式。这是一项额外的工作。

我听说Linq实体可以保护您的应用程序免受数据库更改，但这没有意义。数据库设计和应用程序设计需要齐头并进。如果我对几个表进行规范化或对数据库进行其他重新设计，我不希望Linq对象模型不再反映实际的数据库设计。

那么调整视图或存储过程的优势又如何呢？您可以直接在数据库级别执行此操作，而无需重新编译代码并将其发布到生产环境中。如果我有一个显示来自多个表的数据的视图，并且我决定更改数据库设计，我所要做的就是更改该视图。我的所有代码都保持不变。

Answer 11

<script>alert("hello") </script>我认为在网络服务器（无论是LINQ还是ad-hoc SQL）上执行此操作比让SQL Server在数据库上执行此操作更快或更有效？

对于简单查询，LINQ显然更好，因为它将被预编译，为您提供类型检查等优势。但是，对于任何密集型数据库操作，报表构建，需要执行的批量数据分析，存储程序将赢得胜利

Answer 12

考虑一个包含一百万个条目的数据库表，加入另一个包含一百万个条目的表...你真的认为在网络服务器上做这个（无论是LINQ还是ad-hoc SQL）会更快或者比让SQL Server在数据库中执行它更有效吗？

对于简单查询，LINQ显然更好，因为它将被预编译，为您提供类型检查等优势。但是，对于任何密集型数据库操作，报表构建，需要执行的批量数据分析，存储程序将赢得胜利。