概述

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

事務(wù)及其ACID屬性

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

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

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

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

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

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

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

不可重復(fù)讀：事務(wù)內(nèi)部相同的查詢在不同時(shí)刻結(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í)，如果不設(shè)置隔離級別默認(rèn)用MySQL設(shè)置的隔離級別，如果Spring設(shè)置了就用已設(shè)置的隔離級別；

鎖詳解

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

鎖分類

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

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

        讀鎖（共享鎖，S鎖（Shared））：針對同一份數(shù)據(jù)，多個(gè)讀操作可以同時(shí)進(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的最大不同點(diǎn)：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讀取到另外一個(gè)事務(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é)果如下：

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

 產(chǎn)生了不可重復(fù)讀的問題，一個(gè)事務(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é)果與開始時(shí)一樣，解決了不可重復(fù)讀的問題；直接查詢，此時(shí)age=8；

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

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

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

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

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

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

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

間隙鎖（Gap Lock）

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

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

臨鍵鎖（Next-key Locks）

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

無索引行鎖會升級為表鎖

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

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

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

結(jié)論：

Innodb存儲引擎由于實(shí)現(xiàn)了行級鎖定，雖然在鎖定機(jī)制的實(shí)現(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（等待平均時(shí)長）

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

Innodb_row_lock_time（等待總時(shí)長）

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

死鎖

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)生死鎖的那個(gè)事務(wù)，但有些情況無招。

查看近期死鎖日志信息：

show engine innodb status\G;

鎖優(yōu)化建議：

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

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

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

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

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

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

最新評論