上图中1号事务首先执行了一个当前读的select语句,这个语句会在 id > 0的所有间隔加上Gap锁,接下来2号事务在id = 3处执行插入时系统就会返回Lock wait timeout execcded的异常。当然,其他事务可以在id <= 0的条件下插入成功,这没问题。
Serializable (技术解读:S锁(读)+X锁(写))
Serialization隔离级别是最严格的隔离级别,所有读请求都会加上读锁,不分快照读和当前读,所有写会加上写锁。当然,这种隔离级别的性能因为锁开销而相对最差。
MySQL事务持久性保证
MySQL事务持久化策略和HBase基本相同,但是涉及的组件相对比较多,主要有doublewrite、redo log以及binlog:
1. MySQL数据持久化(DoubleWrite)
实际上MySQL的真实数据写入分为两次写入,一次写入到一个称为DoubleWrite的地方,写成功之后再真实写入数据所在磁盘。为什么要写两次?这是因为MySQL数据页大小与磁盘一次原子操作大小不一致,有可能会出现部分写入的情况,比如默认InnoDB数据页大小为16K,而磁盘一次原子写入大小为512字节(扇区大小),这样一个数据页写入需要多次IO,这样一旦中间发生异常就会出现数据丢失。另外需要注意的是DoubleWrite性能并不会影响太大,因为写入DoubleWrite是顺序写入,对性能影响来说不是很大。
2. redolog持久化策略(innodb_flush_log_at_trx_commit)
redolog是InnoDB的WAL,数据先写入redolog并落盘,再写入更新到bufferpool。redolog的持久化策略和HBase中hlog的持久化策略一致,默认为1,表示每次事务提交之后log就会持久化到磁盘;该值为0表示每隔1秒钟左右由异步线程持久化到磁盘,这种情况下MySQL发生宕机有可能会丢失部分数据。该值为2表示每次事务提交之后log会flush到操作系统缓冲区,再由操作系统异步flush到磁盘,这种情况下MySQL发生宕机不会丢失数据,但机器宕机有可能会丢失部分数据。
3. binlog持久化策略(sync_binlog)
binlog作为Server层的日志系统,主要以events的形式顺序纪录了数据库的各种操作,同时可以纪录每次操作所花费的时间。在MySQL官方文档上,主要介绍了Binlog的两个最基本核心作用:备份和复制,因此binlog的持久化会一定程度影响数据备份和复制的完整性。和redo持久化策略相同,可取值有0,1,N。默认为0,表示写入操作系统缓冲区,异步flush到磁盘。该值为1表示同步写入磁盘。为N则表示每写N次操作系统缓冲就执行一次刷新操作。
总结一下,本文是数据库事务系列文章的第三篇,核心介绍了MySQL的单机跨行事务模型,其中对隔离性所涉及到的锁技术、MVCC机制进行了比较详细的说明。对事务原子性、持久性等相关特性也进行简单的分析和说明。接着笔者将会带大家一起聊聊分布式事务模型,看看和单机事务模型到底有何区别。
推荐学习:MySQL教程