概述

數(shù)據(jù)庫一般都會并發(fā)執(zhí)行多個事務(wù)，多個事務(wù)可能會并發(fā)的對相同的一批數(shù)據(jù)進(jìn)行增刪改查操作，可能導(dǎo)致臟讀、臟寫、不可重復(fù)度和幻讀。這些問題的本質(zhì)都是數(shù)據(jù)庫的多事務(wù)并發(fā)問題，為了解決事務(wù)并發(fā)問題，數(shù)據(jù)庫設(shè)計了事務(wù)隔離機制、鎖機制、MVCC多版本并發(fā)控制隔離機制，用一整套機制來解決多事務(wù)并發(fā)問題。

事務(wù)及其ACID屬性

原子性：操作的不可分割；

一致性：數(shù)據(jù)的一致性；

隔離性：事務(wù)之間互不干擾；

持久性：數(shù)據(jù)的修改時永久的；

并發(fā)事務(wù)處理帶來的問題

臟寫：丟失更新，最后的更新覆蓋了由其他事務(wù)所做的更新；

臟讀：事務(wù)A讀取到了事務(wù)B已經(jīng)修改但未提交的數(shù)據(jù)；

不可重復(fù)讀：事務(wù)內(nèi)部相同的查詢在不同時刻結(jié)果不一樣，針對的是數(shù)據(jù)的更新、刪除操作；

幻讀：事務(wù)A讀取到了其后開始的事務(wù)B提交的新增數(shù)據(jù)；針對的是數(shù)據(jù)的插入；

事務(wù)隔離級別

 READ-UNCONMMITTED、READ-COMMITTED、REPEATABLE-READ、SERIALIZABLE

查看當(dāng)前數(shù)據(jù)庫的事務(wù)隔離級別：

show variables like 'tx_isolation'

設(shè)置事務(wù)隔離級別：

set tx_isolation='REPEATABLE-READ';

MySQL默認(rèn)的事務(wù)隔離級別是可重復(fù)讀，用Spring開發(fā)程序時，如果不設(shè)置隔離級別默認(rèn)用MySQL設(shè)置的隔離級別，如果Spring設(shè)置了就用已設(shè)置的隔離級別；

鎖詳解

鎖是計算機協(xié)調(diào)多個進(jìn)程或線程并發(fā)訪問某一資源的機制。

鎖分類

從性能上分為：樂觀鎖（用版本對比來實現(xiàn)）和悲觀鎖；

從對數(shù)據(jù)庫操作類型分：讀寫和寫鎖（悲觀鎖）；

        讀鎖（共享鎖，S鎖（Shared））：針對同一份數(shù)據(jù)，多個讀操作可以同時進(jìn)行而不會互相影響；

        寫鎖（排它鎖，X鎖（exclusive））:當(dāng)前寫操作沒有完成前，阻斷其他寫鎖和讀鎖；

從對數(shù)據(jù)庫操作的粒度分：表鎖和行鎖

        表鎖：每次操作鎖住整張表，開銷小，加鎖快；不會出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低；一般用在整表數(shù)據(jù)遷移的場景。

# 手動增加表鎖
lock table 表名稱 read(write),表名稱2 read(write);
# 查看表上加過的鎖
show open tables;
# 刪除表鎖
unlock tables;

        行鎖：每次操作鎖住一行數(shù)據(jù)。開銷大，加鎖慢；會出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度最高。

InnoDB與MYISAM的最大不同點：1、InnoDB支持事務(wù)；2、InnoDB支持行級鎖。

總結(jié)：

MyISAM在執(zhí)行查詢語句前，會自動給涉及的表加讀鎖；執(zhí)行update、insert、delete操作加寫鎖；

InnoDB在執(zhí)行查詢語句前（非串行隔離級別），不會加鎖；執(zhí)行update、insert、delete操作會加行鎖。

讀鎖會阻塞寫，但不會阻塞讀。而寫鎖會把讀寫都阻塞。

行鎖與事務(wù)隔離級別案例分析

 mysql準(zhǔn)備一張表

1、臟讀，事務(wù)A讀取到另外一個事務(wù)已修改但未提交的數(shù)據(jù)，此種情形簡單，不具體闡述。對應(yīng)的事務(wù)隔離級別：read uncommitted（讀未提交）。

2、不可重復(fù)讀，對應(yīng)的事務(wù)隔離級別：read committed（讀已提交）

事務(wù)A：

set session transaction isolation level read committed;
 
start transaction;
 
select * from t_user;

事務(wù)B：

set session transaction isolation level read committed;
 
start transaction;
 
-- insert into t_user values (1,'張',8);
update t_user set age = 9 where id = 1;
 
commit;

事務(wù)A第一次執(zhí)行到查詢語句，結(jié)果如下：

此時，事務(wù)B執(zhí)行完畢，事務(wù)A還未結(jié)束，繼續(xù)執(zhí)行一次查詢，結(jié)果如下：

 產(chǎn)生了不可重復(fù)讀的問題，一個事務(wù)內(nèi)前后兩次查詢的數(shù)據(jù)結(jié)果不一致，讀取到了其他事務(wù)已經(jīng)提交的數(shù)據(jù)。

