• 原子性：通过undolog日志文件实现
• 持久性：通过redo log实现
• 隔离性：通过锁和mvcc机制实现
• 一致性：通过上面三个实现

• 加锁会降低数据库读写效率
• 当前读：总是读取最新的数据
  • 读锁（共享锁）：select…lock in share mode
  • 写锁（排它锁）：select…for update、update、insert、delete
• 快照读：读取历史版本的一个记录

• 事务2修改zhangsan为lisi，首先把zhangsan这个行记录添加排他锁，然后把zhangsna此时的行状态写入undolog，最后修改lisi的最近操作事务id与回滚指针
• 
• undolog内容：事务id（单调递增），行id，回滚指针

• 当不同事务对同一记录做修改时，会导致该行记录的undolog形成一个线性表

• 现在有了事务4，那么事务4读取的是哪个版本的数据？一定有对应规则，规则是什么=》隔离级别。

隔离性：

• readview：事务快照读时，产生的视图

• 

• 假如4个事务都操作相同的记录，事务2能读到事务4修改的记录吗？ 能

•   事务2下的开启改为开启并快照读

• 判断原则，可见性算法（判断为可提交则可读）

  

• 所以上面就是判断事务2在读快照时，事务4是否已提交。已提交则可读，未提交则不可读。（注意是读快照时）=》这就是读已提交RC

• 为什么RR，可重复读看不到？

  • 和RC相比，readview生成的时机不同，因为就是把最近事务操作id和readview的值进行对比

  • 

  • trx_list 变成了 1234了，4在里面了，判断为事务4未提交。

  • RR级别下，事务2永远读的是第一次的快照吗？ 不是

    • 如果事务2 进行update操作（当前读），快照会更新（会找更新就会引起RC级别的幻读）

    • RR要解决幻读，需要借助间隙锁（锁一段范围），如select... for update，其他事务插入更新就会阻塞。（那自己不是还可以更新 readview）

    • 总结：readview会更新就可能会幻读。

持久性：

• 先写日志，再写数据 ：比如我们更一条数据

  • 数据从磁盘找到这条数据（很慢，随机读），加载到内存，更新后写入磁盘

  • 万一写入磁盘错误或者数据丢失，怎么恢复呢？

  • 日志是以追加的形式进行读写（顺序读写）的，如果我们先把这条日志写入redolog，就不怕数据丢失了

• 二阶段提交：

  • mysql本来就有个二进制日志文件binlog ，innodb这个插件引擎（undolog，redolog）的redolog必须和binlog保持一致
  • 为什么会有prepare状态：
  • 
  • 保证日志文件一致：如果再binlog前断电，日志文件不一致，回滚；在binlog下面断点，没事，把prepare改成commit就行。。。理解不太深