Mysql事務隔離級別

1、事務的四大特性(簡稱ACID)

數據庫若是支持事務的操做，那麼就具有如下四個特性：

一、原子性(Atomicity)

事務是數據庫的邏輯工做單位，事務中包括的諸操做要麼全作，要麼全不作。

二、一致性(Consistency)

事務執行的結果必須是使數據庫從一個一致性狀態變到另外一個一致性狀態。一致性與原子性是密切相關的。

三、隔離性(Isolation)

一個事務的執行不能被其餘事務干擾。

四、持續性/永久性(Durability)

一個事務一旦提交，它對數據庫中數據的改變就應該是永久性的。

2、事務的四種隔離級別

按照SQL:1992 事務隔離級別，InnoDB默認是可重複讀的（REPEATABLE READ）。MySQL/InnoDB 提供SQL標準所描述的全部四個事務隔離級別。你能夠在命令行用--transaction-isolation選項，或在選項文件裏，爲全部鏈接設置默認隔離級別。
例如，你能夠在my.inf文件的[mysqld]節裏相似以下設置該選項：

transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE}

用戶能夠用SET TRANSACTION語句改變單個會話或者全部新進鏈接的隔離級別。它的語法以下：

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

注意：默認的行爲（不帶session和global）是爲下一個（未開始）事務設置隔離級別。若是你使用GLOBAL關鍵字，語句在全局對從那點開始建立的全部新鏈接（除了不存在的鏈接）設置默認事務級別。你須要SUPER權限來作這個。使用SESSION 關鍵字爲未來在當前鏈接上執行的事務設置默認事務級別。 任何客戶端都能自由改變會話隔離級別（甚至在事務的中間），或者爲下一個事務設置隔離級別。 

你能夠用下列語句查詢全局和會話事務隔離級別：

SELECT @@global.tx_isolation;
SELECT @@session.tx_isolation;
SELECT @@tx_isolation;

隔離級別	髒讀（Dirty Read）	不可重複讀（NonRepeatable Read）	幻讀（Phantom Read）
未提交讀（Read uncommitted）	可能	可能	可能
已提交讀（Read committed）	不可能	可能	可能
可重複讀（Repeatable read）	不可能	不可能	可能
可串行化（Serializable ）	不可能	不可能	不可能

 

 

 

 

 

 

 

---

 

1.未提交讀(Read Uncommitted)：容許髒讀，也就是可能讀取到其餘會話中未提交事務修改的數據

2.提交讀(Read Committed)：只能讀取到已經提交的數據。Oracle等多數數據庫默認都是該級別 (不重複讀)

3.可重複讀(Repeated Read)：可重複讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標準中，該隔離級別消除了不可重複讀，可是還存在幻象讀

4.串行讀(Serializable)：徹底串行化的讀，每次讀都須要得到表級共享鎖，讀寫相互都會阻塞

 

Read Uncommitted這種級別，數據庫通常都不會用，並且任何操做都不會加鎖，這裏就不討論了。

 

 1.）Mysql事務隔離級別之未提交讀

mysql> set session transaction isolation level read uncommitted;   //設置未提交讀
Query OK, 0 rows affected (0.00 sec)

mysql> select @@session.tx_isolation;
+------------------------+
| @@session.tx_isolation |
+------------------------+
| READ-UNCOMMITTED       |
+------------------------+


mysql> CREATE TABLE `test` (
    ->   `id` varchar(64) NOT NULL COMMENT '主鍵ID',
    ->   `name` varchar(64) NOT NULL COMMENT '名稱'
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='test';
Query OK, 0 rows affected (0.03 sec)

mysql> start transaction;              //開啓事務
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO test (id, name) VALUES ('c2f25a90-fd66-420d-9003-3b0f1d16c0b7', '123');     //插入數據，但未提交事務
Query OK, 1 row affected (0.01 sec)

mysql>

打開另外一個session看下，能不能查到數據

示例以下，也能查到數據，說明出現了髒讀：就是指當一個事務正在訪問數據，而且對數據進行了修改，而這種修改尚未提交到數據庫中，這時，另一個事務也訪問這個數據，而後使用了這個數據

mysql> set session transaction isolation level read uncommitted;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test;
+--------------------------------------+------+
| id                                   | name |
+--------------------------------------+------+
| c2f25a90-fd66-420d-9003-3b0f1d16c0b7 | 123  |     //讀取的是另外一事務未提交的數據
+--------------------------------------+------+
1 row in set (0.00 sec)

mysql>

 2.）Mysql事務隔離級別之提交讀

1.設置隔離級別爲提交讀，並查詢數據

sesson1

mysql> set session transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)

