MySQL中的鎖（表鎖详囤、行鎖）

?鎖是計算機協(xié)調(diào)多個進程或純線程并發(fā)訪問某一資源的機制。在數(shù)據(jù)庫中渣蜗，除傳統(tǒng)的計算資源（CPU屠尊、RAM、I/O）的爭用以外耕拷，數(shù)據(jù)也是一種供許多用戶共享的資源讼昆。如何保證數(shù)據(jù)并發(fā)訪問的一致性、有效性是所在有數(shù)據(jù)庫必須解決的一個問題骚烧，鎖沖突也是影響數(shù)據(jù)庫并發(fā)訪問性能的一個重要因素浸赫。從這個角度來說，鎖對數(shù)據(jù)庫而言顯得尤其重要赃绊，也更加復(fù)雜既峡。

概述

相對其他數(shù)據(jù)庫而言，MySQL的鎖機制比較簡單碧查，其最顯著的特點是不同的存儲引擎支持不同的鎖機制运敢。

MySQL大致可歸納為以下3種鎖：

表級鎖：開銷小，加鎖快忠售；不會出現(xiàn)死鎖传惠；鎖定粒度大，發(fā)生鎖沖突的概率最高稻扬，并發(fā)度最低涉枫。

行級鎖：開銷大，加鎖慢腐螟；會出現(xiàn)死鎖愿汰；鎖定粒度最小，發(fā)生鎖沖突的概率最低乐纸，并發(fā)度也最高衬廷。

頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現(xiàn)死鎖汽绢；鎖定粒度界于表鎖和行鎖之間吗跋，并發(fā)度一般

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

MySQL表級鎖的鎖模式（MyISAM)

MySQL表級鎖有兩種模式：表共享鎖（Table Read Lock）和表獨占寫鎖（Table Write Lock）。

對MyISAM的讀操作宁昭，不會阻塞其他用戶對同一表請求跌宛，但會阻塞對同一表的寫請求；

對MyISAM的寫操作积仗，則會阻塞其他用戶對同一表的讀和寫操作疆拘；

MyISAM表的讀操作和寫操作之間，以及寫操作之間是串行的寂曹。

當(dāng)一個線程獲得對一個表的寫鎖后哎迄，只有持有鎖線程可以對表進行更新操作回右。其他線程的讀、寫操作都會等待漱挚，直到鎖被釋放為止翔烁。

MySQL表級鎖的鎖模式

? ? ＭySQL的表鎖有兩種模式：表共享讀鎖（Table Read Lock）和表獨占寫鎖（Table Write Lock）。鎖模式的兼容如下表

ＭySQL中的表鎖兼容性

當(dāng)前鎖模式/是否兼容/請求鎖模式None讀鎖寫鎖

讀鎖是是否

寫鎖是否否

可見旨涝，對ＭyISAM表的讀操作蹬屹，不會阻塞其他用戶對同一表的讀請求，但會阻塞對同一表的寫請求白华；對ＭyISAM表的寫操作哩治，則會阻塞其他用戶對同一表的讀和寫請求；ＭyISAM表的讀和寫操作之間衬鱼，以及寫和寫操作之間是串行的Ｒ捣ぁ（當(dāng)一線程獲得對一個表的寫鎖后，只有持有鎖的線程可以對表進行更新操作鸟赫。其他線程的讀蒜胖、寫操作都會等待，直到鎖被釋放為止抛蚤。）

如何加表鎖

MyISAM在執(zhí)行查詢語句（SELECT）前台谢，會自動給涉及的所有表加讀鎖，在執(zhí)行更新操作（UPDATE岁经、DELETE朋沮、INSERT等）前，會自動給涉及的表加寫鎖缀壤，這個過程并不需要用戶干預(yù)樊拓，因此用戶一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在本書的示例中塘慕，顯式加鎖基本上都是為了方便而已筋夏，并非必須如此。

