由 dawei 移动H5页面常需与后端数据库交互，比如用户抽奖、订单提交、积分扣减等操作，一旦出错极易引发数据不一致。MySQL事务正是保障这类关键操作原子性与一致性的核心机制。
事务本质是一组SQL语句的执行单元，满足ACID特性：原子性（全部成功或全部回滚）、一致性（数据始终满足业务约束）、隔离性（并发操作互不干扰）、持久性（提交后结果永久保存）。H5后台若用PHP、Node.js或Java连接MySQL，都需显式开启事务控制。
实战中，以“用户下单扣库存”为例：先检查商品库存是否充足，再生成订单，最后扣减库存。三步必须绑定在同一个事务内。若库存校验通过但订单插入失败，未回滚会导致超卖；若订单成功而库存未扣，则出现“有单无货”。正确做法是BEGIN开启事务，所有SQL执行后根据业务逻辑判断——成功则COMMIT，任一环节异常则ROLLBACK。
注意事务隔离级别对H5场景的影响。默认REPEATABLE READ可防止脏读与不可重复读，但可能产生幻读；高并发抢购场景下，若仅用SELECT判断库存，仍可能出现超卖。此时应配合SELECT … FOR UPDATE加行锁，确保库存校验与更新过程不可被并发干扰。
自动提交（autocommit）必须关闭。MySQL默认开启autocommit，每条SQL立即生效，事务形同虚设。PHP中可用mysqli->autocommit(FALSE)，Node.js的mysql2库需显式调用connection.beginTransaction()，否则BEGIN语句将被忽略。
错误处理不可省略。网络超时、数据库连接中断、唯一键冲突等都可能导致事务异常。务必在catch块中执行ROLLBACK，并记录日志，避免连接泄露或事务长期挂起。H5接口返回前，需明确告知前端操作结果，而非静默失败。
小心隐式提交。DDL语句（如CREATE、ALTER）、LOCK TABLES、部分管理命令会强制提交当前事务。开发时避免在事务中混用建表或加锁操作，否则事务提前结束，后续SQL将脱离事务保护。
建议图AI生成，仅供参考
事务不是银弹。长事务会占用连接与锁资源，拖慢H5接口响应。应精简事务内SQL数量，只包裹真正需要一致性的操作。高频写入场景可考虑最终一致性+补偿机制，而非强事务依赖。