【发布时间】：2014-11-04 04:45:00
【问题描述】：
我正在使用 SQL Server 2005 数据库并且我的应用程序在 ASP.NET MVC4 中。 应用程序的业务逻辑有点复杂，包含多个表连接和搜索条件。在极端条件下，我需要加入大约 10 个表来获取单个网格所需的数据。 我想知道是否应该使用 SP 或 Linq to SQL 应用程序代码来最大化我的应用程序性能。
【问题讨论】：
标签： c# asp.net sql-server linq
【发布时间】：2014-11-04 04:45:00
【问题描述】：
SQL Server 基本上通过这些步骤来执行任何查询（存储过程调用或即席 SQL 语句）：
- 语法检查查询
- 如果没问题 - 它会检查计划缓存以查看它是否已经有该查询的执行计划
- 如果有执行计划 - 该计划被（重新）使用并执行查询
- 如果还没有计划，则确定执行计划
- 该计划存储在计划缓存中以供以后重用
- 查询已执行
重点是：即席 SQL 和存储过程的处理方式没有区别。
如果 ad-hoc SQL 查询正确使用 参数 - 无论如何都应该使用，以防止 SQL 注入攻击 - 它的性能特征没有什么不同，而且绝对是 不比执行存储过程差。
存储过程还有其他好处（例如，无需授予用户直接表访问权限），但就性能而言，使用适当参数化的即席 SQL 查询与使用存储过程一样高效程序。
更新：在非参数化查询上使用存储过程更好，主要有两个原因：
由于每个非参数化查询都是对 SQL Server 的新的、不同的查询，因此对于每个查询，它都必须经过确定执行计划的所有步骤（因此浪费时间- 并且还浪费计划缓存空间，因为将执行计划存储到计划缓存中最终并没有真正的帮助，因为该特定查询可能不会再次执行）
非参数化查询存在 SQL 注入攻击的风险，应不惜一切代价避免
【讨论】：
-
+1 以获得精彩的总结。如果您预计会有许多具有不同参数的 linq 查询并且您拥有 SQL2k8 或更高版本，请考虑针对临时工作负载优化您的服务器 (msdn.microsoft.com/en-us/library/cc645587.aspx)。
-
您忘记了 1 和 2 之间的参数嗅探步骤。另请注意，即席查询必须完全相同，包括参数名称和大小，才能在缓存中找到。 varchar 参数上的
.AddWithValue将很少使用缓存。 -
@adrianm：是的，好点 - 并且完全同意，临时查询必须完全相同 - 直到每个空格、逗号和分号 - 而不仅仅是“相似”......
您通常会发现存储过程的性能更快，因为存储过程会尽可能重用执行计划。 Linq 查询本质上变成了针对数据库的即席查询，没有缓存的情况下每次都作为新请求进行处理。
【讨论】：
-
任何适当设计和参数化的“ad-hoc”SQL 查询将完全使用相同的执行计划重用 - 绝对没有性能优势 从使用存储过程！ （这是一个长期存在的神话 - 但它只是一个神话，它不是真实的！）不：存储过程 ARE NOT 预编译 - 他们通过 与首次执行时的任何临时查询完全相同过程.....
-
如果您假设缓存命中率相同，则完全正确，这取决于您的服务器如何针对临时工作负载进行优化（默认情况下）。
-
此外，通过拥有大量单独的 Linq 查询，您可以轻松生成大量一次性执行计划，这会再次浪费缓存中的空间，除非您的服务器针对临时工作负载进行了优化。
-
是的，同意，您最终可能会得到很多较小的查询 - 但是任何给定的临时查询的性能统计信息并不比执行相同操作的存储过程差，这是我的主要观点.存储过程对于某些事情非常有用 - 但感知到的性能优势（预编译）只是一个神话......