传言1：存储过程要比SQL代码执行效率更高
SQL是一种语言，用来声明在数据库上想要执行的操作（查询，更新或管理等）。数据库引擎得到的均是文本，就像C#源代码要由编译器处理一样，SQL源码也要必须通过某种方式的编译，以便生成一系列的底层数据库操作，这个输出就叫着执行计划。从概念角度考虑，生成执行计划的过程可以看做是程序编译的过程。

所谓的存储过程要比普通SQL有性能提升体现在对执行计划的重用上。换句话说，第一执行存储过程时，数据库将生成执行计划。然后执行代码。下一次执行的时候即可重用前面已经生成的执行计划，因此效率上会有提高。所有的SQL命令都需要执行计划。

这个（错误的）会议声明，数据库仅会重用存储过程的执行计划。不过在SQL Server和Oracle数据库（我们对其它产品也并不十分的了解）中，重要执行计划将会应用到任何SQL语句上。下面是SQL Server2005在线文档中的一段引用。

在SQL Server2005执行任何 SQL语句时，关系引擎首先查看缓存，判断其中是否有当前SQL的执行计划。SQL Server2005将重用任何可行的执行计划，以便减小重新编译SQL语句对性能上的影响。若没有找到现有的执行计划，SQL Server2005才会为当前查询生成新的执行计划。

因此，当前强调存储过程要比简单的SQL代码更高效的争论就没有任何意义了。从性能角度考虑，所有达到数据库的SQL代码都会被同等对待，编译之后，二者性能没有任何差别，这就是结论。

传言2：存储过程可以用来阻挡SQL注入攻击
这个传言和前面有关性能的传言有些相似。存储过程当然可以降低SQL注入发生的可能性，因为存储过程使用强类型参数。因此对于攻击者来说，很难在需要数字的地方传入字符串，反之亦然。

参数化查询也提供了同样的功能，例如，ADO.NET就对创建参数化查询提供了很好的支持，且ADO.NET被广泛应用于.NET平台上的很多数据库中，包括Entity Frameword,NHibernate和其它O/RM中。使用参数构造的SQL语句也可以和存储过程一样阻挡SQL注入攻击。

(本文摘自：Microsoft.NET 企业级应用架构设计)。

[英文原文：We Don’t Need That Documentation ]