一、InnoDB的表級鎖

在絕大多數(shù)情況下應(yīng)該使用行鎖，因為事務(wù)和行鎖往往是選擇InnoDB的理由，但個別情況下也使用表級鎖。

事務(wù)需要更新大部分或全部數(shù)據(jù)，表又比較大，如果使用默認的行鎖，不僅這個事務(wù)執(zhí)行效率低，而且可能造成其他事務(wù)長時間等待和鎖沖突事務(wù)涉及多個表，比較復雜，很可能引起死鎖，造成大量事務(wù)回滾

我們希望獲取表鎖時，執(zhí)行以下命令：

在使用表鎖的時候，涉及的效率問題：
要獲取一張表的共享鎖S或者排它鎖X，首先要確定這張表沒有被其它事務(wù)獲取過X鎖，這張表里面的數(shù)據(jù)沒有被其它事務(wù)獲取過行鎖X鎖。

假如我們這張表有一千萬個數(shù)據(jù)，怎么判斷這一千萬個數(shù)據(jù)哪些行有X鎖？
如果想獲得表的S鎖，就需要判斷表里面哪些行有過X鎖，如果有一些行有過X鎖，那么就不能獲取這張表的S鎖或者X鎖。除了挨個檢查，沒有更好的辦法，這就導致效率低下的問題

由于需要加表鎖而去挨個遍歷數(shù)據(jù)，確定是否有某些數(shù)據(jù)被加了行鎖，而導致的效率低下問題。我們這里學習的意向共享鎖和意向排他鎖就可以解決，當要獲取表的X鎖是，不需要再檢查表中的哪些行鎖被（X或者S）占用，只需要快速檢查IX和IS鎖即可。

二、意向共享鎖和意向排它鎖

• 意向共享鎖（IS鎖）：事務(wù)計劃給記錄加行共享鎖，事務(wù)在給一行記錄加共享鎖前，必須先取得該表的IS鎖
• 意向排他鎖（IX鎖）：事務(wù)計劃給記錄加行排他鎖，事務(wù)在給一行記錄加排他鎖前，必須先取得該表的IX鎖

• 在加行鎖之前，由InnoDB存儲引擎加上表的IS或IX鎖
• 意向鎖之間都是兼容的，不會產(chǎn)生沖突，主要是為了輔助其他的在獲取表鎖的時候加快效率
• 意向鎖存在的意義是為了更高效的獲取表鎖（表格中的X和S指的是表鎖，不是行鎖?。?/li>
• 意向鎖是表級鎖，協(xié)調(diào)表鎖和行鎖的共存關(guān)系。主要目的是顯示事務(wù)正在鎖定某行或者試圖鎖定某行。

分析事務(wù)1獲取行X鎖和事務(wù)2獲取表S鎖：

首先事務(wù)1需要給表的第10行數(shù)據(jù)加X鎖，于是InnoDB存儲引擎自動給整張表加上了IX鎖。當事務(wù)2再想獲取整張表的S鎖時，看到這張表已經(jīng)有別的事務(wù)獲取了IX鎖了，就說明這張表肯定有某些數(shù)據(jù)被加上了X鎖，這就導致事務(wù)2不能給整張表加S鎖了。此時事務(wù)2只能等待，無法成功獲取表S鎖

三、死鎖

1. 數(shù)據(jù)庫中的死鎖

MyISAM表鎖時deadlock free的，這是因為MyISAM 不支持事務(wù)，只支持表鎖，總是一次獲得所需的全部鎖，要么全部滿足，要么等待，因此不會出現(xiàn)死鎖。但在InnoDB中，除單個SQL組成的事務(wù)外，鎖是逐步獲得的，即鎖的粒度比較小，這就決定了在InnoDB中發(fā)生死鎖是可能的。當然如果處理多張表，還是有可能出現(xiàn)死鎖的。

死鎖問題一般都是我們自己造成的，和多線程編程的死鎖情況相似，大部分都是由于我們多個線程在獲取多個鎖資源的時候，獲取的順序不同而導致的死鎖問題。因此我們應(yīng)用在對數(shù)據(jù)庫的多個表做更新的時候，不同的代碼段，應(yīng)對這些表按相同的順序進行更新操作，以防止鎖沖突導致死鎖問題。

2. 死鎖場景以及解決方法

死鎖出現(xiàn)的場景如下：

事務(wù)1成功獲取行鎖1
事務(wù)2成功獲取行鎖2
…
事務(wù)1無法獲取行鎖2，被阻塞的同時沒有辦法執(zhí)行commit/rollback，無法釋放行鎖1
事務(wù)2無法獲取行鎖1，被阻塞的同時沒有辦法執(zhí)行commit/rollback，無法釋放行鎖2

所有的事務(wù)都阻塞了，相當于進程內(nèi)的所有線程都阻塞了，造成了死鎖問題。

解決死鎖的方法：多個事務(wù)/線程獲取多個相同資源鎖的時候，應(yīng)該按照同樣的順序，獲取資源的鎖。

事務(wù)被阻塞或者死鎖了，mysqld（MySQL Server守護進程）設(shè)置有事務(wù)阻塞的超時時間，事務(wù)不會阻塞很長時間，超時后事務(wù)處理失敗，自動釋放當前占有的鎖。

3. 操作

設(shè)置手動提交和可重復讀隔離級別并開啟事務(wù)

查詢一下表數(shù)據(jù)，在可重復讀隔離級別使用的是MVCC提供的快照讀，并沒有加鎖

事務(wù)1獲取id=7的排他鎖，事務(wù)2獲取id=8的排他鎖

事務(wù)1再獲取id=8的排它鎖，發(fā)生阻塞

事務(wù)2再獲取id=7的排它鎖，發(fā)生阻塞

此時由于MySQL Server檢測到發(fā)生了死鎖，于是解除事務(wù)1的阻塞，進行事務(wù)1的rollback，釋放其占有的行鎖，于是事務(wù)2成功獲取id=7的排它鎖

三、鎖的優(yōu)化建議

• 在能正確完成業(yè)務(wù)的前提下，為確保效率，盡量使用較低的隔離級別（必須避免臟讀）
• 設(shè)計合理的索引并盡量使用索引訪問數(shù)據(jù)，使加鎖更準確，減少鎖沖突的機會，提高并發(fā)能力
• 選擇合理的事務(wù)大小，小事務(wù)發(fā)生鎖沖突的概率小（事務(wù)越大，包含的SQL越多，可能包含更多的表資源和行資源的鎖，增大了鎖沖突的概率）不同的程序訪問一組表時，應(yīng)盡量約定以相同的順序訪問各表，對一個表而言，盡可能以固定的順序存取表中的行。這樣可以大大減少死鎖的機會
• 盡量用相等條件訪問數(shù)據(jù)，這樣可以避免間隙鎖對并發(fā)插入的影響（其實等值查詢也會加間隙鎖）不要申請超過實際需要的鎖級別
• 除非必須，查詢時不要顯示加鎖（在已提交讀和可重復讀隔離級別，MVCC提供了讀取機制，不需要手動加鎖）

到此這篇關(guān)于MySQL的意向共享鎖、意向排它鎖和死鎖的文章就介紹到這了,更多相關(guān)MySQL鎖內(nèi)容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站！

海外穩(wěn)定服務(wù)器

版權(quán)聲明：本站文章來源標注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。