单条UPDATE本身原子，无需BEGIN；仅多语句需“全成功或全失败”时才需START TRANSACTION，如订单创建+库存扣减+积分更新、主子表关联插入、跨表校验更新等场景。
单条 UPDATE 本身已是原子的，不需要 BEGIN TRANSACTION 包裹；只有多条语句必须“全成功或全失败”时，才需要事务。
MySQL 中哪些操作真正需要 START TRANSACTION
事务不是万能开关，它只对「多个语句构成逻辑整体」的场景起作用。常见真实需求包括：
- 订单创建 + 库存扣减 + 积分更新：三者必须同步，缺一不可
- INSERT 主表后用
LAST_INSERT_ID()插入子表：子表依赖主表生成的 ID - 先查用户等级（
SELECT ... FROM user_levels），再根据结果决定是否允许执行UPDATE orders - 跨表校验型更新：比如检查优惠券状态 + 更新订单状态 + 写日志，任一环节失败都得回滚
这些场景下，任意一步出错都会导致数据不一致——这时才该用 START TRANSACTION 显式开启事务边界。
为什么写了 BEGIN 却没生效？autocommit 是最大干扰项
你执行了 BEGIN TRANSACTION，但下一条语句一跑完就自动提交了，根本没进事务上下文。原因几乎总是：autocommit = 1（MySQL 默认开启）。
- 先运行
SELECT @@autocommit;确认值是否为0 - 如果不是，立刻执行
SET autocommit = 0;（注意：该设置仅对当前连接有效） - 优先用
START TRANSACTION而非BEGIN，部分客户端工具（如 DBeaver）会拦截BEGIN并强制自动提交 - ORM 场景中，
session.flush()≠session.commit()：前者只同步到 DB 缓冲区，后者才真正触发 COMMIT
UPDATE 条件判断才是防并发错的关键防线
很多人以为加了事务就能防超卖，其实不然。比如扣库存写成：
UPDATE products SET stock = stock - 1 WHERE id = 123;
即使包在事务里，高并发下仍可能变成负数。真正可靠的写法是把业务规则直接写进 WHERE：
UPDATE products SET stock = stock - 1 WHERE id = 123 AND stock >= 1;
这个语句本身原子执行：引擎层一次完成读取、判断、计算、写回。事务在这里毫无增益，反而可能因锁持有时间变长引发阻塞。
所以，条件 WHERE 不是可选项，而是业务原子性的第一道也是最硬的一道防线。
事务没提交就断连，锁可能残留
连接异常中断（比如网络抖动、应用 crash）时，MySQL 会自动回滚未提交事务，但某些锁未必立即释放。
- PostgreSQL 可查
pg_stat_activity中state = 'idle in transaction'的残留会话 - MySQL 侧虽无直接对应视图，但长时间未提交事务会占用行锁/间隙锁，影响其他事务执行
- 生产环境建议设置
wait_timeout和interactive_timeout避免僵尸连接长期占资源
事务不是保险箱，它是有状态、有时效、会受外部干扰的机制。关键点永远落在：是否真需要多语句强一致性、autocommit 是否关掉、WHERE 条件是否兜住业务逻辑、连接生命周期是否可控。
