在生產中有兩筆單子同時進行 ，乙個是新增乙個是修改操作，且這兩個操作都通過spring新增了事務，由於死鎖導致了新增的這筆單子新增失敗導致回滾。
1、先使用 >show engine innodb status 命令檢視了mysql的最近一次死鎖記錄
2、分析後得到結論由於兩個事務的執行語句順序相反，應該是先修改table1 再修改table2,另乙個是先修改table2再修改table1導致兩個資源都在對方手裡，資料庫只能回滾事務1來解決死鎖問題。
3、提出問題：mysql資料庫當時我們設定的儲存引擎是innodb 應該是行鎖級別的，為何兩個語句涉及修改的行不一樣也會發生被鎖的情況。 在一番查詢後發現，原來資料型別的轉換導致索引失效。
在 mysql 中，行級鎖並不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條sql 語句操作了主鍵索引，mysql該次死鎖產生的原因是：就會鎖定這條主鍵索引；如果一條語句操作了非主鍵索引，mysql會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。 innodb
行鎖是通過給索引項加鎖實現的，如果沒有索引，innodb
會通過隱藏的聚簇索引來對記錄加鎖。也就是說：如果不通過索引條件檢索資料，那麼innodb將對錶中所有資料加鎖，實際效果跟表鎖一樣。因為沒有了索引，找到某一條記錄就得掃瞄全表，要掃瞄全表，就得鎖定表。
1、兩個事務對sql的呼叫是相反的，導致相互持有對方的鎖
2、資料型別傳遞不規範導致索引失效從而引起表鎖
show engine innodb status / /檢視最近一次資料死鎖的日誌set @@autocommit=0; / /將事務設定為手動提交
show variables like 『%autocommit%』 / /檢視事務是否設定為手動提交
記一次生產報too man open files
有一天私有雲無法訪問，馬上聯絡廠商，最後廠商發現好多容器不停重啟，經過日誌檢視發現平台開啟檔案控制代碼太多，很奇怪，就開始排查，最後發現乙個埠，定位到應用spring actuator.這個應用是我為了監控微服務而發布的乙個監控應用，馬上看日誌，發現應用報錯，too many open files，...
一次生產事故的優化經歷
跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開頁面。在搶標過程中繼續觀察，...
一次生產事故的優化經歷
原 一次生產事故的優化經歷 跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開...