背景:
剛從別人手裡交接了乙個服務, 裡面有個複雜的業務(命名為介面a), 最近我們公司需要修復資料, 開了80臺機器去呼叫介面a, 日誌就各種 lock wait timeout exceeded; try restarting transaction
備註:
1.介面a有事務
2.統計錯誤日誌, 有很多個地方都會出現 lock wait timeout exceeded; try restarting transaction(大概4個點)
解決問題的過程:
1.首先把事務去掉了, 用其他方式保證資料的完整性, 解決了一部分執行sql 取鎖超時的問題
2.還剩下一些取鎖超時的地方, 就去研究了下如何定位鎖表的問題
3.通過自己的研究與實驗, 定位到了是哪個地方鎖表時間太長
研究/實驗過程:
了解到 select * from information_schema.innodb_trx; 該語句能獲取正在等待鎖的sql
1.首先, 設定資料庫為手動提交事務(在本地mysql資料庫實驗):
set autocommit = 0;select * from base_product where id = 21 for update;3.執行sql語句:
update base_product set remark = "test" where id = 21;update sql 語句自白: 本update也要取id = 21的資料, 居然被鎖住了,沒法finish
4.執行sql語句:
select * from information_schema.innodb_trx;5.過了1分鐘報出:
[sql] update base_product set remark = 「test」 where id = 21;
[err] 1205 - lock wait timeout exceeded; try restarting transaction
結果如下圖:
這就是模擬取鎖超時的過程,
由於我這個服務, 出deadlock found when trying to get lock的錯誤比較頻繁, 也就是, 我可以不停的刷:
select * from information_schema.innodb_trx;select * from information_schema.processlist;結果:我沒有線上資料庫的許可權… 所以我去dba那裡玩了一下, 刷了10分鐘, 刷出來了, 找到了鎖住表的sql…
附:我去網上查如何只查對某個表操作的sql
網上的方式是(錯誤):
select * from information_schema.processlist where db = #select * from information_schema.processlist where info like "%#%";select * from information_schema.processlist where command = "query" and info like "%base_product%";鎖表, 死鎖, 事務, 行級鎖, lock wait timeout exceeded
利用悲觀鎖解決資料庫死鎖
reference url it168技術文件 這邊講述的資料庫死鎖是由於查詢條件順序不對而造成的一類，主要是兩個執行緒在同時對乙個資料庫表進行操作時，出現了下列情況，假設乙個資料庫表 內有5行資料，執行緒1需要對1 4行資料進行update操作，而執行緒2需要對2 5行資料進行update操作，但...
關於資料庫鎖的一些總結
在總結資料庫鎖之前先闡述一下 資料庫的集中隔離級別以及它們分別能避免哪些問題 1.未提交讀，最低階的隔離級別，不能避免丟失更新以及髒讀。2.提交讀，可以避免丟失更新以及髒讀。3.可重複讀，可以避免不可重複讀。4.可序列化，可以避免幻影讀。mysql預設級別是3，mysql的兩大主要引擎，1是inno...
資料庫偶然出現死鎖 等待鎖超時 的情況處理
前言 朋友諮詢我說執行簡單的update語句失效，症狀如下 mysql update order info set province id 15 city id 1667 where order from 10 and order out sn 1407261241 x error 1205 hy0...