### Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when tryin

Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

; Deadlock found when trying to get lock; try restarting transaction; nested exception is com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction，堆栈信息：
org.springframework.dao.DeadlockLoserDataAccessException:

Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

死锁出现

3个 for---->批量删除解决：

原有：三层循环去删除，并且使用错了delete方法，实际走的是逻辑删除，只是修改状态。然后这个店铺状态的时候，产生了mysql死锁。所谓死锁：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。

猜测发生死锁的原因是

导入excel表的有许多重复的名称，刚好1进来去delete（可能是逻辑删除，可能是物理删除）这个重复shopId。而且1还没有执行完，2又过来了，2找到类似店铺也是这个重复的shopId使用delete方法，直接导致两个线程争夺同一个资源。造成了死锁。改造的方法最后是这样的

使用要删除的shopId放到一个集合中，在统一在mybatis批量删除。后续未发现死锁现象。之前主要是导入7000店铺的时候，大量重复名称店铺导致了高并发死锁的这个场景。