存储程序不和

Question

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

我正在收听Hanselminutes的播客"微型ORM的崛起",其中一位嘉宾(Sam Saffron和Rob Conery)概述了DBA坚持存储过程的经典原因:

1. 它们是预编译的,这为它们提供了执行速度优势
2. 它们隐藏了底层数据库方案,允许分离界面和实现,以防止脆弱.

一位客人说这些不是好的论据,并且提出DBA坚持存储过程的真正原因是因为他们只是想保护自己免受中间层开发人员的无知.

我发现这个说法有点偏向极端.当然我可以同意参数#2是有缺陷的,但我认为众所周知,将任意(未编译的)SQL发送到数据库是一个性能损失.有什么我想念的东西可以解释为什么论证#1不是真的吗？

作为一个猜测,我自己的答案是性能受到了影响 - 但它很少发生.它可能类似于开发人员试图优化他写入的每个循环,即使只有1%的循环编写得益于调优.我正确地捕捉了这个想法吗？

Answer 1

"但我认为众所周知,向数据库发送任意(未编译的)SQL是一种性能损失."

自SQL 6.5以来,存储过程与其他有关预编译的sql语句之间的区别并不存在.

存储过程和执行计划

在SQL Server 6.5及更早版本中,存储过程是部分预编译执行计划的一种方法.在创建存储过程时,部分编译的执行计划存储在系统表中.执行存储过程比执行SQL语句更有效,因为SQL Server不必完全编译执行计划,只需完成优化存储的过程计划.此外,存储过程的完全编译的执行计划保留在SQL Server过程高速缓存中,这意味着后续执行存储过程可以使用预编译的执行计划.

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