存储过程不提供事务边界，原子性须由调用方控制；过程内禁止start transaction/commit，应由外部显式开启事务并根据返回值决定commit或rollback，并发安全需额外加锁。
存储过程本身不提供事务边界，原子性必须由调用方控制——过程内写 START TRANSACTION 不仅无效，还可能意外提交已有事务。
MySQL 存储过程中不能用 START TRANSACTION
很多人在过程里直接写 START TRANSACTION 和 COMMIT，以为能兜住逻辑，结果发现转账一半成功、余额错乱。这是因为：
-
START TRANSACTION是会话级命令，执行时会隐式提交当前活跃事务（如果存在） - 存储过程不是事务容器，它只是 SQL 封装；InnoDB 不允许过程内开启新事务上下文
- 若过程被嵌套调用，内部
START TRANSACTION可能提前终结外层事务，导致数据已落盘无法回滚 - 过程里的
COMMIT会提交整个会话事务，连带其他未预期的修改一起生效
正确做法：调用端显式控制事务
把存储过程当作“纯操作单元”，只做 DML 和校验，事务交给上层决定：
- 调用前确保
autocommit = 0，或显式执行START TRANSACTION - 过程只包含类似
UPDATE accounts SET balance = balance - amount WHERE id = from_id这类语句 - 用
ROW_COUNT()或OUT参数返回影响行数/错误标志，供调用方判断是否继续 - 调用后立即检查结果：成功则
COMMIT，失败则ROLLBACK
示例调用片段：
SET autocommit = 0; START TRANSACTION; CALL TransferMoney(1, 2, 100.00); IF ROW_COUNT() = 2 THEN COMMIT; ELSE ROLLBACK; END IF;
想加兜底？用 DECLARE HANDLER，但别自己 COMMIT/ROLLBACK
如果希望过程在出错时“自动标记失败”，可用异常处理器，但必须守住一条线：不执行 COMMIT 或 ROLLBACK。
- 声明
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION设置OUT error_flag = 1 - 过程末尾不做任何事务控制，把回滚责任完整交还给调用方
- 注意：InnoDB 遇到异常不会自动回滚，
ROLLBACK必须显式发出 - 避免在
EXIT HANDLER里写ROLLBACK—— 它会破坏外层事务一致性
并发安全要靠锁，不是靠过程封装
原子性 ≠ 并发安全。即使事务包裹得再严，高并发下仍可能因读-改-写竞争导致超扣。这时候得补锁：
- MySQL 没有
sp_getapplock，可用SELECT ... FOR UPDATE（需在事务内、有索引支持） - 或用
GET_LOCK('voucher_use_45678', 5)做应用级命名锁，但务必配对RELEASE_LOCK() - 锁名必须含业务上下文，比如
'db_shop_stock_check_123'，避免全局冲突 -
IS_USED_LOCK()只能查状态，不能替代正确释放逻辑；连接断开时锁自动释放，但没写RELEASE_LOCK()会导致锁残留
真正容易被忽略的点是：事务控制和并发控制是两层事——BEGIN 只管“全做或全不做”，而防止并发覆盖得靠锁或条件更新（如 WHERE balance >= amount），两者缺一不可。
