ReZero's Utopia.

(转)Mysql Transaction

Word count: 1.4kReading time: 4 min
2020/07/29 Share

MySql Transaction

事务如何保证

  1. 原子性: undo log

    • binlog记载的是update/delete/insert这样的SQL语句,而redo log记载的是物理修改的内容(xxxx页修改了xxx)。即redo log 记录的是数据的物理变化,binlog 记录的是数据的逻辑变化。

    • binlog的作用是复制和恢复而生的。

    • 主从服务器需要保持数据的一致性,通过binlog来同步数据。

    • 如果整个数据库的数据都被删除了,binlog存储着所有的数据变更情况,那么可以通过binlog来对数据进行恢复。而redo log 存储的是物理数据的变更,如果我们内存的数据已经刷到了磁盘了,那redo log
      的数据就无效了。所以redo log不会存储着历史所有数据的变更,文件的内容会被覆盖的

  2. 持久性: redo log

    • redo log事务开始的时候,就开始记录每次的变更信息,而binlog是在事务提交的时候才记录

    • 如果写redo log失败了,那我们就认为这次事务有问题,回滚,不再写binlog。

    • 如果写redo log成功了,写binlog,写binlog写一半了,但失败了怎么办?我们还是会对这次的事务回滚,将无效的binlog给删除(因为binlog会影响从库的数据,所以需要做删除操作)

    • 如果写redo log和binlog都成功了,那这次算是事务才会真正成功。

    • 简单来说:MySQL需要保证redo log和binlog的数据是一致的,如果不一致,那就乱套了。

  3. 两阶段提交

    • 阶段1:InnoDBredo log 写盘,InnoDB 事务进入 prepare 状态

    • 阶段2:binlog 写盘,InooDB 事务进入 commit 状态

    • 每个事务binlog的末尾,会记录一个 XID event,标志着事务是否提交成功,也就是说,恢复过程中,binlog 最后一个 XID event 之后的内容都应该被 purge。

  4. undo_log: 回滚和多版本控制(MVCC)

    • undo log主要存储的也是逻辑日志,比如我们要insert一条数据了,那undo log会记录的一条对应的delete日志。我们要update一条记录时,它会记录一条对应相反的update记录(原子性保证的前提)

    • undo log存储着修改之前的数据,相当于一个前版本,MVCC实现的是读写不阻塞,读的时候只要返回前一个版本的数据就行了。

关于锁

锁协议

  • 无法像应用一样预知用哪些数据,直接锁对应的数据即可,因而数据库提出了两段锁协议
  1. 加锁阶段:在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁(共享锁,其它事务可以继续加共享锁,但不能加排它锁),在进行写操作之前要申请并获得X
    锁(排它锁,其它事务不能再获得任何锁)。加锁不成功,则事务进入等待状态,直到加锁成功才继续执行。
  2. 解锁阶段:当事务释放了一个封锁以后,事务进入解锁阶段,在该阶段只能进行解锁操作不能再进行加锁操作。

加锁方式

  1. 读提交:读不加锁,写加锁

    • 如果一个条件无法通过索引快速过滤,存储引擎层面就会将所有记录加锁后返回,再由MySQL Server层进行过滤

    • 实际改进:在MySQL Server过滤条件,发现不满足后,会调用unlock_row
      方法,把不满足条件的记录释放锁 (违背了二段锁协议的约束)。这样做,保证了最后只会持有满足条件记录上的锁,但是每条记录的加锁操作还是不能省略的。

  2. 不可重复读

    • 悲观锁:事务开启时就锁数据,锁数据期间别的无法修改,自然看到的就一直是对应的数据了,此方法低效且无法处理插入这种幻读的情况。

    • 所以采取了乐观锁 :MVCC 这种模式

MVCC

  • SELECT时,读取创建版本号<=当前事务版本号,删除版本号为空或>当前事务版本号。

  • INSERT时,保存当前事务版本号为行的创建版本号

  • DELETE时,保存当前事务版本号为行的删除版本号

  • UPDATE时,插入一条新纪录,保存当前事务版本号为行创建版本号,同时保存当前事务版本号到原来删除的行

    • Mysql 的 可重复读解决了 幻读的 问题,因为幻读插入的数据版本号高于当前版本,因此不会读到。但这也意味着读的不是最新的数据,因此称为快照读,与之对应的就是锁数据来保持当前版本读,称为当前读。

    • 为了解决当前读中的幻读 问题,MySQL事务使用了Next-Key锁。Next-Key锁是行锁和GAP(间隙锁)的合并。RR级别中,事务A在update后加锁,事务B无法插入新数据,这样事务A在update
      前后读的数据保持一致,避免了幻读。这个锁,就是Gap锁,所谓Gap锁就是按索引字段将修改数据附近的区间进行加锁,进而保证不可插入,但弊端就在于对没有索引的字段会锁全表,而有索引的字段在没有命中数据的情况下,仍然回对该区间加锁

CATALOG
  1. 1. MySql Transaction
    1. 1.1. 事务如何保证
      1. 1.1.1. 关于锁
      2. 1.1.2. 锁协议
      3. 1.1.3. 加锁方式
      4. 1.1.4. MVCC