|
先介绍一下事务的四大特性（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.实现一致性
- 保证原子性，持久性和隔离性
- 数据库本身提供保证，例如字符串长度不能超过列的限制
- 应用层面进行保证
|