【问题标题】:Mysql stored procedure slow for delete statement删除语句的Mysql存储过程慢
【发布时间】:2013-05-16 20:18:27
【问题描述】:

我有一个奇怪的 mysql 查询速度问题,我正试图解决这个问题。我正在将一个 mysql 数据库从一台服务器移动到另一台服务器,而一台本应更强大的服务器运行某些 mysql 查询的速度几乎是原始服务器的 4 倍。经过几天的调试,我终于发现速度存在巨大差异,具体取决于存储过程中 where 子句中变量的使用方式。以下是一些示例:

快速:

set @s = Concat('delete from visitids where VisitID=''',xVisitID,''' and OrgCode=''',xOrgCode,'''');
PREPARE stmt FROM @s;
EXECUTE stmt;

慢:

delete from visitids where VisitID=xVisitID and OrgCode=xOrgCode;

慢:

set @s = Concat('delete from visitids where VisitID=xVisitID and OrgCode=xOrgCode');
    PREPARE stmt FROM @s;
    EXECUTE stmt;

第一个示例比接下来的 2 个示例快约 5 倍。另一个奇怪的事情是它取决于服务器和可能的 mysql 版本。在一台服务器上,变量在 where 子句中的使用方式并不重要,但在另一台服务器上却如此。我错过了什么吗?为什么在 where 子句中带有变量的直接 sql 语句比使用从字符串构建并准备/执行的 sql 查询的语句慢得多?

【问题讨论】:

  • 第三个例子根本行不通,因为xVisitIDxOrgCode变量不会存在于语句执行的范围内;也许您打算将它们显示为参数化?无论如何,所有服务器上是否存在所有相同的索引?
  • 最后一个例子应该被改写为 set @s = Concat('delete from visitids where VisitID=@xVisitID and OrgCode=@xOrgCode');声明和设置这些变量。数据和索引完全相同。当我对一台服务器进行 mysqldump 并将其导入另一台服务器时,我看到了这一点。

标签: mysql stored-procedures


【解决方案1】:

我遇到了同样的问题。在sp中,删除很慢。直接运行delete语句时,delete语句很快。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-08-26
    • 1970-01-01
    • 1970-01-01
    • 2011-08-19
    • 1970-01-01
    相关资源
    最近更新 更多