存储过程争执 [重复]答案

【问题标题】：The Stored Procedures Feud [duplicate]存储过程争执 [重复]
【发布时间】：2011-06-10 16:13:55
【问题描述】：

可能重复：
What are the pros and cons to keeping SQL in Stored Procs versus Code

我在听Hanselminutes podcast "Rise of The Micro ORM,"，其中一位嘉宾（Sam Saffron 和 Rob Conery）概述了 DBA 坚持使用存储过程的经典原因：

它们是预编译的，这使它们具有执行速度优势
它们隐藏了底层数据库方案，从而允许将接口和实现分离，从而防止脆弱性。

然后一位嘉宾说这些不是很好的论据，并提出 DBA 坚持使用存储过程的真正原因是因为他们只是想保护自己免受中间层开发人员的无知。

我发现这种说法有点极端。当然，我同意论点 #2 是有缺陷的，但我认为众所周知，向数据库发送任意（未编译的）SQL 会对性能造成影响。有什么我遗漏的东西可以解释为什么论点 #1 不是真的吗？

我自己的回答，只是一个猜测，是性能受到影响 - 但这并不重要。这可能类似于一个尝试优化他编写的每个循环的开发人员，尽管只有 1% 的编写的循环曾经从调整中受益。我是否正确地捕捉到了这个想法？

【问题讨论】：

标签： c# database performance stored-procedures orm

【解决方案1】：

“但我认为众所周知，向数据库发送任意（未编译的）SQL 会影响性能。”

您在存储过程和其他关于预编译的 sql 语句之间所做的区别自 SQL 6.5 以来就不存在了。

存储过程和执行计划

在 SQL Server 6.5 及更早版本中，存储过程是一种方法部分预编译执行计划。当时的存储过程已创建，部分编译执行计划存储在系统中桌子。执行存储过程比执行一个更有效 SQL 语句，因为 SQL Server 做了不必编译执行计划完全，它只需要完成优化存储的计划程序。此外，完全编译存储的执行计划过程被保留在 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 语句的执行计划在过程缓存中，不仅仅是存储过程执行计划。这数据库引擎使用高效的比较新的算法 Transact-SQL 语句与现有的 Transact-SQL 语句执行计划。如果数据库引擎确定一个新的 Transact-SQL 语句匹配现有的 Transact-SQL 语句执行计划，它重用该计划。这会降低相对性能预编译存储的好处通过扩展执行计划的程序重用所有 SQL 语句。

http://msdn.microsoft.com/en-us/library/aa174792%28v=sql.80%29.aspx

【讨论】：

是的，这个。过去是真的，即席查询没有预编译或以其他方式优化。这种争论很久以前就消失了。我的愤世嫉俗的观点是，DBA 只是不想将任何控制权或工作保障让给应用程序开发人员。

【解决方案2】：

根据我的经验，大多数 DBA 无法再编写存储过程，然后他们就可以驾驶航天飞机了。在我工作过的所有地方，存储过程都是由应用程序开发人员编写的，他们还设计和实现了数据库。

话虽如此，存储过程并不是天生就比使用视图快，如果由没有经验的开发人员使用游标之类的东西编写，可能确实会更慢。

【讨论】：

【解决方案3】：

至于性能：使用存储过程或预编译语句。

至于抽象：使用 DAL/ORM 或存储过程。

当然，存储过程可以执行您在外部无法执行的操作，并且具有这种性能。所以像往常一样，这取决于..

【讨论】：