mysql中innoDB鎖有什么主要作用

下文給大家?guī)碛嘘Pmysql中innoDB鎖有什么主要作用內(nèi)容，相信大家一定看過類似的文章。我們給大家?guī)淼挠泻尾煌兀恳黄饋砜纯凑牟糠职?，相信看完mysql中innoDB鎖有什么主要作用你一定會有所收獲。

在InnoDB加鎖前，為什么要先start transaction

　　innodb下鎖的釋放在事務提交/回滾之后，事務一旦提交/回滾之后，就會自動釋放事務中的鎖，innodb默認情況下autocommit=1即開啟自動提交

檢索條件使用索引和不使用索引的鎖區(qū)別：

　　檢索條件有索引的情況下會鎖定特定的一些行。

檢索條件沒有使用使用的情況下會進行全表掃描，從而鎖定全部的行（包括不存在的記錄）

讀鎖:

　　讀鎖是共享的，或者說是相互不阻塞的。多個用戶在同一時刻可以同時讀取同一個資源，而互不干擾。

寫鎖：

　　寫鎖是排他的，也就是說一個寫鎖會阻塞其他的寫鎖和讀鎖。另外寫鎖比讀鎖有更高的優(yōu)先級，因此一個寫鎖請求可能會被插入到讀鎖 隊列的前面，但是讀鎖則不肯能插入到寫鎖的前面

表鎖：

　　InnoDB還有兩個表鎖：意向共享鎖（IS），意向排它鎖（IX）

行鎖：

　　InnoDB實現(xiàn)了兩種類型額行級鎖，共享鎖和排它鎖

樂觀鎖：

　　樂觀鎖，也叫樂觀并發(fā)控制，它假設多用戶并發(fā)的事務在處理時不會彼此互相影響，各事務能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分數(shù)據(jù)。在提交數(shù)據(jù)更新之前，每個事務會先檢查在該事務讀取數(shù)據(jù)后，有沒有其他事務又修改了該數(shù)據(jù)。如果其他事務有更新的話，那么當前正在提交的事務會進行回滾。

悲觀鎖:

　　悲觀鎖，也叫悲觀并發(fā)控制，當事務A對某行數(shù)據(jù)應用了鎖，并且當這個事務把鎖釋放后，其他事務才能夠執(zhí)行與該鎖沖突的操作，這里事務A所施加的鎖就叫悲觀鎖。享鎖和排他鎖（行鎖，間隙鎖，next-key lock）都屬于悲觀鎖

悲觀鎖與樂觀鎖的實現(xiàn)方式：

　　悲觀鎖的實現(xiàn)依靠的是數(shù)據(jù)庫提供的鎖機制來實現(xiàn)，例如select * from news where id=12 for update,而樂觀鎖依靠的是記錄數(shù)據(jù)版本來實現(xiàn)，即通過在表中添加版本號字段來作為是否可以成功提交的關鍵因素。

共享鎖（S）：

　　共享鎖也叫讀鎖，一個事務獲取了一個數(shù)據(jù)行的共享鎖，其他事務能獲得該行對應的共享鎖，但不能獲得排他鎖，即一個事務在讀取一個數(shù)據(jù)行的時候，其他事務也可以讀，但不能對該數(shù)據(jù)行進行增刪改

　　設置共享鎖： SELECT .... LOCK IN SHARE MODE;

排它鎖（X）：

　　排它鎖也叫寫鎖，一個事務獲取了一個數(shù)據(jù)行的排他鎖，其他事務就不能再獲取該行的其他鎖（排他鎖或者共享鎖），即一個事務在讀取一個數(shù)據(jù)行的時候，其他事務不能對該數(shù)據(jù)行進行增刪改查

　　設置排它鎖：SELECT .... FOR UPDATE

　　注意點：

• 對于select 語句，innodb不會加任何鎖，也就是可以多個并發(fā)去進行select的操作，不會有任何的鎖沖突，因為根本沒有鎖。

• 對于insert，update，delete操作，innodb會自動給涉及到的數(shù)據(jù)加排他鎖，只有查詢select需要我們手動設置排他鎖。

意向共享鎖（IS）：

　　通知數(shù)據(jù)庫接下來需要施加什么鎖并對表加鎖。如果需要對記錄A加共享鎖，那么此時innodb會先找到這張表，對該表加意向共享鎖之后，再對記錄A添加共享鎖。也就是說一個數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖

意向排它鎖（IX）：

