MySQL存储过程死锁排查与解决方案 | 实战教程

2024-12-25 12:10:55

MySQL存储过程死锁问题排查与解决

存储过程中的死锁（Deadlock）是一个棘手的并发问题，其表现为多个事务相互持有对方需要的锁，导致所有事务都无法继续执行，最终数据库会选择回滚部分事务来解除死锁状态。本文针对“MySQL: Deadlock inside stored procedure”这种常见的报错情况，深入分析问题原因，并给出相应的解决策略。

死锁现象分析

观察上述提供的存储过程和自定义函数的代码片段，核心逻辑可以简化为：一个存储过程在事务内进行INSERT操作，并调用自定义函数 updateJournal，后者内部也有INSERT和UPDATE操作。死锁错误经常发生在 updateJournal 执行的过程中。

根本原因是锁竞争。尽管存储过程使用了 START TRANSACTION;，COMMIT; 和 ROLLBACK;，但MySQL内部，不同资源需要不同类型的锁保护。问题在于 tableA, tableB， tableC, 和 tableD 表中的数据存在交错更新的场景，或者函数内的 INSERT 和 UPDATE 与其他事务产生了锁的冲突，导致死锁发生。

具体地讲，可能发生以下一种或几种情况：

行锁竞争： 存储过程和函数 updateJournal 内部都存在 INSERT 或 UPDATE 操作，若其他事务尝试修改这些操作正在使用的数据行，就会产生锁竞争。例如：事务A锁定 tableA 的一行，然后尝试更新 tableC；同时事务B锁定 tableC 的一行，然后尝试更新 tableA。这种循环依赖关系将导致死锁。
函数内的隐含事务： 自定义函数内若也使用了事务操作（尽管示例代码中没有明确写明），与存储过程外层事务产生冲突时也容易引发死锁。尤其要注意 INSERT INTO tableC...和 UPDATE tabled...这些操作，需要仔细检查是否和其他事务可能存在锁的冲突。
表锁竞争： 虽然行锁是InnoDB默认的锁定机制，但是在特定情况下可能触发表锁，特别是当涉及到ALTER TABLE 这样的DDL操作。当发生锁升级时，可能导致更大的死锁风险。
意向锁冲突： 当一个事务请求一个表的行级锁时，数据库会先在表级上添加一个意向锁。如果其他事务在该表上持有表级别的共享锁或者排他锁，那么该事务的行级锁就会被阻塞，形成潜在的死锁可能。

需要特别指出，尽管存储过程的 IF err_code != '00000' 条件使得事务回滚，但是自定义函数 updateJournal 内的数据库修改操作仍然可能会生效。这是因为在大多数MySQL版本中，自定义函数默认运行在自己的独立事务环境中，并不会直接受到外部存储过程事务回滚的影响。

解决方案与实践

要解决存储过程内的死锁问题，重点在于避免锁竞争。以下是一些通用的解决办法，请根据实际情况选择或组合使用。

优化索引和查询: 确保查询使用高效索引，减少锁定的行数，并加速事务执行，可以降低死锁的发生几率。对于tableA, tableB, tableC, 和 tableD表，仔细检查是否使用了合适的索引。使用 EXPLAIN 分析查询，定位性能瓶颈，并据此添加或调整索引。

EXPLAIN SELECT * FROM tableA WHERE id = 123;
EXPLAIN SELECT * FROM tableC WHERE orderId = 456;

操作步骤：
* 执行EXPLAIN 语句查看执行计划。
* 如果 type 列为ALL或者 key 列为空, 表示查询未使用索引，需建立合适的索引。
* 根据 key 和 rows 列查看使用的索引是否高效，决定是否要调整索引。

优化存储过程逻辑:
调整SQL执行顺序，先更新不涉及数据冲突的表，再处理可能引起锁冲突的表。简化复杂存储过程逻辑，尽量分解成更小的、独立的操作，减少单个事务中持有锁的时间。也可以在程序层面加入一些退避和重试机制来处理短暂的死锁情况。例如：将insert和update的逻辑分离开执行。

示例：将函数内的INSERT和UPDATE 分开，在存储过程主体中按顺序执行

