mysql存储过程不能自行控制事务，因start transaction会隐式提交当前事务且commit影响整个会程；正确做法是调用方显式开启事务，过程仅执行dml并返回结果供上层决定commit或rollback。
MySQL 存储过程本身不提供事务边界，订单创建的原子性必须由调用方显式控制——过程里写 START TRANSACTION 或 COMMIT 不仅无效，还可能意外提交已有事务。
为什么存储过程内不能自己开事务
很多人在过程里直接写 START TRANSACTION 和 COMMIT，以为能兜住“插入订单+扣库存+写日志”这一整套逻辑，结果发现订单进了库、库存没扣、日志也没写，或者反过来。根本原因是：
-
START TRANSACTION是会话级命令，执行时会隐式提交当前活跃事务（如果存在） - MySQL 存储过程不是事务容器，InnoDB 不允许过程内开启新事务上下文
- 过程被嵌套调用时，内部
START TRANSACTION可能提前终结外层事务，导致已修改数据落盘无法回滚 -
COMMIT会提交整个会话事务，连带其他未预期的修改一起生效
正确做法：调用端显式开启并控制事务
把存储过程当作纯操作单元，只做 DML 和校验，事务交给上层决定。关键动作包括：
- 调用前确保
autocommit = 0，或显式执行START TRANSACTION - 过程体只包含类似
INSERT INTO orders ...、UPDATE stock SET qty = qty - 1 WHERE id = ? AND qty >= 1这类语句 - 用
ROW_COUNT()或OUT参数返回影响行数/错误标志，供调用方判断是否继续 - 调用后立即检查结果：成功则
COMMIT，失败则ROLLBACK
示例调用片段：
SET autocommit = 0; START TRANSACTION; CALL CreateOrder(123, '2026-08-10', 299.99); IF ROW_COUNT() = 1 THEN COMMIT; ELSE ROLLBACK; END IF;
并发下订单超发怎么防
加了事务不代表不会超卖。比如库存扣减写成：
UPDATE products SET stock = stock - 1 WHERE id = 123;
高并发下仍可能变成负数。真正可靠的写法是把业务规则直接写进 WHERE：
UPDATE products SET stock = stock - 1 WHERE id = 123 AND stock >= 1;
这个语句本身原子执行：引擎层一次完成读取、判断、计算、写回。事务在这里毫无增益，反而可能因锁持有时间变长引发阻塞。
- 条件
WHERE是业务原子性的第一道也是最硬的一道防线 - 若需跨表强一致性（如订单+库存+积分），必须配合
SELECT ... FOR UPDATE锁住相关行，且该语句必须在事务内、有索引支持 - 避免用
GET_LOCK()做应用级锁，除非你严格配对RELEASE_LOCK()，且锁名含业务上下文（如'order_create_123'）
异常处理别越界
想加兜底？可以用 DECLARE HANDLER，但必须守住一条线：不执行 COMMIT 或 ROLLBACK。
- 声明
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION设置OUT error_flag = 1 - 过程末尾不做任何事务控制，把回滚责任完整交还给调用方
- 注意：InnoDB 遇到异常不会自动回滚，
ROLLBACK必须显式发出 - 绝对不要在
EXIT HANDLER里写ROLLBACK——它会破坏外层事务一致性
最易被忽略的是：事务没提交就断连，锁可能残留；而 SELECT ... FOR UPDATE 没走索引，会升级为表锁——这些细节比语法更决定原子性成败。