3、可重復(fù)讀，設(shè)置事務(wù)隔離級別為repeatable read（可重復(fù)讀）；

事務(wù)A第一次執(zhí)行結(jié)果如下：

 事務(wù)B執(zhí)行，修改操作，update  age=8并提交，結(jié)果對比如下

 左邊為事務(wù)A，查詢結(jié)果與開始時一樣，解決了不可重復(fù)讀的問題；直接查詢，此時age=8；

可重復(fù)讀的隔離級別下使用了MVCC（multi-version concurrency control）機制，select操作不會更新版本號，是快照讀（歷史版本）；insert、update和delete會更新版本號，是當(dāng)前讀（當(dāng)前版本）。

4、幻讀，在3中，新增一條數(shù)據(jù)，如下

 此時事務(wù)A再次查詢，結(jié)果如下：

 結(jié)果依然和開始的一樣，此種場景，可重復(fù)讀隔離級別有效的防止了不可重復(fù)讀和幻讀的問題；

如果，事務(wù)A，在第一次查詢后，執(zhí)行不加條件的update，這個update會作用在所有的行上面，包括事務(wù)B新增加的數(shù)據(jù)。此時，再執(zhí)行查詢，結(jié)果如下：

 出現(xiàn)了幻讀，Mysql官方給出的幻讀解釋是：只要在一個事務(wù)中，第二次select多出了row計算幻讀。

5、串行化，serializable，InnoDB的查詢也會被加上行鎖。如果查詢的是一個范圍，那么該范圍內(nèi)的所有記錄行包括每行記錄所在的間隙區(qū)間范圍都會被加鎖，即使該行數(shù)據(jù)還沒有被插入。

間隙鎖（Gap Lock）

session_1執(zhí)行update t_user set name ='哈哈' where id>8 and id<18;則其他session無法在這個范圍包含的所有行記錄以及行記錄所在的間隙里插入或修改任何數(shù)據(jù)

間隙鎖在可重復(fù)讀隔離級別下才會生效

臨鍵鎖（Next-key Locks）

Next-key Locks是行鎖與間隙鎖的組合。在間隙鎖（8,18）這個范圍，實際會找到存在的值，比如id距離這個區(qū)間最近的是，3,20；則實際在（3,20]這個范圍都處在行鎖范圍內(nèi)。

無索引行鎖會升級為表鎖

鎖主要是加在索引上，如果對非索引字段更新，行鎖可能會變表鎖。

InnoDB的行鎖是針對索引加的鎖，不是針對記錄加的鎖。并且該索引不能失效，否則都會從行鎖升級為表鎖

鎖定某一行還可以用lock in share mode(共享鎖)和for update(排它鎖)

結(jié)論：

Innodb存儲引擎由于實現(xiàn)了行級鎖定，雖然在鎖定機制的實現(xiàn)方面所帶來的性能損耗可能比表級鎖定會更高，但是在整體并發(fā)處理能力方面要遠(yuǎn)遠(yuǎn)優(yōu)于MYISAM的表級鎖定。

但是，Innodb的行級鎖定同樣有其脆弱的一面，如使用不當(dāng)，可能會讓整體的性能更差。

行鎖分析

通過檢查InnoDB_row_lock狀態(tài)變量來分析系統(tǒng)上的行鎖的爭奪情況

show status like 'innodb_row_lock%';

比較重要的主要有：

Innodb_row_lock_time_avg（等待平均時長）

Innodb_row_lock_waits（等待總次數(shù)）

Innodb_row_lock_time（等待總時長）

當(dāng)?shù)却螖?shù)很高，且每次等待時長也不小的時候，就需要分析系統(tǒng)中為什么會有如此多的等待，根據(jù)分析結(jié)果制定優(yōu)化計劃。

死鎖

set session transaction isolation level repeatable read;
 
start transaction;
 
select * from t_user where id = 2 for update;
select * from t_user where id = 1 for update;

事務(wù)A先鎖定id=1,再鎖定id=2;事務(wù)B順序相反，出現(xiàn)死鎖，結(jié)果如下：

 大多數(shù)情況Mysql可以自動檢測死鎖并回滾產(chǎn)生死鎖的那個事務(wù)，但有些情況無招。

查看近期死鎖日志信息：

show engine innodb status\G;

鎖優(yōu)化建議：

1、盡可能讓所有數(shù)據(jù)檢索都通過索引來完成，避免無索引行鎖升級為表鎖；

2、合理設(shè)計索引，盡量縮小鎖的范圍；

3、盡可能減少索引條件范圍，避免間隙鎖；

4、盡量控制事務(wù)大小，減少鎖定資源量和時間長度，涉及事務(wù)加鎖的sql盡量放在事務(wù)最后執(zhí)行；

5、盡可能低級別事務(wù)隔離

到此這篇關(guān)于深入理解Mysql事務(wù)隔離級別與鎖機制的文章就介紹到這了,更多相關(guān)Mysql事務(wù)隔離級別與鎖機制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論