事务的个性(ACID)
群里有小伙伴面试时,碰到面试官提了个很刁钻的问题:
Mysql为何应用可反复读(Repeatable read)为默认隔离级别???
上面进入正题:
咱们都晓得事务的几种性质 :原子性、一致性、隔离性和持久性 (ACID)
为了维持一致性和隔离性,个别应用加锁这种形式来解决,然而加锁绝对带来的是并发解决能力的升高
而数据库是个高并发的利用,因而对于加锁的解决是事务的精华.
上面咱们来理解一下封闭协定,以及事务在数据库中做了什么
封闭协定（Locking Protocol）
MySQL的锁零碎：shared lock 和 exclusive lock 即共享锁和排他锁，也叫读锁(S)和写锁(X),共享锁和排他锁都属于乐观锁。排他锁又能够能够分为行锁和表锁。
封闭协定（Locking Protocol）: 在应用X锁或S锁对数据加锁时,约定的一些规定.例如何时申请X或S锁,持续时间,何时开释锁等.
一级、二级、三级封闭协定
对封闭形式规定不同的规定，就造成了各种不同的封闭协定,不同的封闭协定，为并发操作的正确性提供不同水平的保障
一级封闭协定
一级封闭协定定义：事务T在批改数据R之前必须先对其加X锁(排他锁)，直到事务完结才开释。事务完结包含失常完结（COMMIT）和非正常完结（ROLLBACK）。
一级封闭协定能够避免失落批改，并保障事务T是可复原的。应用一级封闭协定能够解决失落批改问题。在一级封闭协定中，如果仅仅是读数据不对其进行批改，是不须要加锁的，它不能保障可反复读和不读“脏”数据。
二级封闭协定
二级封闭协定定义：一级封闭协定加上事务T在读取数据R之前必须先对其加S锁(共享锁)，读完后开释S锁。事务的加锁和解锁严格分为两个阶段，第一阶段加锁，第二阶段解锁。
加锁阶段: 在对任何数据进行读操作之前要申请并取得S锁（共享锁，其它事务能够持续加共享锁，但不能加排它锁），在进行写操作之前要申请并取得X锁（排它锁，其它事务不能再取得任何锁）。加锁不胜利，则事务进入期待状态，直到加锁胜利才继续执行。解锁阶段:当事务开释了一个封闭当前，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。
二级封闭协定除避免了失落批改，还能够进一步避免读“脏”数据。但在二级封闭协定中，因为读完数据后开释S锁，所以它不能保障可反复读。
二级封闭的目标是保障并发调度的正确性。就是说，如果事务满足两段锁协定，那么事务的并发调度策略是串行性的。保障事务的并发调度是串行化（串行化很重要，尤其是在数据恢复和备份的时候）
三级封闭协定
三级封闭协定定义：一级封闭协定加上事务T在读取数据R之前必须先对其加S锁(共享锁)，直到事务完结才开释。在一级封闭协定（一级封闭协定：批改之前先加X锁，事务实现开释）的根底上加上S锁，事务完结后开释S锁
三级封闭协定除避免了失落批改和不读“脏”数据外，还进一步避免了不可反复读。
上述三级协定的次要区别在于什么操作须要申请封闭，以及何时开释。
事务四种隔离级别
在数据库操作中，为了无效保障并发读取数据的正确性，提出的事务隔离级别。下面提到的封闭协定 ，也是为了构建这些隔离级别存在的。
| 隔离级别 | 脏读（Dirty Read） | 不可反复读（NonRepeatable Read） | 幻读（Phantom Read） |
|---|---|---|---|
| 未提交读（Read uncommitted） | 可能 | 可能 | 可能 |
| 已提交读（Read committed） | 不可能 | 可能 | 可能 |
| 可反复读（Repeatable read） | 不可能 | 不可能 | 可能 |
| 可串行化（Serializable ） | 不可能 | 不可能 | 不可能 |
对于事务并发拜访会产生的问题,以及各隔离级别的具体介绍在我的上一篇文章
一文搞懂事务
为什么是RR
个别的DBMS零碎，默认都会应用读提交（Read-Comitted，RC）作为默认隔离级别，如Oracle、SQL Server等，而MySQL却应用可反复读（Read-Repeatable，RR）。要晓得，越高的隔离级别，能解决的数据一致性问题越多，实践上性能的损耗更大，且并发性越低。隔离级别顺次为: SERIALIZABLE > RR > RC > RU
咱们能够通过以下语句设置和获取数据库的隔离级别:
查看零碎的隔离级别:
mysql> select @@global.tx_isolation isolation;+-----------------+| isolation |+-----------------+| REPEATABLE-READ |+-----------------+1 row in set, 1 warning (0.00 sec)查看以后会话的 隔离级别:
mysql> select @@tx_isolation;+----------------+| @@tx_isolation |+----------------+| READ-COMMITTED |+----------------+1 row in set, 1 warning (0.00 sec)设置会话的隔离级别，隔离级别由低到高设置顺次为:
set session transacton isolation level read uncommitted;set session transacton isolation level read committed;set session transacton isolation level repeatable read;set session transacton isolation level serializable;设置以后零碎的隔离级别，隔离级别由低到高设置顺次为:
set global transacton isolation level read uncommitted;set global transacton isolation level read committed;set global transacton isolation level repeatable read;set global transacton isolation level serializable;可反复读(Repeated Read)：可反复读。基于锁机制并发管制的DBMS须要对选定对象的读锁(read locks)和写锁(write locks)始终放弃到事务完结，但不要求“范畴锁(range-locks)”，因而可能会产生“幻影读(phantom reads)”
在该事务级别下，保障同一个事务从开始到完结获取到的数据统一。是Mysql的默认事务级别。
上面咱们先来思考2个问题
- 在读已提交(Read Commited)级别下，呈现不可反复读问题怎么办?须要解决么？
不必解决，这个问题是能够承受的！毕竟你数据都曾经提交了，读出来自身就没有太大问题！Oracle ,SqlServer 默认隔离级别就是RC，咱们也没有更改过它的默认隔离级别.
- 在Oracle，SqlServer中都是抉择读已提交(Read Commited)作为默认的隔离级别，为什么Mysql不抉择读已提交(Read Commited)作为默认隔离级别，而抉择可反复读(Repeatable Read)作为默认的隔离级别呢？
历史起因,早阶段Mysql(5.1版本之前)的Binlog类型Statement是默认格局，即顺次记录零碎承受的SQL申请；5.1及当前，MySQL提供了Row,Mixed,statement 3种Binlog格局, 当binlog为statement格局,应用RC隔离级别时,会呈现BUG因而Mysql将可反复读(Repeatable Read)作为默认的隔离级别！
Binlog简介
Mysql binlog是二进制日志文件，用于记录mysql的数据更新或者潜在更新(比方DELETE语句执行删除而理论并没有符合条件的数据)，在mysql主从复制中就是依附的binlog。能够通过语句“show binlog events in 'binlogfile'”来查看binlog的具体事件类型。binlog记录的所有操作实际上都有对应的事件类型的
MySQL binlog的三种工作模式：Row （用到MySQL的非凡性能如存储过程、触发器、函数，又心愿数据最大化始终则抉择Row模式，咱们公司抉择的是row）
简介：日志中会记录每一行数据被批改的状况，而后在slave端对雷同的数据进行批改。
长处：能分明的记录每一行数据批改的细节
毛病：数据量太大
Statement （默认）
简介：每一条被批改数据的sql都会记录到master的bin-log中，slave在复制的时候sql过程会解析成和原来master端执行过的雷同的sql再次执行。在主从同步中个别是不倡议用statement模式的，因为会有些语句不反对，比方语句中蕴含UUID函数，以及LOAD DATA IN FILE语句等
长处：解决了 Row level下的毛病，不须要记录每一行的数据变动，缩小bin-log日志量，节约磁盘IO，进步新能
毛病：容易呈现主从复制不统一
Mixed（混合模式）
简介：联合了Row level和Statement level的长处，同时binlog构造也更简单。
咱们能够简略了解为binlog是一个记录数据库更改的文件,主从复制时须要此文件,具体细节先略过
主从不统一实操
binlog为STATEMENT格局，且隔离级别为读已提交(Read Commited)时，有什么bug呢？
测试表:
mysql> select * from test;+----+------+------+| id | name | age |+----+------+------+| 1 | NULL | NULL || 2 | NULL | NULL || 3 | NULL | NULL || 4 | NULL | NULL || 5 | NULL | NULL || 6 | NULL | NULL |+----+------+------+6 rows in set (0.00 sec)| Session1 | Session2 | |
|---|---|---|
| mysql> set tx_isolation = 'read-committed'; | ||
| Query OK, 0 rows affected, 1 warning (0.00 sec) | mysql> set tx_isolation = 'read-committed'; | |
| Query OK, 0 rows affected, 1 warning (0.00 sec) | ||
| begin; Query OK, 0 rows affected (0.00 sec) | begin; Query OK, 0 rows affected (0.00 sec) | |
| delete from test where 1=1; | ||
| Query OK, 6 rows affected (0.00 sec) | ||
| insert into test values (null,'name',100); | ||
| Query OK, 1 row affected (0.00 sec) | ||
| commit; | ||
| Query OK, 0 rows affected (0.01 sec) | ||
| commit; | ||
| Query OK, 0 rows affected (0.01 sec) |
Master此时输入
select * from test;+----+------+------+| id | name | age |+----+------+------+| 7 | name | 100 |+----+------+------+1 row in set (0.00 sec)然而，你在此时在从(slave)上执行该语句，得出输入
mysql> select * from test;Empty set (0.00 sec)在master上执行的程序为先删后插！而此时binlog为STATEMENT格局，是基于事务记录，在事务未提交前，二进制日志先缓存，提交后再写入记录的,因而程序为先插后删！slave同步的是binglog，因而从机执行的程序和主机不统一！slave在插入后删除了所有数据.
解决方案有两种！
(1)隔离级别设为可反复读(Repeatable Read),在该隔离级别下引入间隙锁。当Session 1执行delete语句时，会锁住间隙。那么，Ssession 2执行插入语句就会阻塞住！
(2)将binglog的格局批改为row格局，此时是基于行的复制，天然就不会呈现sql执行程序不一样的问题！奈何这个格局在mysql5.1版本开始才引入。因而因为历史起因，mysql将默认的隔离级别设为可反复读(Repeatable Read)，保障主从复制不出问题！
RU和Serializable
我的项目中不太应用读未提交(Read UnCommitted)和串行化(Serializable)两个隔离级别，起因:
读未提交(Read UnCommitted)
容许脏读，也就是可能读取到其余会话中未提交事务批改的数据 一个事务读到另一个事务未提交读数据
串行化(Serializable)
应用的乐观锁的实践，实现简略，数据更加平安，然而并发能力十分差。如果你的业务并发的特地少或者没有并发，同时又要求数据及时牢靠的话，能够应用这种模式。个别是应用mysql自带分布式事务性能时才应用该隔离级别
RC和 RR
此时咱们纠结的应该就只有一个问题了:隔离级别是用读已提交还是可反复读？
接下来对这两种级别进行比照的第一种状况:
在RR隔离级别下，存在间隙锁，导致呈现死锁的几率比RC大的多！
实现一个简略的间隙锁例子
select * from test where id <11 ;+----+------+------+| id | name | age |+----+------+------+| 1 | NULL | NULL || 2 | NULL | NULL || 3 | NULL | NULL || 4 | NULL | NULL || 5 | NULL | NULL || 6 | NULL | NULL || 7 | name | 7 |+----+------+------+7 rows in set (0.00 sec)| session1 | session2 | |
|---|---|---|
| mysql> set tx_isolation = 'repeatable-read'; | ||
| Query OK, 0 rows affected, 1 warning (0.00 sec) | mysql> set tx_isolation = 'repeatable-read'; | |
| Query OK, 0 rows affected, 1 warning (0.00 sec) | ||
| Begin; | ||
| select * from test where id <11 for update; | ||
| insert into test values(null,'name',9); //被阻塞! | ||
| commit; | ||
| Query OK, 0 rows affected (0.00 sec) | ||
| Query OK, 1 row affected (12.23 sec) //锁开释后实现了操作 |
在RR隔离级别下，能够锁住（-∞，10] 这个间隙，避免其余事务插入数据！
而在RC隔离级别下，不存在间隙锁，其余事务是能够插入数据！
ps:在RC隔离级别下并不是不会呈现死锁，只是呈现几率比RR低而已
### 锁表和锁行
在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行
select * from test;+----+------+------+| id | name | age |+----+------+------+| 8 | name | 11 || 9 | name | 9 || 10 | name | 15 || 11 | name | 15 || 12 | name | 16 |+----+------+------+锁表的例子:
| session1 | session2 | |
|---|---|---|
| Begin; | ||
| update test set age = age+1 where age = 15; | ||
| Rows matched: 2 Changed: 2 Warnings: 0 | ||
| insert into test values(null,'test',15); | ||
| ERROR 1205 (HY000): Lock wait timeout exceeded; | ||
| Commit; |
session2插入失败 查问 数据显示:
select * from test;+----+------+------+| id | name | age |+----+------+------+| 8 | name | 11 || 9 | name | 9 || 10 | name | 16 || 11 | name | 16 || 12 | name | 16 |+----+------+------+半一致性读(semi-consistent)个性
在RC隔离级别下，半一致性读(semi-consistent)个性减少了update操作的并发性！
在5.1.15的时候，innodb引入了一个概念叫做“semi-consistent”，缩小了更新同一行记录时的抵触，缩小锁期待。
所谓半一致性读就是，一个update语句，如果读到一行曾经加锁的记录，此时InnoDB返回记录最近提交的版本,判断此版本是否满足where条件。若满足则从新发动一次读操作，此时会读取行的最新版本并加锁！
倡议
在RC级别下,用的binlog为row格局，是基于行的复制,Innodb的创始人也是倡议binlog应用该格局
互联网我的项目请用：读已提交(Read Commited)这个隔离级别
总结
因为历史起因,老版本Mysql的binlog应用statement格局,不应用RR隔离级别会导致主从不统一的状况
目前(5.1版本之后)咱们应用row格局的binlog 配合RC隔离级别能够实现更好的并发性能.
关注公众号:java宝典