今天在學習JDBC的時候看到了關于MySql的事務的隔離級別的問題，感覺內容挺高級的，所以記錄一篇文章，以備后面使用。

數據庫隔離級別有四種，應用《高性能mysql》一書中的說明：

然后說說修改事務隔離級別的方法：

1.全局修改，修改mysql.ini配置文件，在最后加上

1 #可選參數有：READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE.2 [mysqld]3 transaction-isolation = REPEATABLE-READ

這里全局默認是REPEATABLE-READ,其實MySQL本來默認也是這個級別

2.對當前session修改，在登錄mysql客戶端后，執行命令：

set session transaction isolation level read uncommitted;

要記住mysql有一個autocommit參數，默認是on，他的作用是每一條單獨的查詢都是一個事務，并且自動開始，自動提交(執行完以后就自動結束了，如果你要適用select for update，而不手動調用 start transaction，這個for update的行鎖機制等于沒用，因為行鎖在自動提交后就釋放了)，所以事務隔離級別和鎖機制即使你不顯式調用start transaction，這種機制在單獨的一條查詢語句中也是適用的，分析鎖的運作的時候一定要注意這一點

再來說說鎖機制：

共享鎖：由讀表操作加上的鎖，加鎖后其他用戶只能獲取該表或行的共享鎖，不能獲取排它鎖，也就是說只能讀不能寫

排它鎖：由寫表操作加上的鎖，加鎖后其他用戶不能獲取該表或行的任何鎖，典型是mysql事務中

start transaction;

select * from user where userId = 1 for update;

執行完這句以后

1)當其他事務想要獲取共享鎖，比如事務隔離級別為SERIALIZABLE的事務，執行

select * from user;

將會被掛起，因為SERIALIZABLE的select語句需要獲取共享鎖

2)當其他事務執行

select * from user where userId = 1 for update;

update user set userAge = 100 where userId = 1;

也會被掛起，因為for update會獲取這一行數據的排它鎖，需要等到前一個事務釋放該排它鎖才可以繼續進行

鎖的范圍:

行鎖:對某行記錄加上鎖

表鎖:?對整個表加上鎖

這樣組合起來就有,行級共享鎖,表級共享鎖,行級排他鎖,表級排他鎖

下面來說說不同的事務隔離級別的實例效果，例子使用InnoDB，開啟兩個客戶端A，B，在A中修改事務隔離級別，在B中開啟事務并修改數據，然后在A中的事務查看B的事務修改效果(兩個客戶端相當于是兩個連接，在一個客戶端中的修改參數變量的值是不會影響到另外的一個客戶端的)：

1.READ-UNCOMMITTED(讀取未提交內容)級別

1)A修改事務級別并開始事務，對user表做一次查詢

2)B更新一條記錄

3)此時B事務還未提交，A在事務內做一次查詢，發現查詢結果已經改變

4)B進行事務回滾

5)A再做一次查詢，查詢結果又變回去了

6)A表對user表數據進行修改

7)B表重新開始事務后，對user表記錄進行修改，修改被掛起，直至超時，但是對另一條數據的修改成功，說明A的修改對user表的數據行加行共享鎖(因為可以使用select)

可以看出READ-UNCOMMITTED隔離級別，當兩個事務同時進行時，即使事務沒有提交，所做的修改也會對事務內的查詢做出影響，這種級別顯然很不安全。但是在表對某行進行修改時，會對該行加上行共享鎖

2. READ-COMMITTED(讀取提交內容)

1)設置A的事務隔離級別，并進入事務做一次查詢

2)B開始事務，并對記錄進行修改

3)A再對user表進行查詢，發現記錄沒有受到影響

4)B提交事務

5)A再對user表查詢，發現記錄被修改

6)A對user表進行修改

7)B重新開始事務，并對user表同一條進行修改，發現修改被掛起，直到超時，但對另一條記錄修改，卻是成功，說明A的修改對user表加上了行共享鎖(因為可以select)

READ-COMMITTED事務隔離級別，只有在事務提交后，才會對另一個事務產生影響，并且在對表進行修改時，會對表數據行加上行共享鎖

3. REPEATABLE-READ(可重讀)

1)A設置事務隔離級別，進入事務后查詢一次

2)B開始事務，并對user表進行修改

3)A查看user表數據，數據未發生改變

4)B提交事務

5)A再進行一次查詢，結果還是沒有變化

6)A提交事務后，再查看結果，結果已經更新

7)A重新開始事務，并對user表進行修改

8)B表重新開始事務，并對user表進行修改，修改被掛起，直到超時，對另一條記錄修改卻成功，說明A對表進行修改時加了行共享鎖(可以select)

REPEATABLE-READ事務隔離級別，當兩個事務同時進行時，其中一個事務修改數據對另一個事務不會造成影響，即使修改的事務已經提交也不會對另一個事務造成影響。

在事務中對某條記錄修改，會對記錄加上行共享鎖，直到事務結束才會釋放。

4.SERIERLIZED(可串行化)

1)修改A的事務隔離級別，并作一次查詢

2)B對表進行查詢，正常得出結果，可知對user表的查詢是可以進行的

3)B開始事務，并對記錄做修改，因為A事務未提交，所以B的修改處于等待狀態，等待A事務結束，最后超時，說明A在對user表做查詢操作后，對表加上了共享鎖

SERIALIZABLE事務隔離級別最嚴厲，在進行查詢時就會對表或行加上共享鎖，其他事務對該表將只能進行讀操作，而不能進行寫操作。

喜歡 (1)or分享 (0)

總結

以上是生活随笔為你收集整理的mysql isolation level_MySQL数据库事务隔离级别(Transaction Isolation Level)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。