　　通知數(shù)據(jù)庫接下來需要施加什么鎖并對表加鎖。如果需要對記錄A加排他鎖，那么此時innodb會先找到這張表，對該表加意向排他鎖之后，再對記錄A添加共享鎖。也就是說一個數(shù)據(jù)行加排它鎖前必須先取得該表的IX鎖

　　共享鎖和意向共享鎖，排他鎖與意向排他鎖的區(qū)別：

• 共享鎖和排他鎖，系統(tǒng)在特定的條件下會自動添加共享鎖或者排他鎖，也可以手動添加共享鎖或者排他鎖。

• 意向共享鎖和意向排他鎖都是系統(tǒng)自動添加和自動釋放的，整個過程無需人工干預。

• 共享鎖和排他鎖都是鎖的行記錄，意向共享鎖和意向排他鎖鎖定的是表。

鎖的實現(xiàn)方式：

　　在MySQL中，行級鎖并不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引;如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。

　　InnoDB行鎖是通過給索引項加鎖實現(xiàn)的，如果沒有索引，InnoDB會通過隱藏的聚簇索引來對記錄加鎖。也就是說：如果不通過索引條件檢索數(shù)據(jù)，那么InnoDB將對表中所有數(shù)據(jù)加鎖，實際效果跟表鎖一樣

行鎖分為三種情況：

　　Record Lock:對索引項加鎖，即鎖定一條記錄。

　　Gap Lock:對索引項之間的 ‘間隙’ 、對第一條記錄前的間隙或最后一條記錄后的間隙加鎖，即鎖定一個范圍的記錄，不包含記錄本身

　　Next-key Lock:鎖定一個范圍的記錄并包含記錄本身(上面兩者的結合)

　　注意：InnoDB默認級別是repeatable-read（重復讀）級別。ANSI/IOS SQL標準定義了4種事務隔離級別：未提交讀(read uncommitted)，提交讀(read committed)，重復讀(repeatable read)，串行讀(serializable)

Gap Lock和Next-key Lock的區(qū)別：

　　Next-Key Lock是行鎖與間隙鎖的組合，這樣，當InnoDB掃描索引記錄的時候，會首先對選中的索引記錄加上行鎖（Record Lock），再對索引記錄兩邊的間隙加上間隙鎖（Gap Lock）。如果一個間隙被事務T1加了鎖，其它事務是不能在這個間隙插入記錄的。

　　行鎖防止別的事務修改或刪除，Gap鎖防止別的事務新增，行鎖和GAP鎖結合形成的Next-Key鎖共同解決了RR界別在寫數(shù)據(jù)時的幻讀問題。

何時在InnoDB中使用表鎖：

　　InnoDB在絕大部分情況會使用行級鎖，因為事務和行鎖往往是我們選擇InnoDB的原因，但是有些情況下我們也考慮使用表級鎖

• 當事務需要更新大部分數(shù)據(jù)時，表又比較大，如果使用默認的行鎖，不僅效率低，而且還容易造成其他事務長時間等待和鎖沖突。

• 事務比較復雜，很可能引起死鎖導致回滾。

在InnoDB下 ，使用表鎖要注意以下兩點。

（１）使用LOCK TALBES雖然可以給InnoDB加表級鎖，但必須說明的是，表鎖不是由InnoDB存儲引擎層管理的，而是由其上一層ＭySQL Server負責的，僅當autocommit=0、innodb_table_lock=1（默認設置）時，InnoDB層才能知道MySQL加的表鎖，ＭySQL Server才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖；否則，InnoDB將無法自動檢測并處理這種死鎖。

（２）在用LOCAK TABLES對InnoDB鎖時要注意，要將AUTOCOMMIT設為0，否則ＭySQL不會給表加鎖；事務結束前，不要用UNLOCAK TABLES釋放表鎖，因為UNLOCK TABLES會隱含地提交事務；COMMIT或ROLLBACK不能釋放用LOCAK TABLES加的表級鎖，必須用UNLOCK TABLES釋放表鎖，正確的方式見如下：

　　例如：如果需要寫表t1并從表t讀

SET AUTOCOMMIT=0;
LOCAK TABLES t1 WRITE, t2 READ, ...;[do something with tables t1 and here];COMMIT;
UNLOCK TABLES;

死鎖：

　　我們說過MyISAM中是不會產(chǎn)生死鎖的，因為MyISAM總是一次性獲得所需的全部鎖，要么全部滿足，要么全部等待。而在InnoDB中，鎖是逐步獲得的，就造成了死鎖的可能。

