为什么需要事务？
这里用一个不恰当的比喻，我认为因为数据库要像真实的物理世界一样，需要“量子化”。
事务的四大特性ACID（A:atomicity:原子性）（C:consistency:一致性）（I:isolation:隔离性）（D:durability:持久性）。体现量子化的就是 A 与 C 属性。其中，A本质上就是一组SQL语句的整体执行状态：要么全部成功，要么全部失败，不允许存在中间状态。为什么不能执行一半就结束呢？从技术角度看当然可以，但是跳出技术就会发现很多违反逻辑的地方。经典的例子就是：为什么我钱转出去了，对方没有收到~ 只要你亲身经历一次没收到钱的事情，你会觉得A特性竟然如此可爱。
从SQL角度看有“量子化”，从数据库整体状态看也要有“量子化”，这就是C特性。如果我钱转出去的SQL执行了，你钱增多的SQL还没执行，数据库崩溃。那这个就是“中间状态”，而这个状态是不能允许存在的，是不是像极了电子的轨道跃迁？O(∩_∩)O状态与状态之间只能突变，不能连续。
MySQL用了什么手段？
理念讲起来容易理解，而实际做出来符合要求的系统就是另一回事了。借用大神的一句话：“除非系统通过严格的ACID测试，否则空谈事务的概念是不够的。”MySQL实现ACID细节很多，但总而总的说，其实就是靠日志。A C I 靠的是undo日志，D靠的是redo和binlog日志。
无论是执行语句失败或系统崩溃恢复而产生的回滚，还是MVCC，亦或是隔离级别，本质上都是存一份老数据，然后根据不同的时机“按需取用”。MySQL系统通过undo日志完成这个任务。
而持久化D的问题，大家听说过两个词：日志先行，二阶段提交。保障了你提交事务之后，只要看到成功消息，代表数据库永久存储住了。存到哪里？最初是在日志里！redo日志binlog日志里。
简单感想谈到这，后续有感谢再发出来~
