存储过程之争

Question

可能是重复问题:
将SQL保留在存储过程中与代码相比，有哪些利弊？

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

1. 它们是预编译的，这使它们具有执行速度优势
2. 它们隐藏了底层数据库模式，允许界面和实现的分离，从而防止脆弱性。

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

我认为这个说法有些极端。当然我可以同意论点#2是有缺陷的，但是我认为众所周知向数据库发送任意（未编译）SQL会影响性能。是否有什么我不知道的东西可以解释为什么论点#1并不真实？我的猜测是虽然存在性能问题，但它很少有影响。这或许类似于一个开发者试图优化他写的每个循环，即使只有1%的循环受益于调整。我表达了这个想法吗？

- Brent Arias

Answer 1

"但我认为发送任意（未编译的）SQL到数据库会影响性能是众所周知的。" 你所提到的存储过程和其他SQL语句在预编译方面的区别自SQL 6.5以来已不存在。

“存储过程和执行计划” 在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

- heisenberg

---

没错，以前的确是这样。即兴查询没有预编译或优化。但这个论点早已不成立了。我持怀疑态度的看法是，数据库管理员只是不想将任何控制权或工作保障交给应用程序开发人员。 - Yuck

Answer 2

根据我的经验，大多数数据库管理员不会写存储过程，就像他们不能驾驶航天飞机一样。在我工作的每个地方，存储过程都是由应用程序开发人员编写的，他们还设计和实现了数据库。

话虽如此，存储过程并不比使用视图本质上更快，如果由经验不足的开发人员使用诸如游标之类的东西编写，则可能更慢。

- user2100815

Answer 3

关于性能：要么使用存储过程，要么使用预编译语句。

关于抽象化：要么使用DAL/ORM，要么使用存储过程。

当然，存储过程可以做一些从外部无法完成的事情，并且具有更好的性能。所以像往常一样，这取决于具体情况。

- codymanix