使用存储过程是否有重大的性能提升?

时间:2008-11-28 13:49:05

标签: performance stored-procedures

使用存储过程或使用连接字符串以及所有好东西以旧方式执行它是否更好?我们的系统最近运行缓慢,我们的经理希望我们试着看看我们是否可以加快速度,我们正考虑将一些旧的数据库调用更改为存储过程。值得吗?

10 个答案:

答案 0 :(得分:17)

要做的第一件事是检查数据库是否已设置所有必要的索引。分析代码缓慢的位置,并检查与其相关的相关SQL语句和索引。看看是否可以重写SQL语句以提高效率。检查您是否没有为循环中的每次迭代重新编译SQL(准备好的)语句,而不是在其外部重新编译一次。

如果在执行过程中效率非常低,那么将SQL语句移动到存储过程中将无济于事。但是,数据库将知道如何最好地优化SQL,并且不需要重复执行。它还可以通过将复杂的SQL语句转换为简单的过程调用来使客户端代码更清晰。

答案 1 :(得分:9)

我会快速查看Stored Procedures are EVIL

答案 2 :(得分:6)

只要您的调用一致,数据库就会存储执行计划(无论如何都是MS SQL)。使用存储过程的最强剩余原因是为了方便和可靠的安全管理。

如果我是你,我首先要在需要时添加索引。还运行一个分析工具来检查需要更长时间的内容以及是否需要更改sql,例如添加更多Where子句或限制结果集。

您应该尽可能考虑缓存

答案 3 :(得分:5)

存储过程不会让事情变得更快。

然而,重新安排你的逻辑会产生巨大的影响。在考虑存储过程时,您设计的整洁,集中的事务非常有用。

此外,存储过程倾向于使用绑定变量,其他编程语言有时依赖于动态构建SQL语句。一小组固定的SQL语句和绑定变量很快。动态SQL语句很慢。

“最近运行缓慢”的应用程序不需要编码更改。

  1. 措施。测量。测量。在性能调优方面,“慢”并不意味着什么。什么慢?哪个确切的交易很慢?哪个表很慢?焦点。

  2. 控制所有更改。所有。改变了什么? OS补丁? RDBMS改变了吗?申请变更?改变了一些事情以减缓事情的发展。

  3. 检查比例限制。表格是否因为80%的数据是您每年报告一次的历史记录而放缓?

  4. 存储过程永远不是性能问题的解决方案,除非你绝对指向一个特定的代码块,这个代码块作为存储过程可以证明更快。

答案 4 :(得分:4)

如果存储过程避免发送大量数据和/或避免向服务器进行往返,那么存储过程可以提供帮助,因此如果您的应用程序存在其中一个问题,它们就很有价值。

答案 5 :(得分:2)

如果您的服务器在繁忙的季节变得明显变慢,可能是因为饱和而不是数据库中的任何不足之处。基本queuing theory告诉我们,服务器在接近饱和状态时会出现双曲线变慢。

基本关系是1/(1-X),其中X是负载的比例。这描述了服务之前的平均队列长度或等待时间。因此,当负载达到峰值时,饱和的服务器将非常快速地减速。

加载25%的服务器对于某些常量K的平均服务时间为1.333K(松散地,K是机器执行一次事务的时间)。加载50%的服务器的平均服务时间为2K,加载90%的服务器的平均服务时间为10K。 鉴于减速本质上是双曲线的,因此总体负荷通常不会发生很大变化,从而导致响应时间显着下降。

显然这有点过于简单,因为服务器将同时处理多个请求(针对这种情况有更复杂的排队模型),但广泛的原则仍然适用。

因此,如果您的服务器遇到使其饱和的瞬态负载,您将遇到明显减慢的补丁。请注意,这些减速只需要在系统的一个瓶颈区域中,以减缓整个过程。如果您现在只是在繁忙的季节遇到这种情况,那么您的服务器可能只是对资源施加约束,而不是特别慢或效率低。

请注意,这种可能性与代码效率低下的可能性并不对立。您可能会发现缓解瓶颈的方法是调整一些查询。

为了判断系统是否存在瓶颈,请开始收集分析信息。如果你能找到大量等待的资源,这应该会给你一个很好的起点。

最后一种可能性是您需要升级服务器。如果代码中没有严重的低效率(如果分析不表明任何不成比例的大瓶颈可能就是这种情况),您可能只需要更大的硬件。我不知道你的卷是什么,但不要忽视你可能已经超出服务器的可能性。

答案 6 :(得分:2)

完成研究后,你会发现在光谱的另一侧有两个极端的观点。从历史上看,由于hibernate等框架的可用性,Java社区一直反对存储过程,相反,.NET社区已经使用了更多的存储过程,而这种传统就像vb5 / 6天一样。把所有这些信息放在上下文中,远离硬币两边的极端观点。

速度不应该是决定反对或支持存储过程的主要因素。您可以使用带有hibernate和其他框架的内联SQL来实现sp性能。考虑维护以及报告,脚本等其他程序可以使用应用程序使用的相同存储过程。如果您的方案需要多个使用者使用相同的SQL代码,那么存储过程是一个很好的选择,维护将更容易。如果不是这种情况,并且您决定使用内联sql,请考虑在配置文件中将其外部化以便于维护。

最重要的是,什么才能使您的特定情景成为利益相关者的成功。

答案 7 :(得分:0)

是的,存储过程是向实现良好性能迈出的一步。主要原因是可以预编译存储过程并缓存其执行计划。

然而,您需要首先分析您的性能瓶颈究竟在哪里 - 以便您以结构化的方式进行此练习。

正如其中一个回复中所建议的那样,尝试使用分析器工具进行分析,问题是 - 例如,您是否需要创建索引......

干杯

答案 8 :(得分:0)

像上面提到的所有帖子一样,您首先要清理SQL语句,拥有适当的索引。缓存可能很棘手,我不能发表评论,除非我有更多关于你要完成的事情的详细信息。

但关于sprocs的一件事,确保你不要让它生成动态SQL语句

因为对于一个,它将毫无意义,它可能会受到 SQL注入攻击......这发生在我调查的一个项目中。

我主要推荐使用sprocs进行更新,然后选择语句。 祝你好运:)

答案 9 :(得分:-1)

你永远不能提前说。你必须这样做并衡量差异,因为在10个案例中有9个案例,瓶颈不在你想象的地方。

如果使用存储过程,则不必传输数据。 DB在执行[EDIT]复杂[/ EDIT]存储过程[EDIT]时通常很慢,循环,数学等等[/ EDIT]。所以这取决于你需要做多少工作,你的网络有多慢,数据库执行这个特定代码的速度等等。