存储过程内不能使用 START TRANSACTION 实现事务控制，因其会隐式提交当前事务；正确做法是由调用端显式开启事务，存储过程仅封装 DML 操作与校验，并通过异常处理器配合外部事务回滚。
直接用 START TRANSACTION 包裹转账逻辑，在存储过程中是无效的——MySQL 存储过程默认不开启新事务，且显式 START TRANSACTION 会隐式提交当前活跃事务，导致意外中断。
存储过程里不能直接写 START TRANSACTION
在存储过程中执行 START TRANSACTION，MySQL 会报错或静默提交已有事务（取决于 autocommit 状态），无法达成你想要的“整个过程原子执行”。真正起作用的是调用方控制事务边界，而非过程内部启动。
- 存储过程本身不是事务容器，它只是 SQL 语句的封装
-
START TRANSACTION是会话级命令，一旦执行，会终结上一个未提交事务 - 如果过程被嵌套调用，内部
START TRANSACTION可能导致外层事务提前提交，数据已落盘
正确做法：由调用端开启事务，存储过程只做 DML
把转账逻辑封装成纯操作型存储过程（无事务控制语句），然后由应用或客户端显式开启事务、调用过程、再决定 COMMIT 或 ROLLBACK。
- 存储过程只包含
UPDATE语句和参数校验，例如：UPDATE accounts SET balance = balance - amount WHERE id = from_id - 调用前确保
autocommit = 0，或显式执行BEGIN/START TRANSACTION - 调用后检查返回影响行数或捕获异常，失败时立即
ROLLBACK
示例调用流程：
SET autocommit = 0; START TRANSACTION; CALL TransferMoney(1, 2, 100.00); -- 检查是否成功（如通过 ROW_COUNT() 或 OUT 参数） IF ROW_COUNT() = 2 THEN COMMIT; ELSE ROLLBACK; END IF;
想在过程内兜底？用 DECLARE HANDLER + 自动回滚
如果必须让存储过程具备“出错即撤回”能力，唯一可靠方式是依赖 MySQL 的异常处理器，并配合外部事务——过程内不启动事务，但声明异常处理，靠调用方的事务机制回滚。
- 用
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION设置标志位 - 过程末尾不
COMMIT，也不ROLLBACK，把控制权交还给调用者 - 调用者根据返回状态（比如
OUT error_flag）决定是否ROLLBACK - 注意：InnoDB 在遇到异常时不会自动回滚当前事务，必须显式
ROLLBACK
容易忽略的关键点
很多人以为写个 START TRANSACTION ... COMMIT 在存储过程里就万事大吉，实际上：
- 过程里的
COMMIT会提交整个会话事务，可能连带其他未预期的修改 - 如果过程被多个地方调用，有的地方开了事务、有的没开，行为完全不可控
-
autocommit=1下，每条语句都是独立事务，START TRANSACTION后第一条 UPDATE 就已入盘，后续失败也无法回退 - 真正保障原子性的，是调用链最外层的事务控制 + InnoDB 行锁 + 唯一约束等一致性手段，不是过程语法糖