? ? 給MyISAM表顯示加鎖图呢，一般是為了一定程度模擬事務(wù)操作条篷，實現(xiàn)對某一時間點多個表的一致性讀取。例如蛤织，有一個訂單表orders赴叹，其中記錄有訂單的總金額total，同時還有一個訂單明細表order_detail指蚜，其中記錄有訂單每一產(chǎn)品的金額小計subtotal乞巧，假設(shè)我們需要檢查這兩個表的金額合計是否相等，可能就需要執(zhí)行如下兩條SQL：

SELECT?SUM(total)?FROM?orders;

SELECT?SUM(subtotal)?FROM?order_detail;

這時姚炕，如果不先給這兩個表加鎖摊欠，就可能產(chǎn)生錯誤的結(jié)果丢烘，因為第一條語句執(zhí)行過程中柱宦，order_detail表可能已經(jīng)發(fā)生了改變些椒。因此，正確的方法應(yīng)該是：

LOCK tables orders?read?local,order_detail?read?local;

SELECT?SUM(total)?FROM?orders;

SELECT?SUM(subtotal)?FROM?order_detail;

Unlock tables;

要特別說明以下兩點內(nèi)容掸刊。

上面的例子在LOCK TABLES時加了‘local’選項免糕，其作用就是在滿足MyISAM表并發(fā)插入條件的情況下，允許其他用戶在表尾插入記錄

在用LOCKTABLES給表顯式加表鎖是時忧侧，必須同時取得所有涉及表的鎖石窑，并且MySQL支持鎖升級。也就是說蚓炬，在執(zhí)行LOCK TABLES后松逊，只能訪問顯式加鎖的這些表，不能訪問未加鎖的表肯夏；同時经宏，如果加的是讀鎖，那么只能執(zhí)行查詢操作驯击，而不能執(zhí)行更新操作烁兰。其實，在自動加鎖的情況下也基本如此徊都，MySQL問題一次獲得SQL語句所需要的全部鎖沪斟。這也正是MyISAM表不會出現(xiàn)死鎖（Deadlock Free）的原因

一個session使用LOCK TABLE 命令給表film_text加了讀鎖，這個session可以查詢鎖定表中的記錄暇矫，但更新或訪問其他表都會提示錯誤主之；同時，另外一個session可以查詢表中的記錄李根，但更新就會出現(xiàn)鎖等待杀餐。

當(dāng)使用LOCK TABLE時，不僅需要一次鎖定用到的所有表朱巨，而且史翘，同一個表在SQL語句中出現(xiàn)多少次，就要通過與SQL語句中相同的別名鎖多少次冀续，否則也會出錯琼讽！

并發(fā)鎖

? ? 在一定條件下，MyISAM也支持查詢和操作的并發(fā)進行洪唐。

? ??MyISAM存儲引擎有一個系統(tǒng)變量concurrent_insert钻蹬，專門用以控制其并發(fā)插入的行為，其值分別可以為0凭需、1或2问欠。

當(dāng)concurrent_insert設(shè)置為0時肝匆，不允許并發(fā)插入。

當(dāng)concurrent_insert設(shè)置為1時顺献，如果MyISAM允許在一個讀表的同時旗国，另一個進程從表尾插入記錄。這也是MySQL的默認(rèn)設(shè)置注整。

當(dāng)concurrent_insert設(shè)置為2時能曾，無論MyISAM表中有沒有空洞，都允許在表尾插入記錄肿轨，都允許在表尾并發(fā)插入記錄寿冕。

可以利用MyISAM存儲引擎的并發(fā)插入特性，來解決應(yīng)用中對同一表查詢和插入鎖爭用椒袍。例如驼唱，將concurrent_insert系統(tǒng)變量為2，總是允許并發(fā)插入驹暑；同時玫恳，通過定期在系統(tǒng)空閑時段執(zhí)行OPTIONMIZE TABLE語句來整理空間碎片，收到因刪除記錄而產(chǎn)生的中間空洞岗钩。

MyISAM的鎖調(diào)度

