排查過程：
select * from information_schema.innodb_lock_waits
select * from information_schema.innodb_trx
show engine innodb status
show variables like 'autocommit'
show processlist
之所以出現鎖等待超時的原因是mysql不會為select語句加鎖，但執行這段sql的**被aop的全域性事務覆蓋了，並設定為了唯讀事務，這時mysql會為select加上偏向共享鎖（is鎖，也稱讀鎖），即允許多個事務同時加s鎖/is鎖而不能加x鎖，而update、delete、insert語句mysql會為其加上排他鎖（x鎖，sql後加上for update），加上x鎖的事務無法加上任何其它鎖，除非釋放當前x鎖，由於執行select的**裡沒有執行完（在等待update的執行結果）不會自動提交，導致共享鎖不會釋放，而update的排他鎖又加不上,在等待select的事務釋放共享鎖，從而產生死鎖。解決方法很簡單，將執行select的**從事務中摘出來，不加事務直接執行即可，當然也是有條件的，insert這條記錄的時間和select該記錄的時間間隔在5s以上，基本可以確保不會產生髒讀問題。
排查的時候特意看了一眼autocommit，是因為之前踩過這個坑，mysql的autocommit被關閉了，導致那一段時間髒讀鎖行鎖表的情況發生很頻繁，但萬萬沒想到是autocommit被關了，導致事務執行著就被掛起來。
mysql innodb 鎖相容陣列
xixsis
x✗✗✗
✗ix✗✓✗
✓s✗✗✓
✓is✗✓✓
✓
記一次https請求超時問題排查
最近在專案中遇到乙個特殊情況，某個客戶通過https訪問公司的公網服務，有較大概率出現響應超時的問題。經過排查定位，確認以下資訊 1 客服伺服器訪問其他公司服務，均沒有出現大概率的超時問題。2 公司服務，壓力測試正常，且沒有其他客戶反饋此類問題。3 客戶公網出口，三大運營商各有一條。根據以上資訊，初...
記一次nginx超時404
想用php請求數個介面,花費時間較長,導致超時 起初只是使用set time limit 0 等方式在php內操作,未能解決 後又修改php引數,ng引數未能解決 最終在網上一番查詢,在ng的配置檔案中加入下方的 fastcgi connect timeout 300 fastcgi read ti...
記一次mysql死鎖問題
場景 innodb下不同的事務進行更新和插入操作導致資料庫死鎖，如下，在批量插入之前，進行了邏輯刪除操作，這段 在併發情況下出現死鎖 堆疊異常 deadlock found when trying to get lock try restarting transaction 更新操作sql 批量插入...