由 dawei 事务是MySQL数据一致性的核心保障机制，架构师必须理解其底层逻辑而不仅是语法。ACID四大特性中，“原子性”依赖undo log回滚，“一致性”由应用逻辑与约束共同维系，“隔离性”通过锁和MVCC实现，“持久性”则依托redo log刷盘——这四者并非孤立，而是协同工作的有机整体。
隔离级别直接影响并发性能与数据可见性。READ UNCOMMITTED极少使用；READ COMMITTED（RC）下每次SELECT都生成新快照，可避免脏读但存在不可重复读；REPEATABLE READ（RR）是InnoDB默认级别，基于MVCC+间隙锁（Gap Lock）解决幻读，但需警惕长事务引发的undo log膨胀与主从延迟；SERIALIZABLE强制加读写锁，实际场景应避免。
AI生成内容图，仅供参考
显式事务控制语句看似简单，却暗藏风险：START TRANSACTION启动后若未配对COMMIT或ROLLBACK，连接空闲超时将自动回滚，但业务逻辑可能已误判成功；SAVEPOINT仅在当前事务内有效，嵌套调用易造成释放错位；更关键的是，非事务引擎（如MyISAM）表混入事务中，DML操作不参与回滚，极易引发数据不一致。
架构设计中需规避隐式事务陷阱：autocommit=1时单条DML自动提交，但DDL（如ALTER TABLE）会强制触发隐式提交，导致前序DML不可回滚；批量更新若未分批次控制，可能持锁过久、阻塞读写，甚至触发锁升级。建议用SELECT … FOR UPDATE加锁前先确认索引覆盖，避免全表扫描升为表级锁。
监控与诊断同样关键。通过INFORMATION_SCHEMA.INNODB_TRX观察事务状态、运行时长及持有锁；结合performance_schema.data_locks分析锁冲突根因；慢日志中标记“Rows_examined”突增，常暗示事务内低效查询拖累整体。真正的高可用架构，始于对每个事务生命周期的清醒认知。