生活随笔
收集整理的這篇文章主要介紹了
MySQL批量更新死锁案例分析--转载
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
問題描述
在做項目的過程中，由于寫SQL太過隨意，一不小心就拋了一個死鎖異常，如下：
?
[java]?view plaincopyprint?
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)?? 表結構如下：
?
[sql]?view plaincopyprint?
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語句如下：
?
?
[sql]?view plaincopyprint?
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、先獲取需要更新的記錄的主鍵?
?
[sql]?view plaincopyprint?
select?id?from?user_item?where?user_id=??and?item_id=??? 2、逐條更新
?
?
[java]?view plaincopyprint?
for?(Long?id?:?idList)?{??????userItemDAO.updateStatus(id,?userId,?1);??}?? [sql]?view plaincopyprint?
update?user_item?set?status=??where?id=??and?user_id=??? 這樣貌似解決了，都是對單條進行操作，都是先獲取主鍵上的鎖，再獲取idx_1上的鎖。
?
不過這個解決方案與先前的更新語句不一樣，先前的更新語句對所有記錄的更新在一個事務中，采用循環更新后并不在同一個事務中，所以在for循環外面還得開一個事務。
?
[java]?view plaincopyprint?
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的執行計劃，看看是否用到了索引，用到了哪個索引，對于沒有用索引的操作會采用表級鎖。如果操作用到了主鍵索引會先在主鍵索引上加鎖，然后在其他索引上加鎖，否則加鎖順序相反。在并發度高的應用中，批量更新一定要帶上記錄的主鍵，優先獲取主鍵上的鎖，這樣可以減少死鎖的發生。
原文：http://blog.csdn.net/aesop_wubo/article/details/8286215
轉載于:https://www.cnblogs.com/davidwang456/p/3998361.html
總結
以上是生活随笔為你收集整理的MySQL批量更新死锁案例分析--转载的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。
