mysql怎么讓表不死鎖 mysql解決死鎖的4種基本方法

mysql給表增加字段會鎖表,怎樣才可以不鎖表嗎?

這個是屬于系統(tǒng)遺留問題，也就是一種系統(tǒng)的保護(hù)機(jī)制。就是為了避免出現(xiàn)這種在線修改系統(tǒng)的操作。

成都創(chuàng)新互聯(lián)主營淮安網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,重慶APP開發(fā)公司,淮安h5小程序設(shè)計搭建,淮安網(wǎng)站營銷推廣歡迎淮安等地區(qū)企業(yè)咨詢

增加字段屬于系統(tǒng)的修改操作。盡量不要在線操作，因為可能出現(xiàn)。未知的漏洞。一定要。離線。修改完畢，然后經(jīng)過測試后。認(rèn)為已經(jīng)沒有問題了。在。次日的凌晨發(fā)一個通知。停機(jī)維護(hù)。這樣才能保證系統(tǒng)的正常運(yùn)轉(zhuǎn)。

如果在前期設(shè)置系統(tǒng)的時候就預(yù)留了。熱升級的空間。這樣才能達(dá)到在線操作的目的，而且系統(tǒng)的金融群總是一部分先升級。

很多情況下，你需要使用系統(tǒng)里邊的工具集。在線修改表格。原理其實非常的簡單，新建的和原表的表格結(jié)構(gòu)。要一模一樣。對這個表格進(jìn)行修改，然后把結(jié)構(gòu)變更的日期。插入進(jìn)去。而且還建議您盡量在業(yè)務(wù)的低縫隙進(jìn)行修改。避免發(fā)生不可控的未知狀況。

使用說明：

1、如果是用 MySQL + Apache，使用的又是 FreeBSD 網(wǎng)絡(luò)操作系統(tǒng)的話，安裝時候你應(yīng)按注意到FreeBSD的版本問題，在FreeBSD 的 3.0 以下版本來說，MySQL Source 內(nèi)含的 MIT-pthread 運(yùn)行是正常的，但在這版本以上，你必須使用 native threads。

2、如果在 COMPILE 過程中出了問題，請先檢查你的 gcc版本是否在 2.81 版本以上，gmake 版本是否在3.75以上。

3、如果不是版本的問題，那可能是你的內(nèi)存不足，請使用configure--with-low-memory 來加入。

4、如果要重新做你的configure，那么你可以鍵入rm config.cache和make clean來清除記錄。

5、把 MySQL 安裝在 /usr/local 目錄下，這是缺省值，您也可以按照你的需要設(shè)定你所安裝的目錄。

詳解MySQL（InnoDB）如何處理死鎖

鎖是需要事務(wù)結(jié)束后才釋放的。

一個是 MVCC，一個是兩階段鎖協(xié)議。

為什么要并發(fā)控制呢？是因為多個用戶同時操作 MySQL 的時候，為了提高并發(fā)性能并且要求如同多個用戶的請求過來之后如同串行執(zhí)行的一樣（為了解決臟讀、不可重復(fù)讀、幻讀）

官方定義：

兩階段鎖協(xié)議是指所有事務(wù)必須分兩個階段對數(shù)據(jù)加鎖和解鎖，在對任何數(shù)據(jù)進(jìn)行讀、寫操作之前，事務(wù)首先要獲得對該數(shù)據(jù)的封鎖；在釋放一個封鎖之后，事務(wù)不再申請和獲得任何其他封鎖。

對應(yīng)到 MySQL 上分為兩個階段：

但是兩階段鎖協(xié)議不要求事務(wù)必須一次將所有需要使用的數(shù)據(jù)加鎖（innodb在需要的索引列數(shù)據(jù)才鎖行），并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會形成死鎖。

MySQL有兩種死鎖處理方式：

死鎖檢測 （默認(rèn)開啟）

死鎖檢測的原理是構(gòu)建一個以事務(wù)為頂點、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。

回滾

檢測到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。

收集死鎖信息：

減少死鎖：

死鎖解決：

如何避免mysql死鎖問題

處理方式：

1． 在表上建立一個聚集索引。

2． 對語句更新的相關(guān)字段建立包含索引。

如何預(yù)防死鎖

1.盡量避免并發(fā)的執(zhí)行涉及到修改數(shù)據(jù)的語句。

