MySQL數據庫事務隔離級別(Transaction Isolation Level)

轉載:http://www.cnblogs.com/zemliu/archive/2012/06/17/2552301.html
 
數據庫隔離級別有四種,應用《高性能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客戶端後,執行命令:
 
要記住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事務隔離級別最嚴厲,在進行查詢時就會對錶或行加上共享鎖,其他事務對該表將只能進行讀操作,而不能進行寫操作。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章