为什么存储过程比查询快
我想写一个简单的单行查询来从数据库中只select一个值。
所以，如果我为这个查询编写存储过程而不是在c＃代码中编写简单的select查询，那么我相信这个简单的select查询的存储过程会更快，但为什么呢？
我很困惑与存储过程vs写在我的代码简单的查询？ 我很困惑，为什么存储过程比直接写在代码中的简单的查询更快？
存储过程比SQL代码更快
这是一个神话 ，性能总是相当的，从书中： 架构微软.NET企业解决scheme：
SQL是一种语言，通过它可以声明您在数据库上执行的操作（查询，更新或pipe理操作）的意图。 所有的数据库引擎都是文本。 就像编译器处理的C＃源文件一样，必须以某种方式编译SQL源代码，以产生一系列低级别的数据库操作 – 这个输出是以执行计划的名称命名的。 从概念上讲，执行计划的生成可以看作编译程序的数据库对应。
存储过程保证通过普通SQL代码的所谓性能上的提高在于执行计划的重用。 换句话说，第一次执行SP时，DBMS会生成执行计划，然后执行代码。 下一次它将重新使用先前生成的计划，从而更快地执行该命令。 所有的SQL命令都需要执行计划。
（错误的）神话是一个DBMS重用执行计划只为存储过程。 就SQL Server和Oracle DBMS而言，重用执行计划的好处适用于任何SQL语句。 从SQL Server 2005联机文档引用：
在SQL Server 2005中执行任何SQL语句时，关系引擎首先查看过程高速caching，以validation是否存在同一个SQL语句的现有执行计划。 SQL Server 2005重用了它find的任何现有计划，节省了重新编译SQL语句的开销。 如果不存在现有的执行计划，则SQL Server 2005将为该查询生成一个新的执行计划。
围绕SP执行比普通SQL代码更好的争论是毫无意义的。 在性能方面，任何碰到数据库的SQL代码都以相同的方式处理。 性能等同于编译。 期。
这取决于查询，对于简单的查询，它最好是作为查询本身来编写和执行的。 然而，当你在数据库端做更多的处理时（你想用游标中的数据处理数据等等），存储过程在数据库服务器上执行时会更好，并避免不必要的开销，如parsing和额外的通信。
存储过程是预编译和优化的，这意味着查询引擎可以更快地执行它们。 相比之下，代码中的查询必须在运行时进行分析，编译和优化。 这一切都花费时间。
存储过程存储在数据库中的查询。 他们是预编译的。 当您请求数据库执行存储过程（SQL Server）时，SQL Server已经具有存储过程的执行计划。 简单查询需要在运行时创build执行计划。 你需要在这里学习更多
