最近線上 MySQL 接連發生了幾起數據異常，都是在凌晨爆發，由于業務場景屬于典型的數據倉庫型應用，白天壓力較小無法復現。甚至有些異常還比較詭異，最后 root cause 分析頗費周折。那實際業務當中咱們如何能快速的定位線上 MySQL 問題，修復異常呢？下文我會根據兩個實際 case，分享下相關的經驗與方法。

Case1：部分數據更新失敗

某天渠道同學反饋某報表極個別渠道數據為 0，大部分渠道數據正常。這個數據是由一個統計程序每天凌晨例行更新的，按理來說，要么全部正常，要么全部失敗，那會是什么原因導致極個別數據異常呢？

首先我們能想到的自然是根據統計任務日志來看了，但是看了統計程序打印的日志沒有發現諸如 SQL update 失敗的異常描述，那當時的數據庫究竟發生了什么呢？在查看 MySQL-server 日志之前，習慣性的看了下數據庫狀態：

恰好看到了凌晨這個 update 發生了死鎖：

篇幅所限，上下文我這里省略了很多，從這段日志里可以看到，TRANSACTION 1 和 TRANSACTION 2 分別持有一定數量的行鎖，然后又等待對方的鎖，最后 MySQL 檢測到 deadlock ，然后選擇回滾了 TRANSACTION 1：Innodb目前處理死鎖的方法是將持有最少行級排他鎖的事務進行回滾。

那這里就有 3 個問題了：

1、innodb 行鎖不是只鎖一行？

因為這張表是 innodb 引擎的，InnoDB 支持行鎖和表鎖。而InnoDB行鎖是通過給索引上的索引項加鎖來實現的，這一點MySQL與Oracle不同，后者是通過在數據塊中對相應數據行加鎖來實現的。InnoDB這種行鎖實現特點意味著：只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖，會把所有掃描過的行都鎖定！在實際應用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導致大量的鎖沖突，從而影響并發性能。由于MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是使用相同的索引鍵，是會出現鎖沖突的。當我們用范圍條件而不是相等條件檢索數據，并請求共享或排他鎖時，InnoDB會給符合條件的已有數據記錄的索引項加鎖；另外間隙鎖也會鎖多行，InnoDB除了通過范圍條件加鎖時使用間隙鎖外，如果使用相等條件請求給一個不存在的記錄加鎖，InnoDB也會使用間隙鎖！

話都說到這了，那就看下咱們業務表的索引情況：