項(xiàng)目坑有千千萬,我們靜下心來還是可以找到解決辦法的
創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括平度網(wǎng)站建設(shè)、平度網(wǎng)站制作、平度網(wǎng)頁制作以及平度網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,平度網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到平度省份的部分城市,未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
最近接了一個(gè)由供應(yīng)商留下來的項(xiàng)目,正是周末休息時(shí)間突然一個(gè)電話說功能用不了,翻看日志發(fā)現(xiàn)是業(yè)務(wù)功能的表被鎖了,我就奇了怪了,天天沒事,突然周末來使兒。一番了解才發(fā)現(xiàn)那個(gè)鎖表情況是天天都有的,但是一直沒找到原因,所以DBA運(yùn)維同事天天充當(dāng)定時(shí)刪除機(jī)器,每天早上清除鎖表進(jìn)程,丟失的數(shù)據(jù)也手動補(bǔ)錄,厲害了,這就是供應(yīng)商做的項(xiàng)目嗎?爛到這個(gè)層度(吐槽一番)
回到正題,我們來聊一聊我的解決步驟
一:檢查是否鎖表, 查詢進(jìn)程并殺死進(jìn)程
1) 查詢是否鎖表
show open tables where in_use 0;
2) 查詢進(jìn)程(如果您有SUPER權(quán)限,您可以看到所有線程。否則,您只能看到您自己的線程)
show processlist;
二:查看在鎖事務(wù),殺死事務(wù)對應(yīng)的線程ID
1) 查看正在鎖的事務(wù)
select * from information_schema.INNODB_LOCKS;
2) 殺死進(jìn)程id(就是[select * from information_schema.INNODB_LOCKS; ]命令的trx_mysql_thread_id列)
kill 線程ID
3) 查看等待鎖的事務(wù)
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
其它:
1) 查看服務(wù)器狀態(tài)
show status like '%lock%';
2) 查看超時(shí)時(shí)間:
show variables like '%timeout%';
有時(shí)候,會很不小心,在業(yè)務(wù)運(yùn)行中執(zhí)行了一條鎖表語句。這時(shí)候該怎么辦?
例如:修改元數(shù)據(jù)。
SHOW FULL PROCESSLIST 查看一下:
發(fā)現(xiàn)修改之后,鎖表了。這時(shí)候怎么辦? 殺死它 KILL 4623660
然后一切又恢復(fù)正常了。
一般對于數(shù)據(jù)量較大的表,需要修改表結(jié)構(gòu),或者做一些耗時(shí)比較久的鎖表操作,建議在晚上(業(yè)務(wù)閑時(shí))執(zhí)行。這個(gè)時(shí)候可以配合使用任務(wù)處理一下。
如:修改一個(gè)表的字段長度,和添加索引
名詞解釋:
接著回家睡覺,第二天回來檢查結(jié)果就好了。
附:添加唯一索引示例
MYSQL存儲過程結(jié)合任務(wù)處理耗時(shí)操作
對于寫鎖定如下:
1)、如果表沒有加鎖,那么對其加寫鎖定。
2)、否則,那么把請求放入寫鎖隊(duì)列中。
對于讀鎖定如下:
1)、如果表沒有加寫鎖,那么加一個(gè)讀鎖。
2)、否則,那么把請求放到讀鎖隊(duì)列中。
當(dāng)然我們可以分別用low_priority 以及high_priority在寫和讀操作上來改變這些行為。
-- 查詢是否鎖表
show OPEN TABLES ;
-- 查詢進(jìn)程
show processlist ;
-- 查詢到相對應(yīng)的進(jìn)程,然后殺死進(jìn)程
kill id; -- 一般到這一步就解鎖了
-- 查看正在鎖的事務(wù)
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
-- 查看等待鎖的事務(wù)
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
-- 解鎖表
UNLOCK TABLES;
行鎖的等待
在介紹如何解決行鎖等待問題前,先簡單介紹下這類問題產(chǎn)生的原因。產(chǎn)生原因簡述:當(dāng)多個(gè)事務(wù)同時(shí)去操作(增刪改)某一行數(shù)據(jù)的時(shí)候,MySQL 為了維護(hù) ACID 特性,就會用鎖的形式來防止多個(gè)事務(wù)同時(shí)操作某一行數(shù)據(jù),避免數(shù)據(jù)不一致。只有分配到行鎖的事務(wù)才有權(quán)力操作該數(shù)據(jù)行,直到該事務(wù)結(jié)束,才釋放行鎖,而其他沒有分配到行鎖的事務(wù)就會產(chǎn)生行鎖等待。如果等待時(shí)間超過了配置值(也就是 innodb_lock_wait_timeout 參數(shù)的值,個(gè)人習(xí)慣配置成 5s,MySQL 官方默認(rèn)為 50s),則會拋出行鎖等待超時(shí)錯(cuò)誤。
如上圖所示,事務(wù) A 與事務(wù) B 同時(shí)會去 Insert 一條主鍵值為 1 的數(shù)據(jù),由于事務(wù) A 首先獲取了主鍵值為 1 的行鎖,導(dǎo)致事務(wù) B 因無法獲取行鎖而產(chǎn)生等待,等到事務(wù) A 提交后,事務(wù) B 才獲取該行鎖,完成提交。這里強(qiáng)調(diào)的是行鎖的概念,雖然事務(wù) B 重復(fù)插入了主鍵,但是在獲取行鎖之前,事務(wù)一直是處于行鎖等待的狀態(tài),只有獲取行鎖后,才會報(bào)主鍵沖突的錯(cuò)誤。當(dāng)然這種 Insert 行鎖沖突的問題比較少見,只有在大量并發(fā)插入場景下才會出現(xiàn),項(xiàng)目上真正常見的是 updatedelete 之間行鎖等待,這里只是用于示例,原理都是相同的。
三、產(chǎn)生的原因根據(jù)我之前接觸到的此類問題,大致可以分為以下幾種原因
網(wǎng)頁標(biāo)題:mysql鎖表了怎么辦,mysql表鎖住了怎么辦
文章轉(zhuǎn)載:http://m.kartarina.com/article20/hegeco.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供營銷型網(wǎng)站建設(shè)、企業(yè)網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)公司、關(guān)鍵詞優(yōu)化、網(wǎng)站排名、微信小程序
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)