事务隔离以及锁

该文章是根据架构师之路公众号文章以及部分书籍中而成，仅做笔记用。

事务的特性（ACID）

• Atomicity原子性，对一个事务里的操作，要么全完成，要么全不完成
• Consistent一致性，在事务开始和完成时，数据必须保持一致状态。
• Isolation隔离性，事务之间互不影响，相互隔离。
• Durable持久性，数据修改的永久性。

InnoDB的事务原理

多版本并发控制，MVCC就是通过“读取旧版本数据”来降低并发事务的锁冲突，提高任务的并发度。
MVCC底层通过了redo和undo日志来保证InnoDB事务的ACID特性。
其中：

• redo日志保证已提交事务的ACID特性，设计思路是，通过顺序写替代随机写，提高并发；
• undo日志用来回滚未提交的事务，它存储在回滚段里；

redo Log

• redo Log 有固定的大小，它采用了循环写的机制
• 它维持了两个指针，write pos （当前所在的位置） checkpoint（最后未写入磁盘的数据位置），它们中间的就是空白部分

redolog的写入策略

• redo Log的写入分为两个阶段 prepare、commit 防止数据库crash导致的数据不一致现象。
• 在事务的进行过程中，redo日志会先保存到redo log buffer中，当事务commit后再写入redoLog文件中。
• InnoDB有一个后台线程，每隔一秒就会把redo log buffer中的日志，调用write写到文件系统的page cache，然后调用fsync持久化到磁盘
• 当redo log buffer占用的空间达到innodo_log_buffer_size一半的时候，后台线程会自动写盘。
• 当并行的事务提交时，会顺带将这个事务的redo log buffer持久化到磁盘。
  innodb_flush_log_at_trx_commit控制着redo log的写入策略
  1.设置为0的时候，表示每次事务提交都只是把redolog留在redo log buffer中；
  2.设置为1的时候，表示每次事务提交都将redo log直接持久化到磁盘；
  3.设置为2的时候，表示每次事务提交时都只是把redo log写到page cache。

undo Log

• 每一个事务都有自己的唯一一个事务ID（trx ID）
• 每行数据的版本都会持有一个更新它的事务的id

binlog

• binlog是逻辑日志，记录了语句的原始逻辑，可以追加写入。
• sync_binlog
• binlog有三种格式
  • statement 直接记录SQL原文，可能造成主备不一致
  • row 记录的是真实操作的行以及其数据
  • mixed 判断SQL是否会导致主备不一致，如果是使用row，不会使用statement

binlog的写入机制

• 事务执行过程中，先把日志写到 binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。

     一个事务的`binlog`是不能被拆开的。
  

• 系统给binlog cache分配了一片内存，每个线程一个，参数binlog_cache_size控制了单个线程内binlog cache所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。

• 事务提交的时候，执行器把binlog cache里的完整事务写入到binlog中，并清空binlog cache。

• binlog cache 会先写入到文件系统的page cache（write），然后将数据持久化到磁盘（fsync）。

    write和fsync的时机，是由参数`sync_binlog`控制的：
    1.sync_binlog=0的时候，表示每次提交事务都只write，不fsync；
    2.sync_binlog=1的时候，表示每次提交事务都会执行fsync；
    3.sync_binlog=N的时候，表示每次提交事务都write，但积累N个事务后才fsync。
  

快照读：读取回滚段中的数据，也就是历史数据的快照，这些数据是不会被修改的。

并发事务的问题

脏读

读到了未提交事务操作的记录，例子如下：

-- 事务1，注意该事务没有提交
insert into table values('a')
-- 事务2，如果这是读取到了事务1中的记录，就是脏读。
select * from table

不可重复读

一个事务内相同的查询，得到了不同的结果，例子如下

--事务1先执行select,得到结果value = "old"
select * from table where id =  1
--事务2执行之后直接提交
update table set value = "new" where id = 1;
commit;
--事务1再次执行select，得到结果value = "new"
select * from table where id =  1

幻读

一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。例子如下：

--事务1先执行，查询到了0条数据
select * from table where id>3;
--事务2执行并且提交
insert into table values(4, "test");
commit;
--事务1再执行insert，发生了错误
insert into t values(4, "real");