前面講過纽窟，MyISAM存儲引擎的讀和寫鎖是互斥，讀操作是串行的兼吓。那么臂港，一個進程請求某個MyISAM表的讀鎖，同時另一個進程也請求同一表的寫鎖视搏，MySQL如何處理呢审孽？答案是寫進程先獲得鎖。不僅如此浑娜，即使讀進程先請求先到鎖等待隊列佑力，寫請求后到，寫鎖也會插到讀請求之前筋遭！這是因為MySQL認(rèn)為寫請求一般比讀請求重要打颤。這也正是MyISAM表不太適合于有大量更新操作和查詢操作應(yīng)用的原因，因為漓滔，大量的更新操作會造成查詢操作很難獲得讀鎖编饺，從而可能永遠阻塞。這種情況有時可能會變得非常糟糕响驴！幸好我們可以通過一些設(shè)置來調(diào)節(jié)MyISAM的調(diào)度行為透且。

通過指定啟動參數(shù)low-priority-updates，使MyISAM引擎默認(rèn)給予讀請求以優(yōu)先的權(quán)利豁鲤。

通過執(zhí)行命令SET LOW_PRIORITY_UPDATES=1秽誊，使該連接發(fā)出的更新請求優(yōu)先級降低鲸沮。

通過指定INSERT、UPDATE锅论、DELETE語句的LOW_PRIORITY屬性讼溺，降低該語句的優(yōu)先級。

雖然上面3種方法都是要么更新優(yōu)先棍厌，要么查詢優(yōu)先的方法肾胯，但還是可以用其來解決查詢相對重要的應(yīng)用（如用戶登錄系統(tǒng)）中竖席，讀鎖等待嚴(yán)重的問題耘纱。

另外，MySQL也提供了一種折中的辦法來調(diào)節(jié)讀寫沖突毕荐，即給系統(tǒng)參數(shù)max_write_lock_count設(shè)置一個合適的值束析，當(dāng)一個表的讀鎖達到這個值后，MySQL變暫時將寫請求的優(yōu)先級降低憎亚，給讀進程一定獲得鎖的機會员寇。

? ? 上面已經(jīng)討論了寫優(yōu)先調(diào)度機制和解決辦法妹懒。這里還要強調(diào)一點：一些需要長時間運行的查詢操作极阅，也會使寫進程“餓死”！因此言秸，應(yīng)用中應(yīng)盡量避免出現(xiàn)長時間運行的查詢操作什往，不要總想用一條SELECT語句來解決問題扳缕。因為這種看似巧妙的SQL語句，往往比較復(fù)雜别威，執(zhí)行時間較長躯舔，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的“分解”，使每一步查詢都能在較短時間完成省古，從而減少鎖沖突粥庄。如果復(fù)雜查詢不可避免，應(yīng)盡量安排在數(shù)據(jù)庫空閑時段執(zhí)行豺妓，比如一些定期統(tǒng)計可以安排在夜間執(zhí)行惜互。

InnoDB鎖問題

? ? InnoDB與MyISAM的最大不同有兩點：一是支持事務(wù)（TRANSACTION）；二是采用了行級鎖琳拭。

行級鎖和表級鎖本來就有許多不同之處训堆，另外，事務(wù)的引入也帶來了一些新問題臀栈。

1.事務(wù)（Transaction）及其ACID屬性

? ? 事務(wù)是由一組SQL語句組成的邏輯處理單元蔫慧，事務(wù)具有4屬性，通常稱為事務(wù)的ACID屬性权薯。

原性性（Actomicity）：事務(wù)是一個原子操作單元姑躲，其對數(shù)據(jù)的修改睡扬，要么全都執(zhí)行，要么全都不執(zhí)行黍析。

一致性（Consistent）：在事務(wù)開始和完成時卖怜，數(shù)據(jù)都必須保持一致狀態(tài)。這意味著所有相關(guān)的數(shù)據(jù)規(guī)則都必須應(yīng)用于事務(wù)的修改阐枣，以操持完整性马靠；事務(wù)結(jié)束時，所有的內(nèi)部數(shù)據(jù)結(jié)構(gòu)（如B樹索引或雙向鏈表）也都必須是正確的蔼两。

