下文給大家?guī)碛嘘P(guān)MySQL中innoDB鎖有什么主要作用內(nèi)容，相信大家一定看過類似的文章。我們給大家?guī)淼挠泻尾煌?？一起來看看正文部分吧，相信看完mysql中innoDB鎖有什么主要作用你一定會有所收獲。
波密網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,波密網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為波密上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的波密做網(wǎng)站的公司定做！
innodb下鎖的釋放在事務(wù)提交/回滾之后，事務(wù)一旦提交/回滾之后，就會自動釋放事務(wù)中的鎖，innodb默認(rèn)情況下autocommit=1即開啟自動提交
檢索條件使用索引和不使用索引的鎖區(qū)別：
檢索條件有索引的情況下會鎖定特定的一些行。
檢索條件沒有使用使用的情況下會進(jìn)行全表掃描，從而鎖定全部的行（包括不存在的記錄）
讀鎖是共享的，或者說是相互不阻塞的。多個用戶在同一時刻可以同時讀取同一個資源，而互不干擾。
寫鎖是排他的，也就是說一個寫鎖會阻塞其他的寫鎖和讀鎖。另外寫鎖比讀鎖有更高的優(yōu)先級，因此一個寫鎖請求可能會被插入到讀鎖 隊列的前面，但是讀鎖則不肯能插入到寫鎖的前面
InnoDB還有兩個表鎖：意向共享鎖（IS），意向排它鎖（IX）
InnoDB實現(xiàn)了兩種類型額行級鎖，共享鎖和排它鎖
樂觀鎖，也叫樂觀并發(fā)控制，它假設(shè)多用戶并發(fā)的事務(wù)在處理時不會彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分?jǐn)?shù)據(jù)。在提交數(shù)據(jù)更新之前，每個事務(wù)會先檢查在該事務(wù)讀取數(shù)據(jù)后，有沒有其他事務(wù)又修改了該數(shù)據(jù)。如果其他事務(wù)有更新的話，那么當(dāng)前正在提交的事務(wù)會進(jìn)行回滾。
悲觀鎖，也叫悲觀并發(fā)控制，當(dāng)事務(wù)A對某行數(shù)據(jù)應(yīng)用了鎖，并且當(dāng)這個事務(wù)把鎖釋放后，其他事務(wù)才能夠執(zhí)行與該鎖沖突的操作，這里事務(wù)A所施加的鎖就叫悲觀鎖。享鎖和排他鎖（行鎖，間隙鎖，next-key lock）都屬于悲觀鎖
悲觀鎖的實現(xiàn)依靠的是數(shù)據(jù)庫提供的鎖機制來實現(xiàn)，例如select * from news where id=12 for update,而樂觀鎖依靠的是記錄數(shù)據(jù)版本來實現(xiàn)，即通過在表中添加版本號字段來作為是否可以成功提交的關(guān)鍵因素。
共享鎖也叫讀鎖，一個事務(wù)獲取了一個數(shù)據(jù)行的共享鎖，其他事務(wù)能獲得該行對應(yīng)的共享鎖，但不能獲得排他鎖，即一個事務(wù)在讀取一個數(shù)據(jù)行的時候，其他事務(wù)也可以讀，但不能對該數(shù)據(jù)行進(jìn)行增刪改
設(shè)置共享鎖： SELECT .... LOCK IN SHARE MODE;
排它鎖也叫寫鎖，一個事務(wù)獲取了一個數(shù)據(jù)行的排他鎖，其他事務(wù)就不能再獲取該行的其他鎖（排他鎖或者共享鎖），即一個事務(wù)在讀取一個數(shù)據(jù)行的時候，其他事務(wù)不能對該數(shù)據(jù)行進(jìn)行增刪改查
設(shè)置排它鎖：SELECT .... FOR UPDATE
注意點：
對于select 語句，innodb不會加任何鎖，也就是可以多個并發(fā)去進(jìn)行select的操作，不會有任何的鎖沖突，因為根本沒有鎖。
對于insert，update，delete操作，innodb會自動給涉及到的數(shù)據(jù)加排他鎖，只有查詢select需要我們手動設(shè)置排他鎖。
通知數(shù)據(jù)庫接下來需要施加什么鎖并對表加鎖。如果需要對記錄A加共享鎖，那么此時innodb會先找到這張表，對該表加意向共享鎖之后，再對記錄A添加共享鎖。也就是說一個數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖
通知數(shù)據(jù)庫接下來需要施加什么鎖并對表加鎖。如果需要對記錄A加排他鎖，那么此時innodb會先找到這張表，對該表加意向排他鎖之后，再對記錄A添加共享鎖。也就是說一個數(shù)據(jù)行加排它鎖前必須先取得該表的IX鎖
共享鎖和排他鎖，系統(tǒng)在特定的條件下會自動添加共享鎖或者排他鎖，也可以手動添加共享鎖或者排他鎖。
意向共享鎖和意向排他鎖都是系統(tǒng)自動添加和自動釋放的，整個過程無需人工干預(yù)。
共享鎖和排他鎖都是鎖的行記錄，意向共享鎖和意向排他鎖鎖定的是表。
在MySQL中，行級鎖并不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引;如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關(guān)的主鍵索引。
InnoDB行鎖是通過給索引項加鎖實現(xiàn)的，如果沒有索引，InnoDB會通過隱藏的聚簇索引來對記錄加鎖。也就是說：如果不通過索引條件檢索數(shù)據(jù)，那么InnoDB將對表中所有數(shù)據(jù)加鎖，實際效果跟表鎖一樣
Record Lock:對索引項加鎖，即鎖定一條記錄。
Gap Lock:對索引項之間的 ‘間隙’ 、對第一條記錄前的間隙或最后一條記錄后的間隙加鎖，即鎖定一個范圍的記錄，不包含記錄本身
Next-key Lock:鎖定一個范圍的記錄并包含記錄本身(上面兩者的結(jié)合)
注意：InnoDB默認(rèn)級別是repeatable-read（重復(fù)讀）級別。ANSI/IOS SQL標(biāo)準(zhǔn)定義了4種事務(wù)隔離級別：未提交讀(read uncommitted)，提交讀(read committed)，重復(fù)讀(repeatable read)，串行讀(serializable)
Next-Key Lock是行鎖與間隙鎖的組合，這樣，當(dāng)InnoDB掃描索引記錄的時候，會首先對選中的索引記錄加上行鎖（Record Lock），再對索引記錄兩邊的間隙加上間隙鎖（Gap Lock）。如果一個間隙被事務(wù)T1加了鎖，其它事務(wù)是不能在這個間隙插入記錄的。
行鎖防止別的事務(wù)修改或刪除，Gap鎖防止別的事務(wù)新增，行鎖和GAP鎖結(jié)合形成的Next-Key鎖共同解決了RR界別在寫數(shù)據(jù)時的幻讀問題。
InnoDB在絕大部分情況會使用行級鎖，因為事務(wù)和行鎖往往是我們選擇InnoDB的原因，但是有些情況下我們也考慮使用表級鎖
當(dāng)事務(wù)需要更新大部分?jǐn)?shù)據(jù)時，表又比較大，如果使用默認(rèn)的行鎖，不僅效率低，而且還容易造成其他事務(wù)長時間等待和鎖沖突。
事務(wù)比較復(fù)雜，很可能引起死鎖導(dǎo)致回滾。
（１）使用LOCK TALBES雖然可以給InnoDB加表級鎖，但必須說明的是，表鎖不是由InnoDB存儲引擎層管理的，而是由其上一層ＭySQL Server負(fù)責(zé)的，僅當(dāng)autocommit=0、innodb_table_lock=1（默認(rèn)設(shè)置）時，InnoDB層才能知道MySQL加的表鎖，ＭySQL Server才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖；否則，InnoDB將無法自動檢測并處理這種死鎖。
（２）在用LOCAK TABLES對InnoDB鎖時要注意，要將AUTOCOMMIT設(shè)為0，否則ＭySQL不會給表加鎖；事務(wù)結(jié)束前，不要用UNLOCAK TABLES釋放表鎖，因為UNLOCK TABLES會隱含地提交事務(wù)；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一般都可以檢測到，并使一個事務(wù)釋放鎖回退，另一個獲取鎖完成事務(wù)。但在涉及外部鎖，或涉及鎖的情況下，InnoDB并不能完全自動檢測到死鎖，這需要通過設(shè)置鎖等待超時參數(shù)innodb_lock_wait_timeout來解決。需要說明的是，這個參數(shù)并不是只用來解決死鎖問題，在并發(fā)訪問比較高的情況下，如果大量事務(wù)因無法立即獲取所需的鎖而掛起，會占用大量計算機資源，造成嚴(yán)重性能問題，甚至拖垮數(shù)據(jù)庫。我們通過設(shè)置合適的鎖等待超時閾值，可以避免這種情況發(fā)生。
如果不同程序會并發(fā)存取多個表，盡量約定以相同的順序訪問表，可以大大降低死鎖機會。如果兩個session訪問兩個表的順序不同，發(fā)生死鎖的機會就非常高！但如果以相同的順序來訪問，死鎖就可能避免。
在同一個事務(wù)中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產(chǎn)生概率。
對于非常容易產(chǎn)生死鎖的業(yè)務(wù)部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產(chǎn)生的概。
在程序以批量方式處理數(shù)據(jù)的時候，如果事先對數(shù)據(jù)排序，保證每個線程按固定的順序來處理記錄，也可以大大降低死鎖的可能。
在REPEATEABLE-READ隔離級別下，如果兩個線程同時對相同條件記錄用SELECT...ROR UPDATE加排他鎖，在沒有符合該記錄情況下，兩個線程都會加鎖成功。程序發(fā)現(xiàn)記錄尚不存在，就試圖插入一條新記錄，如果兩個線程都這么做，就會出現(xiàn)死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可以避免問題。
當(dāng)隔離級別為READ COMMITED時，如果兩個線程都先執(zhí)行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個線程能插入成功，另一個線程會出現(xiàn)鎖等待，當(dāng)?shù)冢眰€線程提交后，第２個線程會因主鍵重出錯，但雖然這個線程出錯了，卻會獲得一個排他鎖！這時如果有第３個線程又來申請排他鎖，也會出現(xiàn)死鎖。對于這種情況，可以直接做插入操作，然后再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執(zhí)行ROLLBACK釋放獲得的排他鎖
ps:如果出現(xiàn)死鎖，可以用SHOW INNODB STATUS命令來確定最后一個死鎖產(chǎn)生的原因和改進(jìn)措施。
對于InnoDB表，主要有以下幾點
（１）InnoDB的行銷是基于索引實現(xiàn)的，如果不通過索引訪問數(shù)據(jù)，InnoDB會使用表鎖。
（２）InnoDB間隙鎖機制，以及InnoDB使用間隙鎖的原因。
（３）在不同的隔離級別下，InnoDB的鎖機制和一致性讀策略不同。
（４）ＭySQL的恢復(fù)和復(fù)制對InnoDB鎖機制和一致性讀策略也有較大影響。
（５）鎖沖突甚至死鎖很難完全避免。
在了解InnoDB的鎖特性后，用戶可以通過設(shè)計和SQL調(diào)整等措施減少鎖沖突和死鎖，包括：
盡量使用較低的隔離級別
精心設(shè)計索引，并盡量使用索引訪問數(shù)據(jù)，使加鎖更精確，從而減少鎖沖突的機會。
選擇合理的事務(wù)大小，小事務(wù)發(fā)生鎖沖突的幾率也更小。
給記錄集顯示加鎖時，最好一次性請求足夠級別的鎖。比如要修改數(shù)據(jù)的話，最好直接申請排他鎖，而不是先申請共享鎖，修改時再請求排他鎖，這樣容易產(chǎn)生死鎖。
不同的程序訪問一組表時，應(yīng)盡量約定以相同的順序訪問各表，對一個表而言，盡可能以固定的順序存取表中的行。這樣可以大減少死鎖的機會。
盡量用相等條件訪問數(shù)據(jù)，這樣可以避免間隙鎖對并發(fā)插入的影響。
不要申請超過實際需要的鎖級別；除非必須，查詢時不要顯示加鎖。
對于一些特定的事務(wù)，可以使用表鎖來提高處理速度或減少死鎖的可能。
對于上文關(guān)于mysql中innoDB鎖有什么主要作用，大家覺得是自己想要的嗎？如果想要了解更多相關(guān)，可以繼續(xù)關(guān)注我們的行業(yè)資訊板塊。
重慶分公司
重慶分公司