事务隔离级别

读未提交（Read Uncommitted）

在这种隔离级别下，select语句是不加锁的，在这种隔离级别下以上三种问题都会出现。
但是它是并发最高的。

读提交（Read Committed）

• 普通的读是快照读，总是能读到最新的行数据快照（已提交事务写入的）
• 加锁的select，update，delete等语句，除了在外键约束检查以及重复键检查时会封锁区间，其他时刻都只使用记录锁
• 因此此时其他事务的插入仍然可以执行，还会出现幻读和不可重复读

可重复读（Repeated Read）

• 普通的select使用快照读，某个事务首次read记录的时间为T，未来不会读取到T时间之后已提交事务写入的记录，以保证连续相同的read读到相同的结果集

• 加锁的select，update，delete等语句，它们的锁，依赖于它们是否在唯一索引上使用了唯一的查询条件，或者范围查询条件：

    在唯一索引上使用唯一的查询条件，会使用记录锁，而不会封锁记录之间的间隔，即不会使用间隙锁与临键锁。
    范围查询条件，会使用间隙锁与临键锁，锁住索引记录之间的范围，避免范围间插入记录，以及避免产生脏读和不可重复读
  

串行化（Serialiable）

所有的select语句都会被隐式的转化为select ... in share mode，这意味着：

如果有未提交的事务正在修改某些行，所有读取这些行的select都会被阻塞住。

这种隔离级别下，所有的问题都不会出现，但是并发性最差。

锁

加锁规则

在RR级别下的加锁规则

• 加锁的基本单位为临键锁，前开后闭区间

• 查找过程中访问到的对象才会加锁

• 索引上的等值查询，给唯一索引加锁的时候，临键锁会退化为行锁

• 索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，临键锁退化成间隙锁

• 唯一索引上的范围查询会访问到不满足条件的第一个值为止。

    lock in share mode 只锁覆盖索引
    for update 会给主键索引上满足条件的行加上行锁
  

全局锁

• Flush tables with read lock，使用后整个数据库处于只读状态。
• 可以使用mysqldump使用参数-single-transaction参数，开启一个事务进行数据的备份。

表锁

• lock tables ... read/write除了限制别的线程的读写，也会限制本线程接下来的操作。加了读锁，本线程也只能读，加了写锁，本线程可以读写。
• MDL锁，修改表结构是会自动的上一个MDL写锁，正常增删改查会添加MDL读锁。

自增锁

自增锁是专门针对事务插入AUTO_INCREMENT类型的列，如果一个事务正在往表中插入记录，所有其他事务的插入必须等待，以便第一个事务插入的行是连续的主键值。

共享/排它锁

• 当事务拿到某一行记录的共享锁，才可以读取这一行，多个事务可以拿到一把共享锁（读与读可以并行）
• 当事务拿到某一行记录的排它锁，才可以修改和删除行，只有一个事务可以拿到排它锁，（写写/读写必须互斥）

意向锁

意向锁：未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向，它是表级别的锁，分为以下两种：

• 意向共享锁：事务如果想获得某些行的共享锁，必须先获得意向共享锁
• 意向排它锁：事务如果想获得某些行的排它锁，必须先获得意向排它锁
  例子如下：

-- 要设计IS锁
select ... lock in share mode
-- 要设计IX锁
select ... for update

意向锁之间并不相互互斥，而是可以并行。

插入意向锁

插入意向锁，是间隙锁的一种（所以，也是实施在索引上的），它是专门针对insert操作的。
多个事务，在同一个索引同一个范围区间插入记录时，如果插入的位置不冲突，不会阻塞彼此

记录锁

封锁某一条的索引记录

--它会在id为1的索引记录上加锁，以阻止其他事务插入，更新，删除id=1这一行
SELECT * FROM table where id = 1 for update

间隙锁

封锁索引记录中的间隔，或者第一条索引记录之前的范围，又或者最后一条索引记录之后的范围。

死锁

死锁的解除策略

1. 进行等待，直到超时，通过参数innodb_lock_wait_timeout控制超时时间
2. 发起死锁检测，主动回滚死锁链条中的某一个事务，让其他事务得以继续进行。通过参数innodb_deadlock_detect进行控制