一文带你看通透，MySQL事务ACID四大特性实现原理

　　#头条创作挑战赛#
　　hello，大家好，我是张张，「架构精进之路」公号作者。
　　说起MySQL事务处理的四大特性，相信大家都可以张口就来：ACID！
　　那 MySQL是如何实现ACID的？每种特性的原理又是如何实现的？
　　今天，本文笔者主要探讨MYSQL InnoDB引擎下的ACID实现原理，对事务、锁以及隔离级别等内容统一进行回顾一下。
　　1、ACID特性原子性（Atomicity）
　　单个事务，为一个不可分割的最小工作单元，整个事务中的所有操作要么全部commit成功，要么全部失败rollback，对于一个事务来说，不可能只执行其中的一部分SQL操作，这就是事务的原子性。 一致性(Consistency)
　　数据库总是从一个一致性的状态转换到另外一个一致性的状态。在前面的例子中， 一致性确保了，即使在执行第三、四条语句之间时系统崩溃，信用卡账户也不会损 失100块，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中，保证数据一致性。 隔离性(Isolation)
　　通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见（隔离）的。避免多个事务并发执行的时候不会互相干扰。 持久性（Durability）
　　一旦事务提交，则其所做的修改就会永久保存到数据库中，之后的其他操作或故障都不会对事务的结果产生影响。
　　2、ACID 具体实现原子性：通过undolog来实现。 持久性：通过 binlog、redolog 来实现。 隔离性：通过（读写锁+MVCC）来实现。 一致性：MySQL通过原子性、持久性、隔离性最终实现数据一致性。
　　对MySQL来说，逻辑备份日志（binlog）、重做日志（redolog）、回滚日志（undolog）、锁技术 + MVCC就是MySQL实现事务的基础。 2.1 原子性原理
　　事务通常是以BEGIN TRANSACTION 开始，以 COMMIT 或 ROLLBACK 结束。 COMMIT 表示提交，即提交事务的所有操作并持久化到数据库中。 ROLLBACK表示回滚，即在事务中运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库所有已完成的操作全部撤销，回滚到事务开始时的状态，这里的操作指对数据库的更新操作（查询操作忽略）。这时候需要用到 undolog 来进行回滚。
　　undolog：
　　每条数据变更（INSERT/UPDATE/DELETE/REPLACE）等操作都会生成一条undolog记录，在SQL执行前先于数据持久化到磁盘。 insert语句，回滚时会执行 delete；
　　delete语句，回滚时会执行insert；
　　update语句，回滚时便执行相反的update，把数据改回来。
　　当事务需要回滚时，MySQL会根据回滚日志对事务中已执行的SQL做逆向操作，比如 DELETE 一行数据的逆向操作就是再把这行数据 INSERT回去，其他操作同理。
　　undolog记录事务开始前老版本数据，用于实现回滚，保证原子性，实现MVCC，会将数据修改前的旧版本保存在undolog，然后行记录有个隐藏字段回滚指针指向老版本。 2.2 持久性原理
　　我们知道，MySQL表数据是持久化到磁盘中的，但如果所有操作都去操作磁盘，等并发上来了，那处理效率无法保证，因此引入了缓冲池(Buffer Pool)的概念，Buffer Pool 中包含了磁盘中部分数据页的映射，可以当做缓存来用；这样当修改表数据时，我们把操作记录先写到Buffer Pool中，并标记事务已完成，等MySQL空闲时，再把更新操作持久化到磁盘里，从而大大缓解了MySQL并发压力。
　　MYSQL的持久性便是由redo log来保证。
　　redo log
　　是一种物理日志， 作用：会记录事务开启后对数据做的修改，crash-safe。 它类似于一个卸货的小推车，我们若是每卸一件物品就拿着去入库，那岂不是特浪费时间，若有一个小推车，我们将货物首先存放在小推车，当推车满了再往库里存，可以大大提升效率。
　　其实就是MySQL里经常说到的WAL技术，WAL的全称是 Write-Ahead Logging ，它的关键点就是先写日志，再写磁盘，也就是先装小推车，等不忙的时候再装库。
　　特性：空间一定，写完后会循环写  ，有两个指针write pos指向当前记录位置，checkpoint指向将擦除的位置，redolog相当于是个取货小车，货物太多时来不及一件一件入库太慢了这样，就先将货物放入小车，等到货物不多或则小车满了或则店里空闲时再将小车货物送到库房。用于crash-safe  ，数据库异常断电等情况可用redo log恢复。
　　以下只作了解：
　　写入流程：先写redo log buffer，然后wite到文件系统的page cache，此时并没有持久化，然后fsync持久化到磁盘
　　写入策略：根据innodb_flush_log_at_trx_commit参数控制（innodb以事务的什么提交方式刷新日志） 0——>事务提交时只把redo log留在redo log buffer
　　1——>将redo log直接持久化到磁盘（所以有个双＂1＂配置，后面会讲）
　　2——>只是把redo log写到page cache
　　2.3 隔离性原理
　　MYSQL有四种隔离级别，用来解决存在的并发问题：脏读、幻读、不可重复读。
　　那么不同隔离级别，隔离性是怎样实现的呢？
　　一句话：锁+MVCC。
　　锁表锁：读锁（不会阻塞其他线程的读操作，阻塞写操作）；写锁（读写操作都阻塞） 行锁：需要的时候加上，并不是马上释放，等事务提交才释放，两阶段锁协议 锁的类型
　　间隙锁-gap lock ：锁定区间范围，防止幻读，左开右开，只在可重复读隔离级别下生效—|—为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生
　　记录锁-record Lock ：锁定行记录，索的索引，索引失效，为表锁
　　临键锁-next-key Lock ：record lock+gap lock 左开右闭 （解决幻读 ）  锁的模式
　　select .... for update （持有写锁，别的不可加读锁，也不可加写锁）
　　select .... lock in share mode（持有读锁，别的可以再加读锁，不可加写锁）
　　共享锁-读锁-S锁
　　排他锁-写锁-X锁
　　意向锁：读意向锁+写意向锁
　　自增锁  全局锁：全库逻辑备份 死锁：两个或多个事务在同一资源上相互占用，并请求加锁时，造成相互等待，无限阻塞
　　MVCC：实现多版本并发控制，实现原理：使用版本链+Read View
　　读已提交和可重复读实现原理就是MVCC Read View不同的生成时机。可重复读只在事务开始时生成一个Read View，之后都用的这个；读已提交每次执行前都会生成Read View。
　　2.4 一致性原理
　　一致性是事务追求的最终目标，前文所述的原子性、持久性和隔离性，其实都是为了保证数据库状态的一致性，数据库中的增删改操作，使数据库不断从一个一致性的状态转移到另一个一致性的状态。
　　总结
　　事务该回滚的回滚，该提交的提交，提交后该持久化磁盘的持久化磁盘，该写缓冲池的写缓冲池+写日志。
　　对于数据可见性，通过四种隔离级别进行控制，使得库表中的有效数据范围可控，保证业务数据的正确性的前提下，进而提高并发程度，支撑服务高QPS的稳定运行，保证数据的一致性，这就是咱们说个不停的MySQL数据库事务ACID四大特性。
　　希望今天的讲解对大家有所帮助，谢谢！
　　Thanks for reading!
　　作者：架构精进之路，十年研发风雨路，大厂架构师，CSDN 博客专家，专注架构技术沉淀学习及分享，职业与认知升级，坚持分享接地气儿的干货文章，期待与你一起成长。
　　关注并私信我回复＂01＂，送你一份程序员成长进阶大礼包，欢迎勾搭。