【问题标题】:Stored procedures for complex queries复杂查询的存储过程
【发布时间】:2010-11-19 17:14:13
【问题描述】:

我有一些经常运行的复杂查询。 缓存结果是不可能的,因为它们大部分时间都在更新,而查看更新的数据就是重点。

我不允许更改数据库设置,除非地狱首先冻结,否则那些被允许更改的人不会这样做,所以我必须尽我所能优化查询和表。

因为我认为我已经为这些查询和它们使用的表做了所有我能做的事情,所以我想如果我为它们创建存储过程是否会提高速度。

它会提高速度,还是我应该寻找其他东西?

【问题讨论】:

  • 设置视图怎么样...
  • 我想了几次,但我记得在某处读过 mysql 没有编译用于视图的查询,所以它所能完成的就是让代码看起来更好,所以我没有不打扰意见。还是我的信息有误?

标签: mysql performance


【解决方案1】:

不,使用存储过程不会提高“硬”查询的性能。

大多数硬查询是由于数据库需要做大量工作才能找到答案。如果它在存储过程中,这不会有任何不同。

更改数据库设置可能会影响某些事情,但优化查询的最佳方法通常是更改数据结构,以便您需要查询更少的行或更少的列。或者,您可以让它使用更好的索引或其他改进查询的方法。

使用解释。使用非生产系统进行性能测试。不要费心将您的查询放入一个过程中(如果性能是您想要这样做的唯一原因)。

【讨论】:

  • 所有我已经在做的事情,我在性能上得到了巨大的提升。然后随着表格的不断增长,事情再次放慢了速度。
  • 您是否认为出于性能目的对数据库进行非规范化也是合理的?这通常可以降低查询的复杂性,尽管它可能会增加插入/更新数据所需的时间。但似乎这些成本可以摊销,因为 INSERT 和 UPDATE 通常在较长时间内以较小的块执行。
  • 已经做了一些非规范化。它大大减少了我一些最慢查询所花费的时间。或者也许我设计的表格很糟糕,这并不会让我感到惊讶,因为我从来没有使用过会达到数十万行并且需要与其他表格进行连接的表格。
  • +1 表示“使用解释”。一旦某个表达到特定(大量)行数,我们曾经在客户端上运行 小时 的查询。原来,子查询中的连接导致对一个非常小的表(数十万次,因为它在子查询中。我们展开子查询和运行时间从 20 小时缩短到
【解决方案2】:

参考以下链接

MySQL Stored Procedure vs. complex query

它会给你带来小的性能提升。

【讨论】:

  • 我希望我早点发现这个问题。无论如何,它回答了我是否应该使用 SP 的问题,似乎答案是否定的,因为性能增益将非常小。
【解决方案3】:

是的。使用存储过程将提高性能。由于SP是编译存储在数据库服务器中的。

但这也取决于表和查询的结构!

如果您的数据库结构较差且查询未优化,则随着数据的增长,性能将会降低。

【讨论】:

猜你喜欢
  • 2010-11-12
  • 2011-12-11
  • 1970-01-01
  • 2014-04-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多