問題：

在多訪問的情況下，一個刪除計劃的操作會出現死鎖現象，報錯如下：

### Error updating database.  Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
### The error may involve com.longfor.tender.mapper.TdPlaInfoMapper.updatePlanDelById-Inline
### The error occurred while setting parameters
### SQL: UPDATE td_plan SET is_delete = ?,   last_update_time=?,   last_update_by = ?   WHERE id = ?
### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
; SQL []; Deadlock found when trying to get lock; try restarting transaction; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
	at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:263)
	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)
	at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:71)
	at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:364)
	at com.sun.proxy.$Proxy20.update(Unknown Source)
	at org.mybatis.spring.Sq
 

解決方案：

此刪除涉及到事物，在刪除計劃的過程中，還要刪除立項資訊、合同需求資訊關聯的計劃資訊。在刪除開始之前設定事物，是不夠嚴謹的。所以，把開啟事物放置到刪除立項的方法、合同需求方法、計劃的方法，這樣，每一模組是一個單獨的事物。鎖的範圍縮小，基本併發可用。

網上搜索到的資料，以備參考：

表結構：
CREATE TABLE `test` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘主鍵’,
`test_id` bigint(20) DEFAULT NULL,
`group_id` bigint(20) DEFAULT NULL COMMENT ‘Id，對應test_group.id’,
`gmt_created` datetime DEFAULT NULL COMMENT ‘建立時間’,
`gmt_modified` datetime DEFAULT NULL COMMENT ‘修改時間’,
`is_deleted` tinyint(4) DEFAULT ‘0’ COMMENT ‘刪除。’,
PRIMARY KEY (`id`),
KEY `idx_testid` (`test_id`),
KEY `idx_groupid` (`group_id`)
) ENGINE=InnoDB AUTO_INCREMENT=7429111 ;

SQL執行計劃：
mysql>explain UPDATE test SET is_deleted = 1 WHERE group_id = 1332577 and test_id = 4212859

所以第一個事務先根據group_id索引，已經鎖住primary id，然後再根據test_id索引，鎖定primary id；第二個事務先根據test_id索引，已經鎖住primary id，然後再根據group_id索引，去鎖primary id；所以這樣併發更新就可能出現死索引。

MySQL官方也已經確認了此bug：https://bugs.mysql.com/bug.php?id=77209

解決方法有兩種：

第一、新增test_id+group_id的組合索引，這樣就可以避免掉index merge；

第二、將優化器的index merge優化關閉；

建議選擇第一種方法來避免此問題的發生。

update時，如果where條件裡面涉及多個欄位，區分度都比較高且欄位都分別建了索引的話，mysql會多個索引各走一遍，然後結果取個交集；
單條記錄更新不會引發問題； 多條記錄併發更新時，如果索引行數有重疊，因加鎖順序可能不同，互相等待可能會導致死鎖，為什麼加鎖順序會不同呢？我們的sql中where條件的順序是一定的，那麼加鎖順序也應該一定，為什麼會有加鎖順序不同情況。情況是這樣的，因為我們使用的是兩個單值索引，where條件中是複合條件，那麼mysql會使用index merge進行優化，優化過程是mysql會先用索引1進行掃表，在用索引2進行掃表，然後求交集形成一個合併索引。這個使用索引掃表的過程和我們本身的sql使用索引的順序可能存在互斥，所以造成了死鎖。

更多問題說明及解決方案請參見https://bugs.mysql.com/bug.php?id=77209

另外一個mysql死鎖的場景

在事務中用for迴圈更新一張表，這張表中有主鍵和二級索引，更新就是以二級索引為條件，這時候，因為for迴圈裡面執行的循序不一定，所以有可能導致死鎖

原文：https://blog.csdn.net/zheng0518/article/details/54695605 ;

mysql 官網參考

[1 Jun 2015 11:31] Andrii Nikitin

Description:
On some conditions UPDATE query uses index merge when both indexes expect to retrieve 1 row.

This behavior increases chances for deadlock.

(Corresponding SELECT doesn't show index merge)

How to repeat:
drop table if exists a;

CREATE TABLE `a` (
  `ID` int  AUTO_INCREMENT PRIMARY KEY,
  `NAME` varchar(21),
  `STATUS` int,
  KEY `NAME` (`NAME`),
  KEY `STATUS` (`STATUS`)
) engine = innodb;

set @N=0;
insert into a(ID,NAME,STATUS)
select
	@N:=@N+1,
	@N%1600000, 
	floor(rand()*4)
 from information_schema.global_variables a, information_schema.global_variables b, information_schema.global_variables c 
LIMIT 1600000;

update a set status=5 where rand() < 0.005 limit 1;

explain UPDATE a SET STATUS = 2 WHERE NAME =  '1000000' AND STATUS = 5;

+-------------------------+--------------+------------------------------------------------------
| type        key         | key_len rows | Extra                                                
+-------------------------+--------------+------------------------------------------------------
| index_merge NAME,STATUS | 24,5       1 | Using intersect(NAME,STATUS); Using where; Using temp
+-------------------------+--------------+------------------------------------------------------

Suggested fix:
Do not use index merge when single index is good enough
Try to avoid using index merge in UPDATE to not provoke deadlocks

[25 Feb 2016 18:38] Paul Dubois

Noted in 5.6.30, 5.7.12, 5.8.0 changelogs.

For some queries, an Index Merge access plan was choosen over a range
scan when the cost for the range scan was the same or less.