問題描述
在做項目的過程中,由於寫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語句會執行以下步驟:
1、由於用到了非主鍵索引,首先需要獲取idx_1上的行級鎖
2、緊接着根據主鍵進行更新,所以需要獲取主鍵上的行級鎖;
3、更新完畢後,提交,並釋放所有鎖。
如果在步驟1和2之間突然插入一條語句:update user_item .....where id=? and user_id=?,這條語句會先鎖住主鍵索引,然後鎖住idx_1。
蛋疼的情況出現了,一條語句獲取了idx_1上的鎖,等待主鍵索引上的鎖;另一條語句獲取了主鍵上的鎖,等待idx_1上的鎖,這樣就出現了死鎖。
解決方案
1、先獲取需要更新的記錄的主鍵
select id from user_item where user_id=? and item_id=?
2、逐條更新
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) {
userItemDAO.updateStatus(id,userId,1)
}
return null;
}catch(DAOException e) {
status.setRollbackOnly();
return e;
}
catch (Exception e) {
status.setRollbackOnly();
return e;
}
}
});
小結:在採用INNODB的MySQL中,更新操作默認會加行級鎖,行級鎖是基於索引的,在分析死鎖之前需要查詢一下mysql的執行計劃,看看是否用到了索引,用到了哪個索引,對於沒有用索引的操作會採用表級鎖。如果操作用到了主鍵索引會先在主鍵索引上加鎖,然後在其他索引上加鎖,否則加鎖順序相反。在併發度高的應用中,批量更新一定要帶上記錄的主鍵,優先獲取主鍵上的鎖,這樣可以減少死鎖的發生。