MySQL併發引發的死鎖案例分析

在作項目的過程當中，因爲寫SQL太過隨意，一不當心就拋了一個死鎖異常，以下：

com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction  
        at sun.reflect.GeneratedConstructorAccessor247.newInstance(Unknown Source)  
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)  
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)  
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)  
        at com.mysql.jdbc.Util.getInstance(Util.java:381)  
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1045)  
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)  
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491)  
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423)  
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936)  
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060)  
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2542)  
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1734)  
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2019)  
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1937)  
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1922)

表結構以下：

CREATE TABLE `user_item` (  
  `id` BIGINT(20) NOT NULL,  
  `user_id` BIGINT(20) NOT NULL,  
  `item_id` BIGINT(20) NOT NULL,  
  `status` TINYINT(4) NOT NULL,  
  PRIMARY KEY (`id`),  
  KEY `idx_1` (`user_id`,`item_id`,`status`)  
) ENGINE=INNODB DEFAULT CHARSET=utf-8

SQL語句以下：

update user_item set status=1 where user_id=? and item_id=?

緣由分析 MySQL的事務支持與存儲引擎有關，MyISAM不支持事務，INNODB支持事務，更新時採用的是行級鎖。這裏採用的是INNODB作存儲引擎，意味着會將update語句作爲一個事務來處理。前面提到行級鎖必須創建在索引的基礎，這條更新語句用到了索引idx_1，因此這裏確定會加上行級鎖。 行級鎖並非直接鎖記錄，而是鎖索引，若是一條SQL語句用到了主鍵索引，mysql會鎖住主鍵索引；若是一條語句操做了非主鍵索引，mysql會先鎖住非主鍵索引，再鎖定主鍵索引。 這個update語句會執行如下步驟： 一、因爲用到了非主鍵索引，首先須要獲取idx_1上的行級鎖 二、緊接着根據主鍵進行更新，因此須要獲取主鍵上的行級鎖； 三、更新完畢後，提交，並釋放全部鎖。 若是在步驟1和2之間忽然插入一條語句：update user_item .....where id=? and user_id=?,這條語句會先鎖住主鍵索引，而後鎖住idx_1。 蛋疼的狀況出現了，一條語句獲取了idx_1上的鎖，等待主鍵索引上的鎖；另外一條語句獲取了主鍵上的鎖，等待idx_1上的鎖，這樣就出現了死鎖。

解決方案 一、先獲取須要更新的記錄的主鍵

select id from user_item where user_id=? and item_id=?

二、逐條更新

for (Long id : idList) {  
    userItemDAO.updateStatus(id, userId, 1);  
}  
update user_item set status=? where id=? and user_id=?

這樣貌似解決了，都是對單條進行操做，都是先獲取主鍵上的鎖，再獲取idx_1上的鎖。 不過這個解決方案與先前的更新語句不同，先前的更新語句對全部記錄的更新在一個事務中，採用循環更新後並不在同一個事務中，因此在for循環外面還得開一個事務。

Exception e = (Exception)getDbfeelTransactionTemplate().execute(new TransactionCallback() {  
   public Object doInTransaction(TransactionStatus status) {  
      try {  
            for(Long id:idList) {  
        <span style="white-space:pre">  </span>userItemDAO.updateStatus(id,userId,1)  
        }  
            return null;  
      }catch(DAOException e) {  
         status.setRollbackOnly();  
         return e;  
      }  
      catch (Exception e) {  
         status.setRollbackOnly();  
         return e;  
      }  
   }  
});

**小結：**在採用INNODB的MySQL中，更新操做默認會加行級鎖，行級鎖是基於索引的，在分析死鎖以前須要查詢一下mysql的執行計劃，看看是否用到了索引，用到了哪一個索引，對於沒有用索引的操做會採用表級鎖。若是操做用到了主鍵索引會先在主鍵索引上加鎖，而後在其餘索引上加鎖，不然加鎖順序相反。在併發度高的應用中，批量更新必定要帶上記錄的主鍵，優先獲取主鍵上的鎖，這樣能夠減小死鎖的發生。