MySQL：使用事务处理嵌套存储过程中的回滚答案

【问题标题】：MySQL: Handling Rollback in Nested Stored Procedures With TransactionsMySQL：使用事务处理嵌套存储过程中的回滚
【发布时间】：2018-05-22 14:04:27
【问题描述】：

我有 4 个存储过程，我们将它们命名为 spA、spB、spC 和 spD。

每个存储过程都有一个启动事务、提交和回滚。

spA 当前是父 存储过程(SP)，在其中，我按各自的顺序调用 spB、spC、spD。显然，因为所有的 SP 都有提交，所以当 spC 失败时，在 spB 中执行的 DML 操作不会恢复，因为它们已经提交，并且当 spD 失败时 spB 和 spC 中的操作不会回滚。

我在 spB、spC 和 spD 中提交的原因是，稍后我可能会直接使用这些 SP 中的任何一个来执行与 SP 相关的操作。

目前，我计划使用输入位标志来决定是否提交事务。在 MS SQL 中，有一个检查 @@transcount 的选项，但是，我在 MySQL 中找不到类似的东西。

我想知道是否有更好的方法来处理这种情况。

【问题讨论】：

我的建议是不要将提交放在存储过程中。如果一切都按预期完成，则在 sp 之后提交。我真的不明白你这样做的原因，但我认为这样做的成本超过了收益。
正如我提到的，我计划稍后单独使用父 SP 中的各个 SP。假设 spB、spC、spD 在表 B、C 和 D 中插入数据。这样，spA 会同时在所有三个表（B、C 和 D）中插入数据。但是，稍后我可能只想在表 B、C 或 D 中插入数据。为此，我只需调用相应的 spB、spC 或 spD。因此，我也需要这些 SP 中的事务（启动、提交和回滚）。它解释了我为什么这样做吗？
只管理一个事务更容易（MySQL本身没有嵌套的工具）。当您以后使用它们时，您总是可以将 B、C 和 D 调用包装在事务中。
我发现的一件事是我不能做我计划做的事情，因为在 MySQL 中每次遇到新的启动事务时，新启动事务之前的所有 DML 查询都被隐式提交。所以我将不得不坚持使用包装技术。如果有更方便的方式，我会喜欢的。

标签： mysql database stored-procedures transactions rdbms

【解决方案1】：

我同意上面的 cmets。我建议您在调用任何存储过程之前，仅在应用程序的“顶层”启动和提交事务。不要在存储过程中开始或提交事务。

试图像 Microsoft SQL Server 对 @@trancount 那样欺骗 ROLLBACK 和 COMMIT 会导致比上述指南更难处理的异常，以在应用程序级别管理事务。

我在 10 年前发布了一个类似的答案，但它与 ORM 类有关，而不是存储过程：How do detect that transaction has already been started?

【讨论】：

【解决方案2】：

管理你自己的变量，看起来 MySQL 不处理这种行为。所以添加一个输入 p_tran_call 位并将其设置为 1 如果 spA 调用 else 0 然后执行 if p_tran_call 为 0 然后开始 tran 和回滚。

确定这就是我的做法。

创建过程 spB(p_tran_control bit) 存在

   declare exit handler for sqlexception
   begin
         if p_tran_control = 0 the 
             rollback;
         end if;
   end; #end of handler

  if p_tran_control = 0 then
         begin transaction;
   end if;


    #more code;


   if p_tran_control = 0 then
        commit;
    end if;

结束

创建过程 spA 开始

  begin transaction;


 call spB(1);


  commit transaction;

结束

现在，我注意到了，事务不会转到任何嵌套调用。因此，如果您从有效的 spA 调用 spB，但是如果您从保存事务的 spA 调用的 spB 调用 spC，则 spC 将提交。即使自动提交设置为关闭；

【讨论】：