-- 修改前的存储过程逻辑 (仅作演示，并未完成功能代码）
DELIMITER //
CREATE PROCEDURE process_order(IN orderId INT)
BEGIN
  DECLARE err_code CHAR(5) DEFAULT '00000';
  DECLARE msg TEXT;
  DECLARE x INT;
  DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
    BEGIN
        GET DIAGNOSTICS CONDITION 1
        err_code = RETURNED_SQLSTATE, msg = MESSAGE_TEXT;
    END;

  START TRANSACTION;

    INSERT INTO tableA ... ;
    INSERT INTO tableB ...;

    SELECT updateJournal(orderId) INTO x;
     
  IF err_code != '00000' THEN
      ROLLBACK;
       INSERT INTO log (msg) VALUES (msg);
    ELSE
      COMMIT;
  END IF;

END//
DELIMITER ;

DELIMITER //
CREATE FUNCTION updateJournal(orderId INT) RETURNS int
BEGIN 
  INSERT INTO tableC ....; 
  UPDATE tabled ....;

RETURN 1; END//
DELIMITER ;


-- 修改后的存储过程逻辑 
DELIMITER //
CREATE PROCEDURE process_order_new(IN orderId INT)
BEGIN
  DECLARE err_code CHAR(5) DEFAULT '00000';
  DECLARE msg TEXT;
  DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
    BEGIN
        GET DIAGNOSTICS CONDITION 1
        err_code = RETURNED_SQLSTATE, msg = MESSAGE_TEXT;
    END;

  START TRANSACTION;
   INSERT INTO tableA ... ;
   INSERT INTO tableB ... ;
    INSERT INTO tableC ... ; -- tableC的插入逻辑放到这里
   UPDATE tableD ...;  -- tableD的更新逻辑放到这里

    IF err_code != '00000' THEN
     ROLLBACK;
     INSERT INTO log (msg) VALUES (msg);
   ELSE
      COMMIT;
    END IF;

END//
DELIMITER ;
--  去除原有的 函数
DROP FUNCTION updateJournal

操作步骤：
* 修改或重新定义存储过程，删除函数调用逻辑。
* 执行新的存储过程观察是否死锁情况。
3. 控制事务隔离级别: 检查当前事务的隔离级别。若隔离级别过高（例如，SERIALIZABLE）,可能加剧锁的冲突。建议使用较低隔离级别（例如, READ COMMITTED），但这也要评估对数据一致性的潜在影响。修改隔离级别一般使用 SET TRANSACTION ISOLATION LEVEL 命令

--  查询当前的事务隔离级别
SELECT @@transaction_isolation;

--  将当前的隔离级别设置为 `READ COMMITTED`
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

操作步骤：

执行 SELECT @@transaction_isolation 命令查看当前的隔离级别
根据业务需求，设定合理的隔离级别，并通过 SET 命令生效。
测试验证变更的隔离级别是否带来死锁问题。

简化存储过程和自定义函数: 将存储过程和自定义函数逻辑尽可能简化，并确保函数没有自己的事务管理机制。这样，所有数据库修改操作都在存储过程的事务内统一管理，能有效避免跨事务边界的死锁。将函数内的操作与主存储过程统一执行。例如：上文示例中的修改逻辑。
重试机制： 采用退避重试策略来处理偶尔出现的死锁。存储过程检测到死锁后进行短暂等待（如几秒），然后重试执行。可以增加while循环结合重试的次数进行。

DELIMITER //
CREATE PROCEDURE process_order_retry(IN orderId INT)
BEGIN
  DECLARE err_code CHAR(5) DEFAULT '00000';
  DECLARE msg TEXT;
  DECLARE x INT;
  DECLARE retry_count INT DEFAULT 3; -- 最大重试次数
  DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
      BEGIN
          GET DIAGNOSTICS CONDITION 1
          err_code = RETURNED_SQLSTATE, msg = MESSAGE_TEXT;
        IF err_code = '40001' THEN
             --  此处40001是SQLSTATE 代码对应死锁
             SET retry_count = retry_count -1;
             IF retry_count > 0 THEN
             DO SLEEP(2);  --  等待两秒
                SIGNAL SQLSTATE '45000'  SET MESSAGE_TEXT = 'Retrying Transaction';
             END IF;
         END IF;
        END;

   retry_loop: WHILE retry_count > 0  DO
    BEGIN
   START TRANSACTION;

        INSERT INTO tableA ... ;
         INSERT INTO tableB ...;

        SELECT updateJournal(orderId) INTO x;
     IF err_code != '00000' THEN
      ROLLBACK;
           INSERT INTO log (msg) VALUES (msg);
        ELSE
             COMMIT;
       END IF;

   LEAVE retry_loop; --  成功退出循环
  END;

   END WHILE retry_loop;
  END//
  DELIMITER ;

-- 注意：自定义函数中不再需要事物和重试
DELIMITER //
CREATE FUNCTION updateJournal_retry(orderId INT) RETURNS int
BEGIN 
   INSERT INTO tableC ... ; 
   UPDATE tabled ... ;
   RETURN 1; END//
DELIMITER ;