由 dawei MySQL事务是保障数据一致性的核心机制，但很多开发者仅停留在BEGIN、COMMIT、ROLLBACK的初级用法上，忽略隔离级别、保存点、隐式提交等关键控制细节。
2026AI生成图像,仅供参考
默认的AUTOCOMMIT开启状态下，每条DML语句都自动构成独立事务。若需多语句协同，必须显式执行START TRANSACTION或BEGIN，并在逻辑完成后主动COMMIT；否则异常中断将导致未提交变更全部丢失。
四种隔离级别直接影响并发行为：READ UNCOMMITTED可能读到脏数据；READ COMMITTED避免脏读但存在不可重复读；REPEATABLE READ（MySQL默认）解决不可重复读，但仍可能出现幻读；SERIALIZABLE则完全串行化，以性能为代价换取最强一致性。
保存点（SAVEPOINT）让事务内部具备分段回滚能力。例如转账场景中，先扣减A账户后设SAVEPOINT sp1，再向B账户入账失败时，可执行ROLLBACK TO sp1，仅撤销后半部分操作，保留A账户已扣减状态，便于重试或人工干预。
需警惕隐式提交陷阱：执行DDL（如CREATE、ALTER）、LOCK TABLES、SET AUTOCOMMIT=1等语句会强制提交当前事务。即便在事务块内调用，也会提前终结上下文，导致后续ROLLBACK失效。
正确诊断事务状态可用SELECT @@autocommit、SELECT @@transaction_isolation；监控活跃事务则通过SELECT FROM information_schema.INNODB_TRX，查看trx_state、trx_started等字段，及时发现长事务阻塞问题。
实战建议：业务代码中优先使用编程语言的事务管理器（如Spring @Transactional），而非裸SQL手动控制；高并发写场景下慎用SERIALIZABLE，改用SELECT … FOR UPDATE配合应用层逻辑补偿；所有事务操作务必设置超时（innodb_lock_wait_timeout），防止死锁雪崩。