隔離性（Isolation）：數(shù)據(jù)庫系統(tǒng)提供一定的隔離機制甩鳄，保證事務(wù)在不受外部并發(fā)操作影響的“獨立”環(huán)境執(zhí)行。這意味著事務(wù)處理過程中的中間狀態(tài)對外部是不可見的额划，反之亦然妙啃。

持久性（Durable）：事務(wù)完成之后，它對于數(shù)據(jù)的修改是永久性的俊戳，即使出現(xiàn)系統(tǒng)故障也能夠保持揖赴。

2.并發(fā)事務(wù)帶來的問題

? ? 相對于串行處理來說，并發(fā)事務(wù)處理能大大增加數(shù)據(jù)庫資源的利用率抑胎，提高數(shù)據(jù)庫系統(tǒng)的事務(wù)吞吐量燥滑，從而可以支持可以支持更多的用戶。但并發(fā)事務(wù)處理也會帶來一些問題阿逃，主要包括以下幾種情況铭拧。

更新丟失（Lost Update）：當(dāng)兩個或多個事務(wù)選擇同一行，然后基于最初選定的值更新該行時盆昙，由于每個事務(wù)都不知道其他事務(wù)的存在羽历，就會發(fā)生丟失更新問題——最后的更新覆蓋了其他事務(wù)所做的更新。例如淡喜，兩個編輯人員制作了同一文檔的電子副本秕磷。每個編輯人員獨立地更改其副本，然后保存更改后的副本炼团，這樣就覆蓋了原始文檔澎嚣。最后保存其更改保存其更改副本的編輯人員覆蓋另一個編輯人員所做的修改。如果在一個編輯人員完成并提交事務(wù)之前瘟芝，另一個編輯人員不能訪問同一文件易桃，則可避免此問題

臟讀（Dirty Reads）：一個事務(wù)正在對一條記錄做修改，在這個事務(wù)并提交前锌俱，這條記錄的數(shù)據(jù)就處于不一致狀態(tài)晤郑；這時，另一個事務(wù)也來讀取同一條記錄，如果不加控制造寝，第二個事務(wù)讀取了這些“臟”的數(shù)據(jù)磕洪，并據(jù)此做進一步的處理，就會產(chǎn)生未提交的數(shù)據(jù)依賴關(guān)系诫龙。這種現(xiàn)象被形象地叫做“臟讀”析显。

不可重復(fù)讀（Non-Repeatable Reads）：一個事務(wù)在讀取某些數(shù)據(jù)已經(jīng)發(fā)生了改變、或某些記錄已經(jīng)被刪除了签赃！這種現(xiàn)象叫做“不可重復(fù)讀”谷异。

幻讀（Phantom Reads）：一個事務(wù)按相同的查詢條件重新讀取以前檢索過的數(shù)據(jù)，卻發(fā)現(xiàn)其他事務(wù)插入了滿足其查詢條件的新數(shù)據(jù)锦聊，這種現(xiàn)象就稱為“幻讀”歹嘹。

3.事務(wù)隔離級別

在并發(fā)事務(wù)處理帶來的問題中，“更新丟失”通常應(yīng)該是完全避免的括丁。但防止更新丟失荞下，并不能單靠數(shù)據(jù)庫事務(wù)控制器來解決伶选，需要應(yīng)用程序?qū)σ碌臄?shù)據(jù)加必要的鎖來解決史飞，因此，防止更新丟失應(yīng)該是應(yīng)用的責(zé)任仰税。

“臟讀”构资、“不可重復(fù)讀”和“幻讀”，其實都是數(shù)據(jù)庫讀一致性問題陨簇，必須由數(shù)據(jù)庫提供一定的事務(wù)隔離機制來解決吐绵。數(shù)據(jù)庫實現(xiàn)事務(wù)隔離的方式，基本可以分為以下兩種河绽。

