InnoDB如何实现事务特性

文章目录

1.实现原子性
2.实现持久性
3.实现隔离性
4.实现一致性

先介绍一下事务的四大特性（ACID）

原子性( A )： 事务是最小的工作单元，不可再分，事务中的操作要么都发生，要么都不发生。

一致性( C )： 事务前后数据的完整性必须保持一致。

隔离性 ( I )： 事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。

持久性( D )： 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

那么数据库是如何保证事务的这四个特性的呢？

1.实现原子性

使用 undo log
原子性要求我们事务当中的操作必须同时成功或同时失败，如果事务中的一些操作执行失败了，那么之前执行成功的操作就要进行回滚。InnoDB实现回滚机制靠的就是undo log ，当事务对数据库进行修改时，InnoDB会生成对应的日志，如果事务执行失败需要进行回滚的时候，就可以利用记录的日志信息进行回滚操作。undo log记录的是逻辑日志，它记录的是sql相关的信息，当回滚的时候InnoDB会根据日志内容进行相反的操作。例如日志当中记录的是Insert操作，回滚的时候都会进行一个update操作。

2.实现持久性

使用 redo log
InnoDB这个存储引擎的数据是放在磁盘当中的，当我们进行IO操作的时候是非常慢的，于是InnoDB提供了 Buffer Pool（缓存） Buffer Pool当中存了磁盘中的部分数据页的映射。当进行读操作的时候会首先去Buffer Pool当中读取，若没有找到再去磁盘读取，读取完之后放入Buffer Pool中。当进行写操作的时候首先写入Buffer Pool当中去，BUffer Pool会定期把数据刷新到磁盘当中去（刷脏操作）。

目前来看一切正常，使用Buffer Pool解决了效率问题，但是也引入了新的问题，如果Mysql宕机了，并且Buffer Pool 当中的数据还没有刷新到磁盘当中去，就会导致数据的丢失。

此时，我们的主角 redo log登场，redo log 采用的是WAL（write ahead logging 预写式日志），当输入进行修改操作之后，会先把这条修改操作保存到 redo log 当中去（磁盘中），然后再更新Buffer Pool当中的数据，保证了数据不会丢失

此时可能大家会有这样的疑问：为什么要多使用一个redo log日志呢，每次修改完直接刷到磁盘中不行吗？可以是可以，但是成本太高了，写入redo log 比刷脏快很多！原因有以下两点：

刷脏是随机IO，每次要修改的地方都不一样，redo log是追加操作，是顺序IO
刷脏是以数据页为单位的，一个数据页大小为16KB，redo log只需要写入一行或多行真正需要的操作就可以了

3.实现隔离性

锁机制（同时写）//明天更新
mvcc（一读一写）//明天更

4.实现一致性

保证原子性，持久性和隔离性
数据库本身提供保证，例如字符串长度不能超过列的限制
应用层面进行保证