MySQL不支持事务嵌套，START TRANSACTION会隐式提交前一事务；唯一可行方案是SAVEPOINT，它在当前事务内设标记点，配合ROLLBACK TO SAVEPOINT实现局部回滚，且需调用方控制事务边界。
MySQL执行START TRANSACTION为什么会意外提交前一个事务
因为MySQL根本不支持嵌套事务。START TRANSACTION不是“挂起当前事务再开一个”，而是先隐式执行COMMIT，再开启新事务。这意味着：前一个事务里所有未提交的INSERT/UPDATE操作立刻落库，不可逆；后续ROLLBACK只能撤回新事务里的操作，对已提交的数据完全无效。
典型现象包括：ERROR 1305 (42000): SAVEPOINT does not exist（SAVEPOINT被提前清空）、回滚后发现数据还在、或者事务中途SELECT查不到刚插入的记录（已被提交并受隔离级别影响）。
- 所有DDL语句（如
CREATE TABLE、ALTER TABLE）也会触发隐式提交，不只是START TRANSACTION - 即使存储过程里只写一次
START TRANSACTION，只要调用方已开启事务，它就等于强行提交+重开，破坏原有事务边界 - 确保
AUTOCOMMIT = 0是前提，否则连基础事务控制都失效
为什么SAVEPOINT是唯一可行的“伪嵌套”手段
SAVEPOINT不开启新事务，只在当前活跃事务内打标记点，符合MySQL扁平事务模型。它轻量、可控，且能实现“局部回滚”——比如用户注册成功但权限分配失败，只撤回后者，保留前者。
关键行为：SAVEPOINT sp_name定义点（同名会覆盖，不报错）；ROLLBACK TO SAVEPOINT sp_name回退到该点；RELEASE SAVEPOINT sp_name可选释放；事务结束（COMMIT或ROLLBACK）时自动清理所有SAVEPOINT。
- 名字必须带上下文标识，例如
sp_after_user_insert，避免不同逻辑块重复覆盖 - 仅InnoDB等支持事务的引擎有效，MyISAM忽略
SAVEPOINT - 不能跨连接使用——每个客户端连接的
SAVEPOINT独立作用域
存储过程中正确使用SAVEPOINT的实操结构
事务边界必须由调用方控制，存储过程内部只负责分段和标记。不要在过程里写START TRANSACTION或COMMIT，否则直接破坏外层一致性。
DELIMITER //
CREATE PROCEDURE proc_do_something(IN p_user_id INT)
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK TO SAVEPOINT sp_main;
RESIGNAL;
END;
<p>INSERT INTO users (id) VALUES (p_user_id);
SAVEPOINT sp_after_user;</p><p>INSERT INTO profiles (user_id, bio) VALUES (p_user_id, 'default');
-- 若此处失败，只回滚profiles插入，users记录保留
IF some_condition THEN
ROLLBACK TO SAVEPOINT sp_after_user;
END IF;
END//
DELIMITER ;- 异常处理器必须用
ROLLBACK TO SAVEPOINT，而非ROLLBACK全局回滚 - 每个
SAVEPOINT后应有明确的业务语义锚点，便于定位和调试 - 若过程被多处调用，需确认调用方是否已开启事务——没开的话，
SAVEPOINT会报错
PHP/ORM中模拟嵌套事务的底层逻辑是什么
像Laravel或Doctrine这类框架所谓“支持嵌套事务”，本质是用_transactionNestingLevel计数器 + SAVEPOINT自动管理。第一层调用beginTransaction()真开事务；第二层及以上只打SAVEPOINT，rollback()时根据层级决定是真回滚还是退到保存点。
你自己手写时别照搬框架封装——重点是理解其映射关系：嵌套层数 > 1 ⇨ 实际只用SAVEPOINT，且必须保证外层事务始终由最外层代码控制生命周期。
- 不要在函数A里
START TRANSACTION，再调用函数B（也含START TRANSACTION），这是典型误用 - 框架的“嵌套”只是语法糖，底层仍依赖
SAVEPOINT，一旦跨连接或手动干预事务状态，糖就失效 - 生产环境排查时，优先查
SHOW ENGINE INNODB STATUS里的事务列表，确认是否真有多个活跃事务（通常没有）
事务嵌套的复杂点不在语法，而在业务逻辑与事务边界的错位——你以为的“子事务”其实是同一事务里的不同阶段，而SAVEPOINT就是给这个阶段打标签的唯一可靠方式。名字重复、忘记设点、或在非事务上下文中调用，都会让局部回滚失效。
