由 dawei MySQL事务不仅是“BEGIN/COMMIT”这么简单，真正威力在于精准控制执行边界与异常响应。理解隔离级别、保存点与一致性读，才能避免脏写、幻读等隐性问题。
隔离级别直接决定事务间可见性。READ COMMITTED确保只读取已提交数据，避免脏读；REPEATABLE READ（MySQL默认）通过间隙锁+MVCC防止不可重复读与大部分幻读；而SERIALIZABLE强制串行执行，开销大但最安全。切勿盲目设为最高级别——应按业务权衡：电商库存扣减用REPEATABLE READ足够，银行对账则需更严管控。
保存点（SAVEPOINT）让回滚粒度可控。当一个事务含多步操作（如订单创建→扣库存→发通知），可在关键节点设SAVEPOINT sp1；若后续发通知失败，只需ROLLBACK TO sp1，保留前两步结果，而非整个事务作废。这显著提升复合业务的健壮性。
本图基于AI算法，仅供参考
显式锁定需谨慎使用。SELECT … FOR UPDATE在UPDATE前加行级写锁，防止并发覆盖；SELECT … LOCK IN SHARE MODE则允许多读但阻塞写。注意：锁定必须在事务内生效，且仅对索引列有效——全表扫描可能升级为表锁，引发性能雪崩。
MVCC（多版本并发控制）是隐形助手。事务启动时生成一致性视图（read view），此后所有SELECT都基于该快照，无需加锁即可保证可重复读。但UPDATE/DELETE仍会基于最新行版本做判断，因此“幻读”在范围查询中仍可能由新插入记录触发，需配合间隙锁抑制。
错误处理不能依赖应用层兜底。应在存储过程中用DECLARE HANDLER捕获SQLEXCEPTION，配合ROLLBACK和自定义日志，确保异常时状态可追溯。例如转账事务中余额不足时，不仅回滚，还记录失败原因与上下文ID，便于后续审计。
真正的精准控制源于对场景的透彻理解：高并发读多写少？选READ COMMITTED+覆盖索引；强一致性写密集？合理拆分事务+显式锁+超时设置。每一次BEGIN，都应带着明确的隔离目标、预期锁范围与回滚预案。