建站
咨詢
售后
建站咨詢
新聞中心
數(shù)據(jù)庫是現(xiàn)代組織最重要的數(shù)據(jù)存儲(chǔ)設(shè)備之一。在數(shù)據(jù)庫系統(tǒng)中，同時(shí)對(duì)數(shù)據(jù)庫的訪問可能是一個(gè)常見場景，這時(shí)候可能會(huì)發(fā)生死鎖。 死鎖是指兩個(gè)或多個(gè)事務(wù)相互等待，從而無法繼續(xù)進(jìn)行的狀態(tài)。為了避免數(shù)據(jù)庫死鎖的影響，我們需要了解。
成都創(chuàng)新互聯(lián)公司：于2013年成立為各行業(yè)開拓出企業(yè)自己的“網(wǎng)站建設(shè)”服務(wù)，為1000+公司企業(yè)提供了專業(yè)的成都網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)和網(wǎng)站推廣服務(wù)， 定制網(wǎng)站設(shè)計(jì)由設(shè)計(jì)師親自精心設(shè)計(jì)，設(shè)計(jì)的效果完全按照客戶的要求，并適當(dāng)?shù)奶岢龊侠淼慕ㄗh，擁有的視覺效果，策劃師分析客戶的同行競爭對(duì)手，根據(jù)客戶的實(shí)際情況給出合理的網(wǎng)站構(gòu)架，制作客戶同行業(yè)具有領(lǐng)先地位的。
一、什么是數(shù)據(jù)庫死鎖？
在繁忙的數(shù)據(jù)庫環(huán)境中，重要的是確保數(shù)據(jù)的完整性和一致性。然而，多個(gè)用戶同時(shí)訪問數(shù)據(jù)庫時(shí)，可能會(huì)發(fā)生死鎖的情況。 死鎖是數(shù)據(jù)庫事務(wù)的一種狀態(tài)，其中兩個(gè)或多個(gè)事務(wù)相互等待，從而導(dǎo)致所有事務(wù)無法繼續(xù)以任何方式處理。
例如，假設(shè)一個(gè)事務(wù)正在執(zhí)行更新操作，而另一個(gè)事務(wù)正在嘗試讀取相關(guān)的數(shù)據(jù)。如果更新事務(wù)持有了鎖并保留了鎖，直到它放棄資源為止，則讀取事務(wù)將被阻塞。 如果它是另一個(gè)事務(wù)的一部分，那么兩個(gè)事務(wù)可能會(huì)相互等待，從而導(dǎo)致死鎖。
死鎖可能導(dǎo)致數(shù)據(jù)庫停止響應(yīng)或出現(xiàn)故障，因此，它們是維護(hù)數(shù)據(jù)庫穩(wěn)定性和功能的重要因素。
二、為什么要避免數(shù)據(jù)庫死鎖？
數(shù)據(jù)庫死鎖很危險(xiǎn)，因?yàn)楫?dāng)一個(gè)事務(wù)持有鎖并等待其他事務(wù)持有的鎖，它會(huì)阻止其他事務(wù)繼續(xù)運(yùn)行。 這可能會(huì)導(dǎo)致資源的浪費(fèi)和系統(tǒng)的癱瘓。 數(shù)據(jù)庫鎖的主要目的是確保數(shù)據(jù)的完整性和一致性。 為了避免數(shù)據(jù)庫死鎖的影響，我們需要遵循一些準(zhǔn)則。
三、？
1.檢查數(shù)據(jù)庫日志
檢查數(shù)據(jù)庫日志是一個(gè)簡單而有效的方法，通常會(huì)記錄死鎖情況。 如果您發(fā)現(xiàn)庫死鎖產(chǎn)生的可能性，請(qǐng)查看DBMS（數(shù)據(jù)庫管理系統(tǒng)）生成的錯(cuò)誤信息。 此外，您還可以使用DBMS日志來概述發(fā)生死鎖的情況的詳細(xì)信息，其中包括事務(wù)ID，日期和時(shí)間戳等其他重要信息。
2.查看應(yīng)用程序日志
應(yīng)用程序的日志也可以提供有關(guān)死鎖的線索。 如果您正在訪問應(yīng)用程序日志，則可能會(huì)看到一條類似死鎖的錯(cuò)誤消息。 此時(shí)，您可以將此信息與數(shù)據(jù)庫日志中的信息進(jìn)行比對(duì)，以幫助診斷和解決死鎖問題。
3.監(jiān)視活動(dòng)和等待的事務(wù)
在DMBS中，可以使用一些技術(shù)來監(jiān)視和識(shí)別活動(dòng)和等待的事務(wù)。 例如，您可以運(yùn)行查詢以了解正在運(yùn)行的并行事務(wù)或等待交易的資源。 一旦發(fā)現(xiàn)問題，您可以更改或優(yōu)化查詢，以更大限度地減少死鎖的情況。
4.使用專業(yè)的數(shù)據(jù)庫工具
專業(yè)的數(shù)據(jù)庫工具可以提供更好的數(shù)據(jù)分析和更詳細(xì)的記錄，以便更清楚地確定死鎖產(chǎn)生的信息。 這些工具可以監(jiān)視DMBS的活動(dòng)，并檢測和記錄系統(tǒng)錯(cuò)誤和異常情況。 如果您想更好地處理數(shù)據(jù)庫死鎖問題，則可以考慮使用這些工具。
數(shù)據(jù)庫死鎖是現(xiàn)代系統(tǒng)中的一種常見問題。 管理人員應(yīng)該學(xué)習(xí)，并遵循一些規(guī)則和準(zhǔn)則，以便更好地處理和解決數(shù)據(jù)庫死鎖問題。
成都網(wǎng)站建設(shè)公司-創(chuàng)新互聯(lián),建站經(jīng)驗(yàn)豐富以策略為先導(dǎo)10多年以來專注數(shù)字化網(wǎng)站建設(shè),提供企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),響應(yīng)式網(wǎng)站制作,設(shè)計(jì)師量身打造品牌風(fēng)格,熱線:028-86922220解決一次mysql死鎖問題
多線程開啟事務(wù)處理。每個(gè)事務(wù)有多個(gè)update操作和一個(gè)insert操作（都在同一張表）。
默認(rèn)隔離級(jí)別：Repeatable Read
只有hotel_id=2和hotel_id=11111的數(shù)據(jù)
邏輯刪除原有數(shù)據(jù)
插入新的數(shù)據(jù)
根據(jù)現(xiàn)有數(shù)據(jù)情況，update的時(shí)候沒有數(shù)據(jù)被更新
報(bào)了非常多一樣的錯(cuò)
發(fā)現(xiàn)居然有死鎖。
根據(jù)常識(shí)考慮，我每個(gè)線程（事務(wù)）更新的數(shù)據(jù)都不沖突，為什么會(huì)產(chǎn)生死鎖？
帶著這個(gè)問題，打印mysql最近一次的死鎖信息
show engine innodb status
顯示如下
發(fā)現(xiàn)事務(wù)1在等待一個(gè)鎖
事務(wù)2也在等待一個(gè)鎖
而且事物2持有了事物1需要的鎖
關(guān)于鎖的描述，出現(xiàn)了
lock_mode
，
gap before rec
，
insert intention
等字眼，看不懂說明了什么？說明我關(guān)于mysql的鎖相關(guān)的知識(shí)儲(chǔ)備還不夠。那就開始調(diào)查mysql的鎖相關(guān)知識(shí)。
通過搜索引擎，
鎖的持有兼容程度如下表
那么再回到死鎖日志，可以知道 :
事務(wù)1正在獲取插入意向鎖
事務(wù)2正在獲取插入意向鎖，持有排他gap鎖
再看我們上面的鎖兼容表格，可以知道，
gap lock和insert intention lock是不兼容的
那么就可以推斷出：
事務(wù)1持有g(shù)ap lock，等待事務(wù)2的insert intention lock釋放；事務(wù)2持有g(shù)ap lock，等待事務(wù)1的insert intention lock釋放，從而導(dǎo)致死鎖。
那么新的問題就來了，事務(wù)1的intention lock 為什么會(huì)和事務(wù)2的gap lock 有交集，或者說，事務(wù)1要插入的數(shù)據(jù)的位置為什么會(huì)被事務(wù)2給鎖?。?/p>
讓我回顧一下gap lock的定義：
間隙鎖，鎖定一個(gè)范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務(wù)的兩次當(dāng)前讀，出現(xiàn)幻讀的情況
那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發(fā)現(xiàn)自己相關(guān)的知識(shí)儲(chǔ)備還不夠。那就開始調(diào)查。
調(diào)查后發(fā)現(xiàn)，當(dāng)當(dāng)前索引是一個(gè)
普通索引
的時(shí)候，會(huì)加一個(gè)gap lock來防止幻讀，
此gap lock 會(huì)鎖住一個(gè)左開右閉的區(qū)間。
假設(shè)索引為xx_idx（xx_id），數(shù)據(jù)分布為1,4,6,8,12，當(dāng)更新xx_id=9的時(shí)候，這個(gè)時(shí)候gap lock的鎖定記錄區(qū)間就是(8，12>，也就是鎖住了xxid in (9,10,11,12)的數(shù)據(jù)，當(dāng)有其他事務(wù)要插入xxid in (9,10,11,12)的數(shù)據(jù)時(shí)，就會(huì)處于等待獲取鎖的狀態(tài)。
ps：當(dāng)前索引不是普通索引，而且是唯一索引等其他情況，請(qǐng)參考下面資料
MySQL 加鎖處理分析
回到我自己的案例中，重新屢一下事務(wù)1的執(zhí)行過程：
因?yàn)槠胀ㄋ饕?/p>
KEY hotel_date_idx ( hotel_id , rate_date )
的關(guān)系 這段sql會(huì)獲取一個(gè)gap lock，范圍(2,11111>
這段sql會(huì)獲取一個(gè)insert intention lock （waiting）
再看事務(wù)2的執(zhí)行過程
因?yàn)槠胀ㄋ饕?/p>
KEY hotel_date_idx ( hotel_id , rate_date )
的關(guān)系 這段sql也會(huì)獲取一個(gè)gap lock，范圍也是(2,11111>（根據(jù)前面的知識(shí)，gap lock之間會(huì)互相兼容，可以一起持有鎖的）
這段sql也會(huì)獲取一個(gè)insert intention lock （waiting）
看到這里，基本也就破案了。因?yàn)槠胀ㄋ饕年P(guān)系，事務(wù)1和事務(wù)2的gap lock的覆蓋范圍太廣，導(dǎo)致其他事務(wù)無法插入數(shù)據(jù)。
重新梳理一下：
所以從結(jié)果來看，一堆事務(wù)被回滾，只有10007數(shù)據(jù)被更新成功
gap lock 導(dǎo)致了并發(fā)處理的死鎖
在mysql默認(rèn)的事務(wù)隔離級(jí)別（repeatable read）下，無法避免這種情況。只能把并發(fā)處理改成同步處理?；蛘邚臉I(yè)務(wù)層面做處理。
共享鎖、排他鎖、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
show engine innodb status
關(guān)于數(shù)據(jù)庫死鎖報(bào)什么錯(cuò)的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
創(chuàng)新互聯(lián)【028-86922220】值得信賴的成都網(wǎng)站建設(shè)公司。多年持續(xù)為眾多企業(yè)提供成都網(wǎng)站建設(shè),成都品牌建站設(shè)計(jì),成都高端網(wǎng)站制作開發(fā),SEO優(yōu)化排名推廣服務(wù),全網(wǎng)營銷讓企業(yè)網(wǎng)站產(chǎn)生價(jià)值。
當(dāng)前名稱：如何識(shí)別數(shù)據(jù)庫死鎖產(chǎn)生的錯(cuò)誤信息(數(shù)據(jù)庫死鎖報(bào)什么錯(cuò))
本文來源：http://www.5511xx.com/article/djissic.html