一種是在讀取數(shù)據(jù)前己单，對其加鎖，阻止其他事務(wù)對數(shù)據(jù)進行修改耙饰。

另一種是不用加任何鎖纹笼，通過一定機制生成一個數(shù)據(jù)請求時間點的一致性數(shù)據(jù)快照（Snapshot），并用這個快照來提供一定級別（語句級或事務(wù)級）的一致性讀取苟跪。從用戶的角度廷痘，好像是數(shù)據(jù)庫可以提供同一數(shù)據(jù)的多個版本，因此件已，這種技術(shù)叫做數(shù)據(jù)多版本并發(fā)控制（ＭultiVersion Concurrency Control笋额，簡稱MVCC或MCC），也經(jīng)常稱為多版本數(shù)據(jù)庫篷扩。

? ? 數(shù)據(jù)庫的事務(wù)隔離級別越嚴(yán)格兄猩，并發(fā)副作用越小，但付出的代價也就越大，因為事務(wù)隔離實質(zhì)上就是使事務(wù)在一定程度上“串行化”進行枢冤，這顯然與“并發(fā)”是矛盾的援岩，同時，不同的應(yīng)用對讀一致性和事務(wù)隔離程度的要求也是不同的掏导，比如許多應(yīng)用對“不可重復(fù)讀”和“幻讀”并不敏感享怀，可能更關(guān)心數(shù)據(jù)并發(fā)訪問的能力。

? ? 為了解決“隔離”與“并發(fā)”的矛盾趟咆，ISO/ANSI SQL92定義了４個事務(wù)隔離級別添瓷，每個級別的隔離程度不同，允許出現(xiàn)的副作用也不同值纱，應(yīng)用可以根據(jù)自己業(yè)務(wù)邏輯要求鳞贷，通過選擇不同的隔離級別來平衡＂隔離＂與＂并發(fā)＂的矛盾

事務(wù)４種隔離級別比較

隔離級別/讀數(shù)據(jù)一致性及允許的并發(fā)副作用讀數(shù)據(jù)一致性臟讀不可重復(fù)讀幻讀

未提交讀（Read uncommitted）最低級別，只能保證不讀取物理上損壞的數(shù)據(jù)是是是

已提交度（Read committed）語句級否是是

可重復(fù)讀（Repeatable read）事務(wù)級否否是

可序列化（Serializable）最高級別虐唠，事務(wù)級否否否

? ? 最后要說明的是：各具體數(shù)據(jù)庫并不一定完全實現(xiàn)了上述４個隔離級別搀愧，例如，Oracle只提供Read committed和Serializable兩個標(biāo)準(zhǔn)級別疆偿，另外還自己定義的Read only隔離級別：SQL Server除支持上述ISO/ANSI SQL92定義的４個級別外咱筛，還支持一個叫做＂快照＂的隔離級別，但嚴(yán)格來說它是一個用MVCC實現(xiàn)的Serializable隔離級別杆故。ＭySQL支持全部４個隔離級別迅箩，但在具體實現(xiàn)時，有一些特點处铛，比如在一些隔離級下是采用MVCC一致性讀饲趋，但某些情況又不是。

獲取InonoD行鎖爭用情況

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

mysql> show status?like?'innodb_row_lock%';

+-------------------------------+-------+

| Variable_name | Value |

+-------------------------------+-------+

| Innodb_row_lock_current_waits | 0 |

| Innodb_row_lock_time | 0 |

| Innodb_row_lock_time_avg | 0 |

| Innodb_row_lock_time_max | 0 |

| Innodb_row_lock_waits | 0 |

+-------------------------------+-------+

5?rows?in?set?(0.00 sec)

