由 dawei 事务是MySQL保障数据一致性的核心机制，但在实际开发中，常因隔离级别误配、长事务未释放、隐式提交等细节引发“看似正确却悄然出错”的问题。无障碍视角，意味着抛开抽象概念，从开发者每日直面的SQL行为出发，用可观察、可验证的方式理解事务控制。
手动开启事务需显式执行BEGIN或START TRANSACTION；仅靠AUTOCOMMIT=0并不自动启动事务上下文——它只改变后续单条语句的默认提交行为。一旦执行COMMIT或ROLLBACK，当前事务即终结，后续语句将运行在新事务或自动提交模式下，这点极易被忽略。
隔离级别不是越严越好。READ COMMITTED可避免脏读且兼顾并发性能，是大多数业务的合理起点；而SERIALIZABLE虽杜绝所有异常，但会强制行锁升级为范围锁，显著降低吞吐。通过SELECT @@transaction_isolation;可实时确认会话当前级别，避免配置文件与会话设置不一致导致的预期偏差。
SAVEPOINT提供轻量级回滚锚点。例如在批量插入中，某条记录校验失败时，可ROLLBACK TO sp1回退至保存点，而非放弃整个事务。注意：SAVEPOINT不阻断语句执行，也非独立事务，不可跨连接生效。
长事务是隐形杀手。执行SHOW PROCESSLIST可发现State为“Sleep”却Command为“Sleep”的连接，若其trx_state为ACTIVE且time值持续增长，极可能是忘记COMMIT的事务正独占行锁。配合information_schema.INNODB_TRX表查trx_started时间，能准确定位隐患会话。
AI生成图像，仅供参考
•警惕隐式提交陷阱：执行CREATE TABLE、ALTER TABLE、DROP TABLE、GRANT、FLUSH等DDL或管理语句时，MySQL会自动提交当前事务。即便该语句本身失败，前置DML也已不可逆。将这类操作置于事务块内前，务必确认其是否支持回滚——多数DDL不支持。
真正掌握事务，不在于背诵ACID定义，而在于对每条SQL如何影响事务状态形成肌肉记忆。打开general_log、观察binlog事件、定期审计INNODB_TRX，让事务行为可见、可测、可控，才是落地精控的本质。