【MySQL】事物隔離級別

author：咔咔

WeChat：fangkangfk

 

事務隔離級別

隔離級別	讀數據一致性	髒讀	不可重複讀的問題	幻讀
未提交讀 Read Uncommitted	最低級別，只能保證不讀取物理上損壞的數據	是	是	是
已讀提交 Read committed	語句級	否	是	是
可重複讀取 Repeatable Read	事務隔離級別	否	否	是
序列化 Serializable	最高級別，事務級	否	否	否

• 未受權讀取（未提交讀 Read Uncommitted）：READ-UNCOMMITTED | 0：存在髒讀，不可重複讀，幻讀的問題。若是一個事務已經開始寫數據，則另一個數據則不會容許同時進行寫操做，但容許其餘事務讀此行數據。隔離級別能夠經過「排他寫鎖」實現。
• 受權讀取（已讀提交 Read committed）：READ-COMMITTED | 1：解決髒讀的問題，存在不可重複讀，幻讀的問題。這個能夠經過「排他寫鎖」實現。讀取數據的事務容許其餘事務繼續訪問該行數據，可是未提交的寫事務將會禁止其餘事務訪問該行。
• 可重複讀取（Repeatable Read）：REPEATABLE-READ | 2：解決髒讀，不可重複讀的問題，存在幻讀的問題，默認隔離級別。可經過「共享鎖」，「排他鎖」實現。讀取數據的事務將會禁止寫事務（但容許讀事務），寫事務則禁止任何其餘事務。
• 序列化（Serializable）：SERIALIZABLE | 3：解決髒讀，不可重複讀，幻讀，可保證事務安全，但徹底串行執行，性能最低。提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接着一個地執行，不能併發執行。若是僅僅經過「行級鎖」是沒法實現事務序列化的，必需要經過其餘機制保證新插入的數據不會被剛執行查詢操做的事務訪問到。

併發下事物會出現的問題

數據更新丟失：

倆個事物同時操做一條數據，一個事物由於異常致使數據更新丟失

髒讀：

髒讀是指在一個事務處理過程裏讀取了另外一個未提交的事務中的數據。

　　當一個事務正在屢次修改某個數據，而在這個事務中這屢次的修改都還未提交，這時一個併發的事務來訪問該數據，就會形成兩個事務獲得的數據不一致。例如：用戶A向用戶B轉帳100元，對應SQL命令以下

當只執行第一條SQL時，A通知B查看帳戶，B發現確實錢已到帳（此時即發生了髒讀），而以後不管第二條SQL是否執行，只要該事務不提交，則全部操做都將回滾，那麼當B之後再次查看帳戶時就會發現錢其實並無轉。

update account set money=money+100 where name=’B’;  (此時A通知B)

    update account set money=money - 100 where name=’A’;

不可重複讀

是指在對於數據庫中的某個數據，一個事務範圍內屢次查詢卻返回了不一樣的數據值，這是因爲在查詢間隔，被另外一個事務修改並提交了。

　　例如事務T1在讀取某一數據，而事務T2立馬修改了這個數據而且提交事務給數據庫，事務T1再次讀取該數據就獲得了不一樣的結果，發送了不可重複讀。

　　不可重複讀和髒讀的區別是，髒讀是某一事務讀取了另外一個事務未提交的髒數據，而不可重複讀則是讀取了前一事務提交的數據。

　　在某些狀況下，不可重複讀並非問題，好比咱們屢次查詢某個數據固然以最後查詢獲得的結果爲主。但在另外一些狀況下就有可能發生問題，例如對於同一個數據A和B依次查詢就可能不一樣，A和B就可能打起來了……

 

幻讀

是事務非獨立執行時發生的一種現象。例如事務T1對一個表中全部的行的某個數據項作了從「1」修改成「2」的操做，這時事務T2又對這個表中插入了一行數據項，而這個數據項的數值仍是爲「1」而且提交給數據庫。而操做事務T1的用戶若是再查看剛剛修改的數據，會發現還有一行沒有修改，其實這行是從事務T2中添加的，就好像產生幻覺同樣，這就是發生了幻讀。

　　幻讀和不可重複讀都是讀取了另外一條已經提交的事務（這點就髒讀不一樣），所不一樣的是不可重複讀查詢的都是同一個數據項，而幻讀針對的是一批數據總體（好比數據的個數）。

 

事務異常現象展現與解決

級聯回滾

隔離級別：任意

在程序運行過程當中實際上，咱們的事務每每是會併發運行的，可能在某一段時間內運行幾個事務；而其中會有一個很現象是很難解決的可是能夠減小該現象的影響，就是級聯回滾；

級聯回滾：就是在一段時間同時有兩個及以上的事務在運行，因爲最早運行的事務出現了 「異常」 致使事務不得不回滾的狀況

演示

session1	session2	session3
begin;	begin;	begin;
select * from count where prefix = 'dz10021'	|
update count set count = 1 where prefix = 'dz10021';	|
| select * from count where prefix = 'dz10021'
| update count set count = 2 where prefix = 'dz10021';	select * from count where prefix = 'dz10021'
|	update count set count = 3 where prefix = 'dz10021';
這裏添加一條錯誤的信息	|
insert into count values('dz10021', 0, 2);	|
這裏由於異常回滾	由於session1異常回滾	由於session1異常回滾
[Err] 1062 - Duplicate entry 'dz10021' for key 'PRIMARY'	[Err] 1213 - Deadlock found when trying to get lock; try restarting transaction	[Err] 1213 - Deadlock found when trying to get lock; try restarting transaction

解釋：如上的狀況就是由於與session1發生了異常，可是由於session2與session3依賴於session1實現某一些業務，爲了保證數據的一致性的話，是會對於相互依賴操做的數據進行級聯的回滾這是頗有必要的，可是對於程序來講體驗很差，事情快要作好了，忽然由於別人的一個岔子打斷，會很不舒服。

解決：能夠在select * from count where prefix = 'dz10021' 加上 for update

幻讀

隔離級別：RR

session1	session2
start transaction	start transaction
select * from count where prefix = 'dz1'
沒有發現這條數據準備新增	select * from count where prefix = 'dz1'
| 這也沒發現這條數據新增
這裏由於其餘事情耽擱了	insert into count values('dz1', 1, 1)
| commit
處理以後新增
insert into count values('dz1', 0, 1)
出現主鍵衝突，若是沒有設置主鍵就是數據重複提交