2.編寫應(yīng)用程序，讓進(jìn)程持有鎖的時間盡可能短，這樣其它進(jìn)程就不必花太長的時間等待鎖被釋放。

解決一次mysql死鎖問題

多線程開啟事務(wù)處理。每個事務(wù)有多個update操作和一個insert操作（都在同一張表）。

默認(rèn)隔離級別：Repeatable Read

只有hotel_id=2和hotel_id=11111的數(shù)據(jù)

邏輯刪除原有數(shù)據(jù)

插入新的數(shù)據(jù)

根據(jù)現(xiàn)有數(shù)據(jù)情況，update的時候沒有數(shù)據(jù)被更新

報了非常多一樣的錯

發(fā)現(xiàn)居然有死鎖。

根據(jù)常識考慮，我每個線程（事務(wù)）更新的數(shù)據(jù)都不沖突，為什么會產(chǎn)生死鎖？

帶著這個問題，打印mysql最近一次的死鎖信息

show engine innodb status

顯示如下

發(fā)現(xiàn)事務(wù)1在等待一個鎖

事務(wù)2也在等待一個鎖

而且事物2持有了事物1需要的鎖

關(guān)于鎖的描述，出現(xiàn)了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂說明了什么？說明我關(guān)于mysql的鎖相關(guān)的知識儲備還不夠。那就開始調(diào)查mysql的鎖相關(guān)知識。

通過搜索引擎，

鎖的持有兼容程度如下表

那么再回到死鎖日志，可以知道 :

事務(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 為什么會和事務(wù)2的gap lock 有交集，或者說，事務(wù)1要插入的數(shù)據(jù)的位置為什么會被事務(wù)2給鎖?。?/p>

讓我回顧一下gap lock的定義：

間隙鎖，鎖定一個范圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務(wù)的兩次當(dāng)前讀，出現(xiàn)幻讀的情況

那為什么是gap lock，gap lock到底是基于什么邏輯鎖的記錄？發(fā)現(xiàn)自己相關(guān)的知識儲備還不夠。那就開始調(diào)查。

調(diào)查后發(fā)現(xiàn)，當(dāng)當(dāng)前索引是一個 普通索引 的時候，會加一個gap lock來防止幻讀， 此gap lock 會鎖住一個左開右閉的區(qū)間。 假設(shè)索引為xx_idx（xx_id），數(shù)據(jù)分布為1,4,6,8,12，當(dāng)更新xx_id=9的時候，這個時候gap lock的鎖定記錄區(qū)間就是(8，12]，也就是鎖住了xxid in (9,10,11,12)的數(shù)據(jù)，當(dāng)有其他事務(wù)要插入xxid in (9,10,11,12)的數(shù)據(jù)時，就會處于等待獲取鎖的狀態(tài)。

ps：當(dāng)前索引不是普通索引，而且是唯一索引等其他情況，請參考下面資料

MySQL 加鎖處理分析

回到我自己的案例中，重新屢一下事務(wù)1的執(zhí)行過程：

因為普通索引

KEY hotel_date_idx ( hotel_id , rate_date )

的關(guān)系 這段sql會獲取一個gap lock，范圍(2,11111]

這段sql會獲取一個insert intention lock （waiting）

再看事務(wù)2的執(zhí)行過程

因為普通索引

KEY hotel_date_idx ( hotel_id , rate_date )

的關(guān)系 這段sql也會獲取一個gap lock，范圍也是(2,11111]（根據(jù)前面的知識，gap lock之間會互相兼容，可以一起持有鎖的）

這段sql也會獲取一個insert intention lock （waiting）

看到這里，基本也就破案了。因為普通索引的關(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ù)隔離級別（repeatable read）下，無法避免這種情況。只能把并發(fā)處理改成同步處理?；蛘邚臉I(yè)務(wù)層面做處理。

共享鎖、排他鎖、意向共享、意向排他

record lock、gap lock、next key lock、insert intention lock

show engine innodb status

文章標(biāo)題：mysql怎么讓表不死鎖 mysql解決死鎖的4種基本方法
本文地址：http://muchs.cn/article6/hgioig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、網(wǎng)站營銷、搜索引擎優(yōu)化、網(wǎng)站設(shè)計、企業(yè)建站、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)