共计 6983 个字符，预计需要花费 18 分钟才能阅读完成。
事务的个性(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 宝典