mysql> select @@session.tx_isolation;
+------------------------+
| @@session.tx_isolation |
+------------------------+
| READ-COMMITTED         |
+------------------------+
1 row in set (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test;    //數據是空的
Empty set (0.01 sec)

2）在session2開啓另一個事務，插入數據，事務不提交

start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO test (id, name) VALUES ('c2f25a90-fd66-420d-9003-3b0f1d16c0b7', '123');
Query OK, 1 row affected (0.00 sec)

  再次在session1中再查一次數據

mysql> select * from test;   //仍是空的。
Empty set (0.00 sec)

 3）在sesson2的事務提交，並在session1中再查一次數據，發現已經能夠查到數據了

mysql> commit;
Query OK, 0 rows affected (0.01 sec)

mysql> select * from test;
+--------------------------------------+------+
| id                                   | name |
+--------------------------------------+------+
| c2f25a90-fd66-420d-9003-3b0f1d16c0b7 | 123  |
+--------------------------------------+------+
1 row in set (0.01 sec)

說明提交讀出現了不可重複讀：是指在一個事務內，屢次讀同一數據。在這個事務尚未結束時，另一個事務也訪問該同一數據。那麼，在第一個事務中的兩次讀數據之間，因爲第二個事務的修改，那麼第一個事務兩次讀到的的數據多是不同的。這樣就發生了在一個事務內兩次讀到的數據是不同的，所以稱爲是不可重複讀。

 3.）Mysql事務隔離級別之可重複讀

1.在session1中設置事務隔離級別爲可重複讀，並開啓事務，進行查詢test表數據，發現只有三條數據

mysql>  set session transaction isolation level Repeatable read;
Query OK, 0 rows affected (0.00 sec)

mysql> select @@session.tx_isolation;
+------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ        |
+------------------------+
1 row in set (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test;
+--------------------------------------+--------+
| id                                   | name   |
+--------------------------------------+--------+
| c2f25a90-fd66-420d-9003-3b0f1d16c0b7 | 123    |
| asdasd                               | 321    |
| 可重複讀測試                         | lklklk |
+--------------------------------------+--------+
3 rows in set (0.00 sec)

2.在另外一個session中開啓一個事務，進行數據的插入，並提交事務

mysql> select @@session.tx_isolation;
+------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ        |
+------------------------+
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO test (id, name) VALUES ('可重複讀測試123', 'lklklk');
Query OK, 1 row affected (0.01 sec)

mysql> commit ;
Query OK, 0 rows affected (0.00 sec)

3.在session1中再查詢test數據，發現仍是三條數據

mysql> select * from test;
+--------------------------------------+--------+
| id                                   | name   |
+--------------------------------------+--------+
| c2f25a90-fd66-420d-9003-3b0f1d16c0b7 | 123    |
| asdasd                               | 321    |
| 可重複讀測試                         | lklklk |
+--------------------------------------+--------+
3 rows in set (0.00 sec)

  可重複讀，就是在一個事務查詢中，若另外一個事務修改數據，並不會影響到這個查詢的事務查詢的數據；也就是說在一個查詢事務中，從開啓事務到提交事務之間的數據都是不受其餘事務影響的

3、未提交讀、提交讀和可重複讀都會出現幻讀

幻讀：第一個事務對一個表中的數據進行了修改，這種修改涉及到表中的所有數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那麼，之後就會發生操做第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺同樣。

mysql>CREATE TABLE `t_bitfly` (
`id` bigint(20) NOT NULL default '0',
`value` varchar(32) default NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB

mysql> select @@global.tx_isolation, @@tx_isolation;
+-----------------------+-----------------+
| @@global.tx_isolation | @@tx_isolation  |
+-----------------------+-----------------+
| REPEATABLE-READ       | REPEATABLE-READ |
+-----------------------+-----------------+

實驗一：

t Session A                   Session B
|
| START TRANSACTION;          START TRANSACTION;
|
| SELECT * FROM t_bitfly;
| empty set
|                             INSERT INTO t_bitfly
|                             VALUES (1, 'a');
|
| SELECT * FROM t_bitfly;
| empty set
|                             COMMIT;
|
| SELECT * FROM t_bitfly;
| empty set
|
| INSERT INTO t_bitfly VALUES (1, 'a');
| ERROR 1062 (23000):
| Duplicate entry '1' for key 1
v (shit, 剛剛明明告訴我沒有這條記錄的)

如此就出現了幻讀，覺得表裏沒有數據，其實數據已經存在了，傻乎乎的提交後，才發現數據衝突了。

實驗二：

t Session A                  Session B
|
| START TRANSACTION;         START TRANSACTION;
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|                            INSERT INTO t_bitfly
|                            VALUES (2, 'b');
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|                            COMMIT;
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|
| UPDATE t_bitfly SET value='z';
| Rows matched: 2  Changed: 2  Warnings: 0
| (怎麼多出來一行)
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | z     |
| |    2 | z     |
| +------+-------+

本事務中第一次讀取出一行，作了一次更新後，另外一個事務裏提交的數據就出現了。也能夠看作是一種幻讀。
當隔離級別是可重複讀，且禁用innodb_locks_unsafe_for_binlog的狀況下，在搜索和掃描index的時候使用的next-key locks能夠避免幻讀。

再看一個實驗，要注意，表t_bitfly裏的id爲主鍵字段。

實驗三：
t Session A                 Session B
|
| START TRANSACTION;        START TRANSACTION;
|
| SELECT * FROM t_bitfly
| WHERE id<=1
| FOR UPDATE;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|                           INSERT INTO t_bitfly
|                           VALUES (2, 'b');
|                           Query OK, 1 row affected
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|                           INSERT INTO t_bitfly
|                           VALUES (0, '0');
|                           (waiting for lock ...then timeout)
|                           ERROR 1205 (HY000):
|                           Lock wait timeout exceeded;
|                           try restarting transaction
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|                           COMMIT;
|
| SELECT * FROM t_bitfly;

| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+

能夠看到，用id<=1加的鎖，只鎖住了id<=1的範圍，能夠成功添加id爲2的記錄，添加id爲0的記錄時就會等待鎖的釋放。

實驗四：一致性讀和提交讀
t Session A                      Session B
|
| START TRANSACTION;             START TRANSACTION;
|
| SELECT * FROM t_bitfly;
| +----+-------+
| | id | value |
| +----+-------+
| |  1 | a     |
| +----+-------+
|                                INSERT INTO t_bitfly
|                                VALUES (2, 'b');
|                                COMMIT;
|
| SELECT * FROM t_bitfly;
| +----+-------+
| | id | value |
| +----+-------+
| |  1 | a     |
| +----+-------+
|
| SELECT * FROM t_bitfly LOCK IN SHARE MODE;
| +----+-------+
| | id | value |
| +----+-------+
| |  1 | a     |
| |  2 | b     |
| +----+-------+
|
| SELECT * FROM t_bitfly FOR UPDATE;
| +----+-------+
| | id | value |
| +----+-------+
| |  1 | a     |
| |  2 | b     |
| +----+-------+
|
| SELECT * FROM t_bitfly;
| +----+-------+
| | id | value |
| +----+-------+
| |  1 | a     |
| +----+-------+

若是使用普通的讀，會獲得一致性的結果，若是使用了加鎖的讀，就會讀到「最新的」「提交」讀的結果。

自己，可重複讀和提交讀是矛盾的。在同一個事務裏，若是保證了可重複讀，就會看不到其餘事務的提交，違背了提交讀；若是保證了提交讀，就會致使先後兩次讀到的結果不一致，違背了可重複讀。

能夠這麼講，InnoDB提供了這樣的機制，在默認的可重複讀的隔離級別裏，可使用加鎖讀去查詢最新的數據（提交讀）。
MySQL InnoDB的可重複讀並不保證避免幻讀，須要應用使用加鎖讀來保證。而這個加鎖度使用到的機制就是next-key locks。

總結:

四個級別逐漸加強，每一個級別解決一個問題。事務級別越高,性能越差,大多數環境read committed 能夠用.記住4個隔離級別的特色(上面的例子);

 

參考：http://www.javashuo.com/article/p-pyttmqsd-k.html

         https://tech.meituan.com/2014/08/20/innodb-lock.html