? ? 如果發(fā)現(xiàn)爭用比較嚴(yán)重撤蟆，如Innodb_row_lock_waits和Innodb_row_lock_time_avg的值比較高奕塑，還可以通過設(shè)置InnoDB Monitors來進一步觀察發(fā)生鎖沖突的表、數(shù)據(jù)行等家肯，并分析鎖爭用的原因龄砰。

InnoDB的行鎖模式及加鎖方法

InnoDB實現(xiàn)了以下兩種類型的行鎖。

共享鎖（s）：允許一個事務(wù)去讀一行息楔，阻止其他事務(wù)獲得相同數(shù)據(jù)集的排他鎖寝贡。

排他鎖（Ｘ）：允許獲取排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同的數(shù)據(jù)集共享讀鎖和排他寫鎖值依。

另外圃泡，為了允許行鎖和表鎖共存，實現(xiàn)多粒度鎖機制愿险，InnoDB還有兩種內(nèi)部使用的意向鎖（Intention Locks）颇蜡，這兩種意向鎖都是表鎖价说。

意向共享鎖（IS）：事務(wù)打算給數(shù)據(jù)行共享鎖，事務(wù)在給一個數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖风秤。

意向排他鎖（IX）：事務(wù)打算給數(shù)據(jù)行加排他鎖鳖目，事務(wù)在給一個數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖。

InnoDB行鎖模式兼容性列表

當(dāng)前鎖模式/是否兼容/請求鎖模式XIXSIS

X沖突沖突沖突沖突

IX沖突兼容沖突兼容

S沖突沖突兼容兼容

IS沖突兼容兼容兼容

? ??如果一個事務(wù)請求的鎖模式與當(dāng)前的鎖兼容缤弦，InnoDB就請求的鎖授予該事務(wù)领迈；反之，如果兩者兩者不兼容碍沐，該事務(wù)就要等待鎖釋放狸捅。

? ? 意向鎖是InnoDB自動加的，不需用戶干預(yù)累提。對于UPDATE尘喝、DELETE和INSERT語句，InnoDB會自動給涉及及數(shù)據(jù)集加排他鎖（Ｘ）斋陪；對于普通SELECT語句朽褪，InnoDB會自動給涉及數(shù)據(jù)集加排他鎖（Ｘ）；對于普通SELECT語句无虚，InnoDB不會任何鎖缔赠；事務(wù)可以通過以下語句顯示給記錄集加共享鎖或排鎖。

共享鎖（Ｓ）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE

排他鎖（X）：SELECT * FROM table_name WHERE ...?FOR UPDATE

? ? 用SELECT .. IN SHARE MODE獲得共享鎖骑科，主要用在需要數(shù)據(jù)依存關(guān)系時確認(rèn)某行記錄是否存在橡淑，并確保沒有人對這個記錄進行UPDATE或者DELETE操作。但是如果當(dāng)前事務(wù)也需要對該記錄進行更新操作咆爽，則很有可能造成死鎖，對于鎖定行記錄后需要進行更新操作的應(yīng)用置森，應(yīng)該使用SELECT ... FOR UPDATE方式獲取排他鎖斗埂。

InnoDB行鎖實現(xiàn)方式

? ??InnoDB行鎖是通過索引上的索引項來實現(xiàn)的，這一點ＭySQL與Oracle不同凫海，后者是通過在數(shù)據(jù)中對相應(yīng)數(shù)據(jù)行加鎖來實現(xiàn)的呛凶。InnoDB這種行鎖實現(xiàn)特點意味者：只有通過索引條件檢索數(shù)據(jù)，InnoDB才會使用行級鎖行贪，否則漾稀，InnoDB將使用表鎖！

? ? 在實際應(yīng)用中建瘫，要特別注意InnoDB行鎖的這一特性崭捍，不然的話，可能導(dǎo)致大量的鎖沖突啰脚，從而影響并發(fā)性能殷蛇。

間隙鎖（Next-Key鎖）

