SQL事务是保障数据可靠的协同体系，通过Undo Log、Redo Log和锁+MVCC实现ACID，需用InnoDB引擎并避免长事务与DDL混用。
SQL事务不是“加个BEGIN再COMMIT”就完事的机制，它背后是一整套保障数据可靠的协同体系。核心在于：事务让多条SQL变成一个不可拆分、可回溯、能抗故障的逻辑单元。
事务怎么开启和结束
MySQL默认是自动提交模式（autocommit=1），每条INSERT/UPDATE/DELETE执行完立刻生效。要手动控制事务，必须先关掉它：
- SET autocommit = 0; —— 会话级关闭，重启后恢复默认
- BEGIN 或 START TRANSACTION —— 显式开启事务边界
- COMMIT —— 持久化所有修改，事务正式结束
- ROLLBACK —— 撤销事务内所有未提交的变更，回到BEGIN前状态
注意：SELECT本身不触发事务，但加上FOR UPDATE或LOCK IN SHARE MODE就会参与锁机制，属于事务上下文。
事务靠什么实现ACID
ACID不是口号，而是由InnoDB底层三大组件分工支撑：
- Undo Log——负责原子性与一致性：记录修改前的旧值，回滚时直接复原；也支撑MVCC快照读
- Redo Log——负责持久性：所有变更先写入顺序日志并刷盘，宕机后靠它重放恢复
- 锁 + MVCC——共同保障隔离性：行锁防并发改同一行，间隙锁防幻读，MVCC让普通SELECT不加锁也能读到一致快照
这三者缺一不可。比如没有Undo Log，ROLLBACK就无从谈起；没有Redo Log，COMMIT后断电等于白提。
隔离级别与常见问题对应关系
MySQL支持四种标准隔离级别，实际使用中重点关注两个：
- READ COMMITTED（RC）：每次SELECT都读最新已提交版本，解决脏读，但可能不可重复读（同一条SELECT执行两次结果不同）
- REPEATABLE READ（RR）：MySQL默认级别，事务启动时创建一致性视图，整个事务期间读取结果固定，配合Next-Key Lock基本防止幻读
脏读、不可重复读、幻读不是理论假设，而是真实并发场景下的数据异常。例如RR下执行SELECT ... FOR UPDATE查某范围，其他事务就不能往该间隙插入新行——这就是临键锁在起作用。
事务使用的几个关键提醒
很多问题出在细节疏忽：
- 只有InnoDB引擎支持完整事务，MyISAM不支持，建表时务必确认
ENGINE=InnoDB - DDL语句（如ALTER TABLE）会隐式提交当前事务，不能回滚
- 长事务会拖慢purge线程、膨胀undo log、阻塞MVCC清理，应尽量缩短执行时间
- 显式事务中避免混合DML与DDL，也不建议在事务里做耗时操作（如调外部API、大文件处理）
基本上就这些。事务机制不复杂，但容易忽略底层依赖和边界情况。用好它，数据库才真正可靠。
