MySQL事务需显式BEGIN与COMMIT/ROLLBACK配对，隔离级别、连接一致性、异常回滚及原子SQL（如UPDATE加条件）缺一不可，否则无法保障数据一致。
MySQL 事务不是“开了就能保证一致”，关键在 BEGIN 到 COMMIT 之间的操作是否真正覆盖了所有关联变更，且隔离级别和错误处理没被绕过。
事务必须显式开启并配对提交/回滚
很多业务代码看似用了 START TRANSACTION，但实际执行中可能被框架自动提交、或异常后没走 ROLLBACK，导致部分写入残留。
- 手动控制时，务必检查每条 SQL 是否在同一个连接内执行（连接池场景下尤其注意连接复用）
- PHP 中
mysqli默认自动提交，需先调用mysqli_autocommit($conn, false)；PDO 则需关闭PDO::ATTR_AUTOCOMMIT - 应用层捕获异常后，必须显式调用
ROLLBACK，不能只依赖 finally 块——某些语言运行时异常可能跳过 finally - 避免在事务中调用外部服务（如发短信、调支付接口），超时或失败会导致事务卡住或误判
UPDATE 涉及库存扣减时必须加行锁防超卖
单纯靠 SELECT ... FOR UPDATE 不够，若 WHERE 条件未命中索引，会升级为表锁；更常见的是漏掉锁范围，导致并发扣减失效。
- 确保
SELECT ... FOR UPDATE的 WHERE 字段有唯一索引或主键，否则 MySQL 可能锁住整个范围（Gap Lock） - 库存扣减逻辑应合并为一条原子语句：
UPDATE goods SET stock = stock - 1 WHERE id = ? AND stock >= 1，再用mysql_affected_rows()或ROW_COUNT()判断是否扣减成功 - 不要先
SELECT stock再UPDATE，中间可能被其他事务修改，即使加了FOR UPDATE也得确认锁住了正确记录
READ COMMITTED 和 REPEATABLE READ 对订单幂等的影响
默认的 REPEATABLE READ 在某些场景下会让同一事务内多次读取看到旧值，掩盖并发问题；而 READ COMMITTED 虽然读最新，但幻读风险需额外处理。
- 订单创建时若需校验“用户今日下单数 REPEATABLE READ 下，事务内重复查询始终返回第一次的结果，无法感知其他事务刚插入的订单
- 解决方法：改用
SELECT ... FOR UPDATE锁住用户维度聚合行（如在user_daily_order表中预占位），或直接在INSERT时用唯一约束（如联合索引(user_id, date)+CHECK或应用层限流） - 不要依赖事务隔离级别替代业务逻辑校验——它只是辅助，不是兜底
最常被忽略的点：事务边界经常被 ORM 的懒加载、日志记录、缓存更新等副作用意外切出。一个 COMMIT 前的 cache.set() 失败，可能让数据库已提交但缓存不一致，这已经超出事务能力范围了。
