MySQL的存储过程在复杂业务中被广泛使用，但当多个存储过程相互调用且都涉及数据写入时，事务该如何控制成为难点。MySQL从语法层面并不支持真正的事务嵌套，也就是说在一个已开启的事务中再执行START TRANSACTION并不会开启子事务，而是会隐式提交当前事务。这就导致开发者如果照搬其他数据库里的嵌套事务写法，很容易造成数据不一致。解决这类问题通常有两种务实思路：伪嵌套逻辑与Savepoint机制。
为什么MySQL没有真正的事务嵌套
在Oracle或PostgreSQL中，可以通过自治事务或SAVEPOINT配合ROLLBACK TO实现类似嵌套的效果。但MySQL的InnoDB引擎只维护一个顶层事务上下文。当会话处于事务中时，再发出START TRANSACTION命令，MySQL会先执行一个隐式COMMIT，把之前的操作全部提交，然后开启新事务。这种行为对存储过程来说非常危险，因为被调用的子过程若包含了START TRANSACTION，调用方的未提交数据就会提前落地。
我们可以通过一个简单的实验来验证。在命令行中先执行几条更新语句，不提交，然后调用一个内部含有START TRANSACTION的存储过程，退出过程后再查看数据，会发现前面的更新已经生效。这种机制决定了在MySQL存储过程里做事务嵌套，不能依赖标准的BEGIN/COMMIT语法，而必须换一种表达方式。
-- 主过程
CREATE PROCEDURE parent_proc()
BEGIN
UPDATE account SET balance = balance - 100 WHERE id = 1;
CALL child_proc(); -- 子过程里若含START TRANSACTION会隐式提交
-- 此时上面的UPDATE已经提交，无法回滚
END;
-- 子过程
CREATE PROCEDURE child_proc()
BEGIN
START TRANSACTION; -- 这里会导致parent_proc的更新被隐式提交
INSERT INTO log VALUES ('child');
COMMIT;
END;
使用Savepoint实现可控的部分回滚
Savepoint是MySQL提供的一个轻量级标记机制。它允许在一个事务中打多个回滚点，后续可以只回滚到某个点而不影响该点之前的操作。在存储过程相互调用时，调用方可以在调用前声明一个Savepoint，若子过程执行失败，则回滚到该点，外层逻辑继续处理或整体回滚。
下面的示例展示了主过程在调用子过程前设置Savepoint，并在异常处理中回滚到该点。注意子过程内部不再使用START TRANSACTION，而是假设它在一个已存在的事务中运行。如果子过程内部出错，我们通过RESIGNAL或者返回值通知主过程，由主过程决定回滚范围。
DELIMITER $$
CREATE PROCEDURE child_proc(OUT err_code INT)
BEGIN
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
BEGIN
SET err_code = 1;
END;
INSERT INTO order_detail VALUES (1, 'item_a', 2);
-- 模拟可能出错的操作
INSERT INTO order_detail VALUES (1, 'item_b', -5); -- 违反非负约束则触发异常
END$$
CREATE PROCEDURE parent_proc()
BEGIN
DECLARE child_err INT DEFAULT 0;
START TRANSACTION;
UPDATE account SET balance = balance - 100 WHERE id = 1;
SAVEPOINT sp_child;
CALL child_proc(child_err);
IF child_err = 1 THEN
ROLLBACK TO sp_child;
-- 主过程可选择继续其他逻辑或整体回滚
INSERT INTO compensate_log VALUES ('child failed, rolled back');
ELSE
RELEASE SAVEPOINT sp_child;
END IF;
COMMIT;
END$$
DELIMITER ;
这种方式的优点在于粒度细，可以精确控制哪一部分被撤销。缺点是Savepoint不能跨会话，也不能跨存储过程边界自动传递，需要显式设计错误传递通道，比如用OUT参数或状态码。另外Savepoint过多会带来一定的内存与日志开销，但在常规业务量级下可以接受。
伪嵌套逻辑：把子过程移出事务边界
伪嵌套逻辑的核心思想是避免在被调用过程中触碰事务控制，而是将子过程需要做的操作记录下来，由外层或异步任务去执行。例如把写日志、发通知等辅助操作插入到一张待处理表，主事务提交后再通过事件调度器或外部脚本读取并处理。这样从业务语义上看像是在子过程里完成了某些动作，但实际上这些动作不在同一个事务里，从而绕开了嵌套限制。
下面的代码演示了伪嵌套做法：子过程只负责往task_queue里插一条记录，本身不开启事务也不做实际外部写入。主过程提交后，由独立的worker完成真正操作。这种方案适合对一致性要求不是绝对同步的场景，比如操作日志、统计汇总。
CREATE PROCEDURE child_proc_pseudo(IN main_id INT) BEGIN -- 不开启事务，仅记录任务 INSERT INTO task_queue (ref_id, task_type, payload, status) VALUES (main_id, 'write_log', 'order created', 'pending'); END; CREATE PROCEDURE parent_proc() BEGIN START TRANSACTION; INSERT INTO orders VALUES (NULL, 100, NOW()); SET @last_id = LAST_INSERT_ID(); CALL child_proc_pseudo(@last_id); COMMIT; -- 提交后由外部worker处理task_queue中的记录 END;
伪嵌套逻辑的优势是简单、对MySQL事务模型零侵入，也不会因为子过程异常拖垮主流程。劣势是牺牲了实时一致性，如果worker失败需要重试与监控。在金融扣款等强一致场景应优先使用Savepoint，在日志类弱一致场景用伪嵌套更轻量。
两种方案的选择建议
当业务要求子过程失败不能污染主过程已写数据，且必须同步返回结果时，Savepoint是更直接的选择。它保留了单一事务的原子视图，只是把回滚范围缩小。当子过程做的是边缘业务，如审计、缓存刷新、消息发送，将其改为伪嵌套可以显著降低存储过程的复杂度和锁持有时间。
实际项目中也可以组合使用：核心链路用Savepoint保证可控回滚，非核心链路用任务表异步化。重要的是在存储过程文档中明确标注哪些过程会设置Savepoint、哪些过程禁止内部开启事务，避免后来维护者误写START TRANSACTION导致隐式提交事故。
| 对比维度 | Savepoint方案 | 伪嵌套逻辑 |
|---|---|---|
| 一致性 | 强一致，同事务内 | 最终一致，跨事务 |
| 实现复杂度 | 中，需错误处理传递 | 低，仅插队列表 |
| 适用场景 | 订单、扣款等核心流 | 日志、通知等辅助流 |
理解MySQL存储过程的事务边界，是写出稳定后台逻辑的基础。面对嵌套需求，不要试图用START TRANSACTION去套层，而应从Savepoint与伪嵌套两条路中挑出贴合业务的一款。