mar*_*zzz 21 sql sql-server stored-procedures
事实上,如果我从我的应用程序调用存储过程,我需要连接到我的数据库.
那么,为什么调用"存储过程"应该比"传递SQL查询"字符串更快？
mar*_*c_s 57
SQL Server基本上通过这些步骤来执行任何查询(存储过程调用或ad-hoc SQL语句):
1)语法检查查询
2)是否可以 - 它检查计划缓存以查看它是否已经有该查询的执行计划
3)是否有执行计划 - 该计划被(重新)使用并且执行查询
4)如果还没有计划,则确定执行计划
5)将计划存储到计划缓存中以供以后重用
6)执行查询
关键是:ad-hoc SQL和存储过程没有区别.
如果ad-hoc SQL查询正确使用参数 - 无论如何应该防止SQL注入攻击 - 它的性能特征没有什么不同,并且绝对不会比执行存储过程更糟糕.
存储过程具有其他好处(例如,无需授予用户直接表访问权限),但就性能而言,使用正确参数化的即席SQL查询与使用存储过程一样高效.
更新:使用存储过程比非参数化查询更好,主要有两个原因:
由于每个非参数化查询都是对SQL Server的一个新的不同查询,因此必须对每个查询执行确定执行计划的所有步骤(从而浪费时间 - 并且还浪费计划缓存空间,因为存储执行计划进入计划缓存最终并没有真正帮助,因为那个特定的查询可能不会再次执行)
非参数化查询存在SQL注入攻击的风险,应该不惜一切代价避免
因为每次将查询字符串传递给SQL Server时,代码都必须编译等,存储过程已经编译好并准备在服务器上运行.
此外,您通过网络发送的数据较少,尽管这通常影响很小.
编辑:作为附注,存储过程有其他好处.
1)安全性 - 由于实际查询存储在服务器上,因此您不通过网络传输此信息,这意味着任何拦截您的网络流量的人都无法深入了解您的表结构.此外,精心设计的SP可以防止注射攻击.
2)代码分离,您将数据库代码保存在数据库中,将应用程序代码保存在应用程序中,几乎没有交叉,我发现这使得bug修复得更好.
3)可维护性和代码重用,您可以多次重复使用过程而无需复制粘贴查询,如果您希望更新查询,则只需在一个位置更新它.
4)减少网络流量.如上所述,对于大多数人来说这可能不是问题,但是对于大型应用程序,您可以通过切换到使用存储过程来显着减少通过网络传输的数据量.