? ? 當(dāng)我們用范圍條件而不是相等條件檢索數(shù)據(jù)，并請求共享或排他鎖時，InnoDB會給符合條件的已有數(shù)據(jù)的索引項加鎖粒梦；對于鍵值在條件范圍內(nèi)但并不存在的記錄亮航，叫做“間隙(GAP)”，InnoDB也會對這個“間隙”加鎖匀们，這種鎖機制不是所謂的間隙鎖（Next-Key鎖）缴淋。

? ? 舉例來說，假如emp表中只有101條記錄泄朴，其empid的值分別是1,2,...,100,101宴猾，下面的SQL：

SELECT?*?FROM emp WHERE empid?>?100?FOR UPDATE

是一個范圍條件的檢索，InnoDB不僅會對符合條件的empid值為101的記錄加鎖叼旋，也會對empid大于101（這些記錄并不存在）的“間隙”加鎖仇哆。

? ??InnoDB使用間隙鎖的目的，一方面是為了防止幻讀夫植，以滿足相關(guān)隔離級別的要求讹剔，對于上面的例子，要是不使用間隙鎖详民，如果其他事務(wù)插入了empid大于100的任何記錄延欠，那么本事務(wù)如果再次執(zhí)行上述語句，就會發(fā)生幻讀沈跨；另一方面由捎，是為了滿足其恢復(fù)和復(fù)制的需要。有關(guān)其恢復(fù)和復(fù)制對機制的影響饿凛，以及不同隔離級別下InnoDB使用間隙鎖的情況狞玛。

? ? 很顯然，在使用范圍條件檢索并鎖定記錄時涧窒，InnoDB這種加鎖機制會阻塞符合條件范圍內(nèi)鍵值的并發(fā)插入心肪，這往往會造成嚴(yán)重的鎖等待。因此纠吴，在實際開發(fā)中硬鞍，尤其是并發(fā)插入比較多的應(yīng)用，我們要盡量優(yōu)化業(yè)務(wù)邏輯戴已，盡量使用相等條件來訪問更新數(shù)據(jù)固该，避免使用范圍條件。

什么時候使用表鎖

? ? 對于InnoDB表糖儡，在絕大部分情況下都應(yīng)該使用行級鎖伐坏，因為事務(wù)和行鎖往往是我們之所以選擇InnoDB表的理由。但在個另特殊事務(wù)中休玩，也可以考慮使用表級鎖著淆。

第一種情況是：事務(wù)需要更新大部分或全部數(shù)據(jù)劫狠，表又比較大，如果使用默認(rèn)的行鎖永部，不僅這個事務(wù)執(zhí)行效率低独泞，而且可能造成其他事務(wù)長時間鎖等待和鎖沖突，這種情況下可以考慮使用表鎖來提高該事務(wù)的執(zhí)行速度苔埋。

第二種情況是：事務(wù)涉及多個表懦砂，比較復(fù)雜，很可能引起死鎖组橄，造成大量事務(wù)回滾荞膘。這種情況也可以考慮一次性鎖定事務(wù)涉及的表，從而避免死鎖玉工、減少數(shù)據(jù)庫因事務(wù)回滾帶來的開銷羽资。

當(dāng)然，應(yīng)用中這兩種事務(wù)不能太多遵班，否則屠升，就應(yīng)該考慮使用ＭyISAＭ表。

? ? 在InnoDB下狭郑，使用表鎖要注意以下兩點腹暖。

