MySQL通过undo log实现事务原子性，确保操作全成功或全回滚。事务修改前数据写入undo log，失败时逆向恢复；未提交时修改隔离，依赖MVCC避免脏读；InnoDB引擎管理日志并支持崩溃恢复；需用BEGIN、COMMIT、ROLLBACK显式控制事务边界。
MySQL事务的原子性确保一个事务中的所有操作要么全部成功执行，要么全部不执行。当事务中任何一个操作失败时，整个事务会回滚到开始前的状态，就像什么都没发生过一样。这种特性是数据库ACID四大特性之一，对数据一致性至关重要。
1. 利用undo log实现回滚
MySQL通过undo log（回滚日志）来保障事务的原子性。当事务执行修改操作（如INSERT、UPDATE、DELETE）时，系统会先将修改前的数据记录写入undo log，保存旧值信息。
- 如果事务提交，undo log中标记该部分日志可被清理
- 如果事务中途失败或主动回滚，MySQL会根据undo log中的记录逆向操作，恢复原始数据
例如：一个事务中更新了某条用户余额记录，undo log会保存更新前的余额数值。一旦事务回滚，系统就能利用这个旧值还原数据。
2. 事务执行过程中的临时状态隔离
在事务未提交前，其对数据的修改不会直接写入主表，而是记录在undo log和内存缓冲区中。其他事务无法看到这些中间状态，这依赖于MVCC（多版本并发控制）机制配合undo log实现。
- 修改操作生成的新版本数据只对当前事务可见
- 其他事务仍能访问旧版本数据，避免脏读
- 只有事务提交后，变更才会持久化并对外可见
3. 原子性与存储引擎的支持
MySQL的原子性依赖支持事务的存储引擎，最常见的是InnoDB。MyISAM等非事务型引擎不提供原子性保障。
- InnoDB自动管理undo log的生成与清理
- 每个DML操作都会对应生成回滚信息
- 崩溃恢复时，InnoDB会检查事务状态并完成回滚或重做
4. 显式控制事务边界
开发者需正确使用事务控制语句，才能发挥MySQL的原子性能力：
- BEGIN / START TRANSACTION：开启事务
- COMMIT：提交事务，所有更改永久生效
- ROLLBACK：回滚事务，撤销所有未提交的更改
在应用代码中应结合异常处理机制，在出错时显式调用ROLLBACK，防止部分执行导致数据不一致。
基本上就这些。MySQL通过undo log机制为核心，配合InnoDB引擎的事务管理和MVCC，完整实现了事务的原子性。只要合理使用事务控制语句，就能有效避免因程序异常或系统故障导致的数据残留问题。
