sql事务通过undo log保障原子性、mvcc与锁协同实现隔离性、redo log确保持久性，一致性则是acid机制与约束共同作用的结果。
SQL事务的实现，核心是靠日志、锁和多版本控制这三样东西协同工作。MySQL的InnoDB引擎就是典型代表——它不用单一样式硬扛全部需求，而是把原子性、一致性、隔离性、持久性拆开，各用最适合的机制来落实。
原子性靠Undo Log回滚
事务不是“执行一半就停”，而是“全有或全无”。这个“全无”怎么做到？靠Undo Log（回滚日志）。
- 每条INSERT/UPDATE/DELETE执行前，InnoDB先记下数据修改前的样子，写进Undo Log；
- 如果事务中途失败，或者显式执行ROLLBACK，系统就按Undo Log把数据一层层还原回去；
- Undo Log还顺带支撑MVCC，让不同事务能读到各自该看到的数据快照。
隔离性靠MVCC + 锁配合
并发事务不互相干扰，不是靠“排队等”，而是靠“各看各的版本+必要时加锁”。
- MVCC对普通SELECT起作用：每个事务启动时生成Read View，结合行记录中的事务ID和Undo Log链，判断该读哪个历史版本；
- 写操作（如UPDATE）仍需加锁：InnoDB默认用行级排他锁，防止其他事务同时改同一行；
- 四种隔离级别本质是Read View生成策略和锁范围的组合：读已提交每次SELECT都新建View；可重复读只在事务首次SELECT时建一次View。
持久性靠Redo Log预写保障
提交（COMMIT）之后数据不能丢，哪怕断电重启也要找得回来——这靠Redo Log（重做日志）。
- 事务提交前，先把变更内容写入Redo Log，并刷盘（fsync）；
- 再把数据页异步刷到磁盘（可以延迟）；
- 崩溃恢复时，MySQL重放Redo Log里已提交但未落盘的修改，确保“已提交=真落地”。
一致性是ACID合力的结果
一致性不是单独某个模块实现的，而是A、I、D共同托住的上层效果，再加上数据库约束和业务逻辑兜底。
- 原子性防止“扣了钱没到账”这类半截操作；
- 隔离性避免脏读、不可重复读破坏中间状态；
- 持久性保证最终结果不会因故障消失；
- 主键、外键、CHECK约束等，在事务提交前强制校验，违反就直接报错回滚。
说到底，事务不是魔法，而是一套精密协作的工程方案：日志管回退与恢复，锁管写冲突，MVCC管读并发，约束管语义正确。理解它们怎么分工，比死记ACID定义更有实际价值。