? ? （１）使用LOCK TALBES雖然可以給InnoDB加表級鎖，但必須說明的是翰萨，表鎖不是由InnoDB存儲引擎層管理的脏答，而是由其上一層ＭySQL Server負責(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產(chǎn)不能釋放用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;

關(guān)于死鎖

? ? ＭyISAM表鎖是deadlock free的墓懂，這是因為ＭyISAM總是一次性獲得所需的全部鎖，要么全部滿足霉囚，要么等待捕仔，因此不會出現(xiàn)死鎖。但是在InnoDB中盈罐，除單個SQL組成的事務(wù)外榜跌，鎖是逐步獲得的，這就決定了InnoDB發(fā)生死鎖是可能的盅粪。

? ? 發(fā)生死鎖后钓葫，InnoDB一般都能自動檢測到，并使一個事務(wù)釋放鎖并退回票顾，另一個事務(wù)獲得鎖础浮，繼續(xù)完成事務(wù)。但在涉及外部鎖库物，或涉及鎖的情況下霸旗，InnoDB并不能完全自動檢測到死鎖，這需要通過設(shè)置鎖等待超時參數(shù)innodb_lock_wait_timeout來解決戚揭。需要說明的是诱告，這個參數(shù)并不是只用來解決死鎖問題，在并發(fā)訪問比較高的情況下民晒，如果大量事務(wù)因無法立即獲取所需的鎖而掛起精居，會占用大量計算機資源，造成嚴(yán)重性能問題潜必，甚至拖垮數(shù)據(jù)庫靴姿。我們通過設(shè)置合適的鎖等待超時閾值，可以避免這種情況發(fā)生磁滚。

? ? 通常來說佛吓，死鎖都是應(yīng)用設(shè)計的問題，通過調(diào)整業(yè)務(wù)流程垂攘、數(shù)據(jù)庫對象設(shè)計维雇、事務(wù)大小、以及訪問數(shù)據(jù)庫的SQL語句晒他，絕大部分都可以避免吱型。下面就通過實例來介紹幾種死鎖的常用方法。

? ? （１）在應(yīng)用中陨仅，如果不同的程序會并發(fā)存取多個表津滞，應(yīng)盡量約定以相同的順序為訪問表铝侵，這樣可以大大降低產(chǎn)生死鎖的機會。如果兩個session訪問兩個表的順序不同触徐，發(fā)生死鎖的機會就非常高咪鲜！但如果以相同的順序來訪問，死鎖就可能避免锌介。

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

? ? （３）在事務(wù)中，如果要更新記錄崔慧，應(yīng)該直接申請足夠級別的鎖拂蝎，即排他鎖，而不應(yīng)該先申請共享鎖惶室，更新時再申請排他鎖温自，甚至死鎖。

? ? （４）在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釋放獲得的排他鎖。

? ? 盡管通過上面的設(shè)計和優(yōu)化等措施叠穆，可以大減少死鎖少漆，但死鎖很難完全避免。因此硼被，在程序設(shè)計中總是捕獲并處理死鎖異常是一個很好的編程習(xí)慣示损。

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

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

總結(jié)

對于ＭyISAM的表鎖检访，主要有以下幾點

? ? （１）共享讀鎖（S）之間是兼容的，但共享讀鎖（S）和排他寫鎖（X）之間仔掸，以及排他寫鎖之間（X）是互斥的脆贵，也就是說讀和寫是串行的。

? ? （２）在一定條件下起暮，ＭyISAM允許查詢和插入并發(fā)執(zhí)行卖氨，我們可以利用這一點來解決應(yīng)用中對同一表和插入的鎖爭用問題。

? ? （３）ＭyISAM默認(rèn)的鎖調(diào)度機制是寫優(yōu)先鞋怀，這并不一定適合所有應(yīng)用双泪，用戶可以通過設(shè)置LOW_PRIPORITY_UPDATES參數(shù)，或在INSERT密似、UPDATE焙矛、DELETE語句中指定LOW_PRIORITY選項來調(diào)節(jié)讀寫鎖的爭用。

? ? （４）由于表鎖的鎖定粒度大残腌，讀寫之間又是串行的村斟，因此，如果更新操作較多抛猫，ＭyISAM表可能會出現(xiàn)嚴(yán)重的鎖等待蟆盹，可以考慮采用InnoDB表來減少鎖沖突。

? ? 對于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ù)湿滓，可以使用表鎖來提高處理速度或減少死鎖的可能。

https://www.cnblogs.com/lxwphp/p/9920665.html

MySQL中的鎖（表鎖蛹头、行鎖）

MySQL中的鎖（表鎖、行鎖）