實例分析MySQL下的四種事務隔離級別

數據庫事務有四種隔離級別：

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

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

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

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

上面這樣的教科書式定義第一次接觸事務隔離概念的朋友看了可能會一臉懵逼，下面咱們就經過具體的實例來解釋四個隔離級別。

首先咱們建立一個user表：

CREATE TABLE user (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `name` varchar(255) NOT NULL,
    PRIMARY KEY (`id`),
    UNIQUE `uniq_name` USING BTREE (name)
) ENGINE=`InnoDB` AUTO_INCREMENT=10 DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

讀未提交隔離級別

咱們先將事務的隔離級別設置爲read committed：

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       |
+------------------------+
1 row in set (0.00 sec)

在下面咱們開了兩個終端分別用來模擬事務一和事務二，p.s: 操做一和操做二的意思是按照時間順序來執行的。

事務1

mysql> start transaction; # 操做1
Query OK, 0 rows affected (0.00 sec)

mysql> insert into user(name) values('ziwenxie'); # 操做3
Query OK, 1 row affected (0.05 sec)

事務2

mysql> start transaction; # 操做2
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user; # 操做4
+----+----------+
| id | name     |
+----+----------+
| 10 | ziwenxie |
+----+----------+
1 row in set (0.00 sec)

從上面的執行結果能夠和清晰的看出來，在read uncommited級別下面咱們在事務一中可能會讀取到事務二中沒有commit的數據，這就是髒讀。

讀提交隔離級別

經過設置隔離級別爲committed能夠解決上面的髒讀問題。

mysql> set session transaction isolation level read committed;

事務一

mysql> start transaction; # 操做一
Query OK, 0 rows affected (0.00 sec)


mysql> select * from user; # 操做三
+----+----------+
| id | name     |
+----+----------+
| 10 | ziwenxie |
+----+----------+
1 row in set (0.00 sec)

mysql> select * from user; # 操做五，操做四的修改並無影響到事務一
+----+----------+
| id | name     |
+----+----------+
| 10 | ziwenxie |
+----+----------+
1 row in set (0.00 sec)

mysql> select * from user; # 操做七

+----+------+
| id | name |
+----+------+
| 10 | lisi |
+----+------+
1 row in set (0.00 sec)

mysql> commit; # 操做八
Query OK, 0 rows affected (0.00 sec)

事務二

mysql> start transaction; # 操做二
Query OK, 0 rows affected (0.00 sec)

mysql> update user set name='lisi' where id=10; # 操做四
Query OK, 1 row affected (0.06 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> commit; # 操做六
Query OK, 0 rows affected (0.08 sec)

雖然髒讀的問題解決了，可是注意在事務一的操做七中，事務二在操做六commit後會形成事務一在同一個transaction中兩次讀取到的數據不一樣，這就是不可重複讀問題，使用第三個事務隔離級別repeatable read能夠解決這個問題。

可重複讀隔離級別

MySQL的Innodb存儲引擎默認的事務隔離級別就是可重複讀隔離級別，因此咱們不用進行多餘的設置。

事務一

mysql> start tansactoin; # 操做一

mysql> select * from user; # 操做五
+----+----------+
| id | name     |
+----+----------+
| 10 | ziwenxie |
+----+----------+
1 row in set (0.00 sec)

mysql> commit; # 操做六
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user; # 操做七
+----+------+
| id | name |
+----+------+
| 10 | lisi |
+----+------+
1 row in set (0.00 sec)

事務二

mysql> start tansactoin; # 操做二

mysql> update user set name='lisi' where id=10; # 操做三
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> commit; # 操做四

在事務一的操做五中咱們並無讀取到事務二在操做三中的update，只有在commit以後才能讀到更新後的數據。

Innodb解決了幻讀麼

實際上RR級別是可能產生幻讀，InnoDB引擎官方稱中利用MVCC多版本併發控制解決了這個問題，下面咱們驗證一下Innodb真的解決了幻讀了麼？

爲了方便展現，我修改了一下上面的user表：

mysql> alter table user add salary int(11);
Query OK, 0 rows affected (0.51 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> delete from user;
Query OK, 1 rows affected (0.07 sec)

mysql> insert into user(name, salary) value('ziwenxie', 88888888);
Query OK, 1 row affected (0.07 sec)

mysql> select * from user;
+----+----------+----------+
| id | name     | salary   |
+----+----------+----------+
| 10 | ziwenxie | 88888888 |
+----+----------+----------+
1 row in set (0.00 sec)

事務一

mysql> start transaction;  # 操做一
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user; # 操做三
+----+----------+----------+
| id | name     | salary   |
+----+----------+----------+
| 10 | ziwenxie | 88888888 |
+----+----------+----------+
1 row in set (0.00 sec)

mysql> update user set salary='4444'; # 操做六，居然影響了兩行，不是說解決了幻讀麼？
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2  Changed: 2  Warnings: 0

mysql> select * from user; # 操做七， Innodb並無徹底解決幻讀
+----+----------+--------+
| id | name     | salary |
+----+----------+--------+
| 10 | ziwenxie |   4444 |
| 11 | zhangsan |   4444 |
+----+----------+--------+
2 rows in set (0.00 sec)

mysql> commit; # 操做八
Query OK, 0 rows affected (0.04 sec)

事務二

mysql> start transaction; # 操做二
Query OK, 0 rows affected (0.00 sec)

mysql> insert into user(name, salary) value('zhangsan', '666666'); # 操做四
Query OK, 1 row affected (0.00 sec)

mysql> commit; # 操做五
Query OK, 0 rows affected (0.04 sec)

從上面的例子能夠看出，Innodb並無如官方所說解決幻讀，不過上面這樣的場景中也不是很常見不用過多的擔憂。

串行化隔離級別

全部事務串行執行，最高隔離級別，不會出現幻讀性能會不好，實際開發中不多使用到。

Contact

GitHub: https://github.com/ziwenxie
Blog: https://www.ziwenxie.site

本文同步發於個人我的博客，轉載請聲明博客出處 :)