MySQL查询直接运行时速度很快，但作为存储过程运行时速度非常慢

我一直在试图找出我所得到的一组查询有什么问题，我只是在这一点上感到困惑

它应该位于GUI应用程序调用的存储过程中

只有一个“小”问题，首先是一个简单的

更新

，然后是一个

插入

，使用带有子选择的

选择

，最后是另一个

更新

。手动同时运行这些查询的总执行时间为0.057秒，不太糟糕

现在，我尝试创建一个包含这些查询和五个输入变量的存储过程，我运行这个过程，第一次运行时花费了47.096秒，随后对它的调用显示了类似的执行时间（35到50秒）。从MySQL工作台运行单个查询仍然显示执行时间小于0.1秒

这些查询真的没有什么特别之处，那么，为什么存储过程要花很长时间才能执行，而查询本身只需要几分之一秒？我在这里遗漏了MySQL的一些特性吗

其他测试结果：

似乎如果我在MySQL Workbench中运行查询，但使用变量，而不是将变量的值放在查询中，那么它的运行速度与存储过程一样慢。因此，我尝试将存储过程更改为只使用静态值而不是变量，但突然之间，它运行得非常快。显然，由于某种原因，使用变量会使其运行非常慢（例如，第一次

更新

查询从使用三个变量的大约0.98秒变为直接在查询中使用变量值时的0.04-0.05秒，而不管它是在存储过程中还是直接运行查询）

---

所以，问题不在于存储过程，而在于我对变量的使用（这是不可避免的）。

请投票回答一个非常有趣和重要的问题。我发现了存储过程可能很慢的一些原因。我很想看看读者对它的反应

---

我从交换中得到的主要建议：它有助于增加更多的索引。

< P>因为我不想浪费太多的时间来弄清楚为什么在我的存储过程中使用变量使它们非常慢，我决定使用一些人认为相当丑陋的修复。我只是直接从应用程序的数据访问层执行每个查询。这不是最漂亮的方法（因为这个应用程序的很多其他东西都使用存储过程），但它可以工作，现在用户不必等待40多秒就可以完成某些操作，因为它们几乎是即时发生的

所以，这并不是一个真正的解决方案或解释所发生的事情，但至少它是有效的。

我也有类似的问题。 运行mysql例程非常慢。 但是一位同事帮了我。 问题是自动提交是真的； 因此，每次插入和选择都会创建一个完整的事务。 然后，我就开始了我的日常工作

SET autocommit=0; 

起初

SET autocommit=1;                    

---

最后。性能从近500秒提高到4秒

我也遇到了同样的问题。经过一段时间的研究，我发现问题在于MySQL在比较文本时的排序问题

TL；DR:该表是在一个排序规则中创建的，而MySQL“认为”该变量在另一个排序规则中。因此，MySQL不能使用用于查询的索引

在我的例子中，表是使用（latin1，latin1\u swedish\u ci）排序规则创建的。为了让MySQL使用索引，我必须将存储过程中的

where

子句从

    UPDATE ... WHERE mycolumn = myvariable

到

更改后，存储过程看起来如下所示：

    CREATE PROCEDURE foo.'bar'()
    BEGIN
        UPDATE mytable SET mycolumn1 = variable1
        WHERE mycolumn2 = 
            convert(variable2 using latin1) collate latin1_swedish_ci
    END;

其中（latin1，latin1\u swedish\u ci）与创建我的表格时使用的排序规则相同

要检查MySQL是否使用索引，您可以将存储过程更改为运行

explain

语句，如下所示：

    CREATE PROCEDURE foo.'bar'()
    BEGIN
        EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
    END;

在我的例子中，

explain

结果显示在查询执行期间没有使用索引

请注意，当您单独运行查询时，MySQL可能会使用索引，但仍然不会在存储过程中对同一查询使用索引，这可能是因为MySQL在另一个排序规则中看到了变量

有关排序规则问题的更多信息，请参见： 备份链接：

---

我们今天遇到的一个问题是，参数（或者可能是变量）名称与列名相同，这使得过程速度变慢，即使它们作为直接查询运行得非常快。简短的版本是，不要使用与将在其中使用参数的查询中的某个列相同的参数名。例如，如果您有一个名为

account\u id

的字段和一个名为相同的参数，请将其更改为类似于

in\u account\u id

的内容，您的运行时间可以从几秒到百分之一秒。

我们需要查看一些代码。首先，你在声明/处理变量时会做出一些奇怪的猜测。。。但这完全是胡乱猜测，没有看到一些代码。正如我所说，非常简单的查询本身运行得非常快，只需

updatetable SET column=variable其中othercolumn>=othervariable或othercolumn=yetanothervar

键入内容即可。变量以varname COLUMNTYPE（SIZE）格式的常规

声明为存储过程的参数。让我困惑的是，没有什么奇怪或缓慢的事情（是的，我正在避免显示代码，因为我的老板可能对我这样做很生气）。我可以提到，除了第一次
更新
查询之外，删除了所有查询（它本身运行不到0.05秒，然后运行存储的proc仍然会给出1s左右的执行时间，上面的注释是一个非常恰当的描述。）
    CREATE PROCEDURE foo.'bar'()
    BEGIN
        EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
    END;