根据性能比较Linq to SQL和存储过程

我正在使用SQL Server 2005数据库，并且我的应用程序位于ASP.NET MVC4中。应用程序的业务逻辑有点复杂，包含多个表连接和搜索条件。在极端条件下，我需要加入大约10个表格来获取单个网格所需的数据。我想知道我是否应该使用SP或Linq到SQL应用程序代码来最大化我的应用程序性能。根据性能比较Linq to SQL和存储过程

来源

2014-11-04 user3206213

您通常会在存储过程中发现更快的性能，因为存储过程将尽可能重新使用执行计划。 Linq查询基本上成为针对数据库的即席查询，每次都将未缓存作为新请求处理。

来源

2014-11-04 04:51:28

任何适当的设计和参数化“即席” SQL查询将使用**完全相同的重用执行计划 - 使用存储过程绝对**没有性能优势**！（这是一个非常长久的神话 - 但它只是一个神话，它不是真实的！）而不是：存储过程***不是***预编译 - 他们经历了**完全相同的过程任何即时查询当第一次执行..... – 2014-11-04 05:52:37

如果您假设缓存命中率是相同的，这完全正确，这取决于您的服务器如何针对临时工作负载进行优化（默认情况下）。 – 2014-11-04 06:02:40

另外，通过拥有大量独立的Linq查询，您可以轻松地生成大量一次性执行计划，这些计划会再次浪费缓存中的空间，除非您的服务器针对临时工作负载进行了优化。 – 2014-11-04 06:10:28

SQL服务器基本上会经过以下步骤执行任何查询（存储过程调用或即席SQL语句）：如果这没关系

语法检查查询
- 它会检查计划缓存以查看它是否已经有针对该查询的执行计划
如果存在执行计划 - 该计划被（重新）使用并且执行查询
如果还没有计划，则确定执行计划
该计划被存储到计划缓存以备后用
执行查询

的一点是：即席SQL和存储过程处理无异。

如果一个特设的SQL查询是否已正确使用参数 - 因为它应该无论如何，以防止SQL注入攻击 - 其性能特点是没有什么不同和最肯定不超过执行一个存储过程更糟。

存储过程有其他的好处（无需授予用户直接访问表，例如），但在性能方面，采用适当的参数化即席SQL查询是一样高效如使用存储过程。

更新：使用存储过程过非参数化查询是更好的原因主要有两个：

，因为每一个非参数化查询是新的，不同的查询到SQL Server，它必须经历确定每个查询的执行计划的所有步骤（从而浪费时间 - 并且浪费计划缓存空间，因为将执行计划存储到计划缓存中并不真的有助于最终，因为该特定查询可能会而不是来
非参数化查询是在SQL注入攻击的风险，应不惜一切代价避免再次执行）

来源

2014-11-04 05:56:22

+1的伟大的总结。如果您预计许多具有不同参数的linq查询，并且您拥有SQL2k8或更高版本，请考虑针对特定工作负载优化您的服务器（http://msdn.microsoft.com/zh-cn/library/cc645587.aspx）。 – 2014-11-04 06:13:30

您忘记了1和2之间的参数嗅探步骤。另请注意，即席查询必须完全相同，包括参数名称和大小，才能在缓存中找到。 varchar参数上的'.AddWithValue'将大量使用缓存。 – adrianm 2014-11-04 07:01:32

@adrianm：是的，好点 - 完全同意，临时查询必须完全一样 - 到每个空格和逗号和分号 - 不只是“相似”.... – 2014-11-04 07:20:39

根据性能比较Linq to SQL和存储过程

回答

相关问题