　   發(fā)生死鎖后，InnoDB一般都可以檢測到，并使一個事務釋放鎖回退，另一個獲取鎖完成事務。但在涉及外部鎖，或涉及鎖的情況下，InnoDB并不能完全自動檢測到死鎖，這需要通過設置鎖等待超時參數(shù)innodb_lock_wait_timeout來解決。需要說明的是，這個參數(shù)并不是只用來解決死鎖問題，在并發(fā)訪問比較高的情況下，如果大量事務因無法立即獲取所需的鎖而掛起，會占用大量計算機資源，造成嚴重性能問題，甚至拖垮數(shù)據(jù)庫。我們通過設置合適的鎖等待超時閾值，可以避免這種情況發(fā)生。

　　有多種方法可以避免死鎖，這里介紹常見的三種：

1. 如果不同程序會并發(fā)存取多個表，盡量約定以相同的順序訪問表，可以大大降低死鎖機會。如果兩個session訪問兩個表的順序不同，發(fā)生死鎖的機會就非常高！但如果以相同的順序來訪問，死鎖就可能避免。

2. 在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產(chǎn)生概率。

3. 對于非常容易產(chǎn)生死鎖的業(yè)務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產(chǎn)生的概。

4. 在程序以批量方式處理數(shù)據(jù)的時候，如果事先對數(shù)據(jù)排序，保證每個線程按固定的順序來處理記錄，也可以大大降低死鎖的可能。

5. 在REPEATEABLE-READ隔離級別下，如果兩個線程同時對相同條件記錄用SELECT...ROR UPDATE加排他鎖，在沒有符合該記錄情況下，兩個線程都會加鎖成功。程序發(fā)現(xiàn)記錄尚不存在，就試圖插入一條新記錄，如果兩個線程都這么做，就會出現(xiàn)死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可以避免問題。

6. 當隔離級別為READ COMMITED時，如果兩個線程都先執(zhí)行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個線程能插入成功，另一個線程會出現(xiàn)鎖等待，當?shù)冢眰€線程提交后，第２個線程會因主鍵重出錯，但雖然這個線程出錯了，卻會獲得一個排他鎖！這時如果有第３個線程又來申請排他鎖，也會出現(xiàn)死鎖。對于這種情況，可以直接做插入操作，然后再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執(zhí)行ROLLBACK釋放獲得的排他鎖

　　　ps:如果出現(xiàn)死鎖，可以用SHOW INNODB STATUS命令來確定最后一個死鎖產(chǎn)生的原因和改進措施。

總結：

　　對于InnoDB表，主要有以下幾點

（１）InnoDB的行銷是基于索引實現(xiàn)的，如果不通過索引訪問數(shù)據(jù)，InnoDB會使用表鎖。

（２）InnoDB間隙鎖機制，以及InnoDB使用間隙鎖的原因。

（３）在不同的隔離級別下，InnoDB的鎖機制和一致性讀策略不同。

（４）ＭySQL的恢復和復制對InnoDB鎖機制和一致性讀策略也有較大影響。

（５）鎖沖突甚至死鎖很難完全避免。

　　 在了解InnoDB的鎖特性后，用戶可以通過設計和SQL調(diào)整等措施減少鎖沖突和死鎖，包括：

• 盡量使用較低的隔離級別

• 精心設計索引，并盡量使用索引訪問數(shù)據(jù)，使加鎖更精確，從而減少鎖沖突的機會。

• 選擇合理的事務大小，小事務發(fā)生鎖沖突的幾率也更小。

• 給記錄集顯示加鎖時，最好一次性請求足夠級別的鎖。比如要修改數(shù)據(jù)的話，最好直接申請排他鎖，而不是先申請共享鎖，修改時再請求排他鎖，這樣容易產(chǎn)生死鎖。

• 不同的程序訪問一組表時，應盡量約定以相同的順序訪問各表，對一個表而言，盡可能以固定的順序存取表中的行。這樣可以大減少死鎖的機會。

• 盡量用相等條件訪問數(shù)據(jù)，這樣可以避免間隙鎖對并發(fā)插入的影響。

• 不要申請超過實際需要的鎖級別；除非必須，查詢時不要顯示加鎖。

• 對于一些特定的事務，可以使用表鎖來提高處理速度或減少死鎖的可能。

對于上文關于mysql中innoDB鎖有什么主要作用，大家覺得是自己想要的嗎？如果想要了解更多相關，可以繼續(xù)關注我們的行業(yè)資訊板塊。