存储过程Feud

本文关键字：Feud 存储过程 | 更新日期: 2023-09-27 17:58:48

可能重复：
在存储过程中保留SQL与代码的优缺点是什么

我在听Hanselminutes的播客"The Micro ORM的崛起"，其中一位嘉宾（Sam Saffron和Rob Conery）概述了DBA坚持存储过程的经典原因：

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

一位客人接着说，这些都不是很好的论据，并表示DBA坚持使用存储过程的真正原因是他们只是想保护自己免受中间层开发人员的忽视。

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

我自己的答案，只是猜测，是有一个表演上的成功——但这并不重要。这可能类似于开发人员试图优化他编写的每个循环，即使只有1%的编写的循环从调优中受益。我是否正确地捕捉到了这个想法？

存储过程Feud

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

自sql 6.5以来，存储的proc和其他关于预编译的sql语句之间的区别就不存在了。

存储过程和执行计划

在SQL Server 6.5及更早版本中，存储过程是部分预编译执行计划存储过程时已创建，部分编译执行计划存储在系统中桌子执行存储过程比执行SQL语句，因为SQL Server不必编制执行计划完全，它只需要完成优化存储的计划程序此外，完全编译的存储的执行计划过程保留在SQL中服务器过程缓存，这意味着存储的过程可以使用预编译的执行计划。

SQL Server 2000和SQL Server版本7.0包含了对语句处理的一些更改，这些更改扩展了许多存储的性能优势所有SQL语句的过程SQLServer 2000和SQL Server 7.0没有保存部分编译的计划存储过程创建。存储过程是在执行时编译其他Transact-SQL语句SQLServer 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无法再编写存储过程，然后就可以驾驶航天飞机了。无论我在哪里工作，存储过程都是由应用程序开发人员编写的，他们还设计和实现了数据库。

话虽如此，存储的proc并不是天生就比使用视图快，而且如果由缺乏经验的开发人员使用游标之类的东西编写，可能确实会慢一些。

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

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

当然，存储过程可以做一些在外部无法做的事情，并且具有这种性能。所以和往常一样，这取决于。。

相关文章：