由 dawei MySQL事务不仅是ACID特性的实现载体，更是保障数据一致性的核心机制。理解事务的底层行为，才能在复杂业务场景中精准控制执行流程。
事务隔离级别直接影响并发行为与性能表现。READ UNCOMMITTED允许脏读，极少使用；READ COMMITTED避免脏读但可能不可重复读；REPEATABLE READ（MySQL默认）通过MVCC与间隙锁解决幻读问题；SERIALIZABLE则强制串行化，开销最大。选择需权衡一致性需求与吞吐压力，而非盲目追求高隔离。
SAVEPOINT是细粒度回滚的关键。在长事务中设置多个保存点，可局部回退而不影响整体流程。例如插入10条记录时第7条失败，只需ROLLBACK TO sp7，后续语句仍可继续执行，避免重跑全部逻辑。
AI绘图结果，仅供参考
隐式提交常被忽视：DDL语句（如ALTER TABLE）、LOCK TABLES、甚至部分SET命令会自动提交当前事务。运维中若在事务内执行ALTER，将导致前序DML意外生效，引发数据不一致。应严格审查SQL类型，必要时拆分操作或使用显式事务包裹。
锁等待与死锁并非异常，而是并发常态。通过INFORMATION_SCHEMA.INNODB_TRX和INNODB_LOCK_WAITS表可实时定位阻塞源头；配合innodb_print_all_deadlocks=ON开启死锁日志，结合应用层重试机制（如指数退避）提升容错能力。
事务超时需主动管控。wait_timeout控制空闲连接，而innodb_lock_wait_timeout限制锁等待时长（默认50秒）。对于长时间运行的报表类事务，应单独调整该参数，并配合应用层设置查询超时，防止长事务拖垮系统资源。
运维中建议定期审计长事务：SELECT FROM information_schema.innodb_trx WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60; 超过一分钟的活跃事务值得排查——可能是未提交、客户端断连未释放，或应用逻辑缺陷所致。
事务的本质是状态机，每一次BEGIN、COMMIT或ROLLBACK都在切换上下文。精准控制不依赖魔法配置，而源于对存储引擎行为、SQL语义及业务边界的持续理解。把事务当作可观察、可干预、可度量的操作单元，才是稳健运维的起点。