xjy110207

@Buffer2Disk 如果你这个表 uid 不会重复的话，建唯一索引可以快速的解决问题，无需程序做任何改动

@Buffer2Disk 你这个是离线任务的话，其实没太大影响。关于事务，锁方面的知识点你可以参考 mysql-refman 里面 14.7 章节

@Buffer2Disk delete 之类的 gap 锁会锁定记录之前的，你这个 1675 的 id 起始记录位置可能处于 200 到 218 页之间的某个页上，那么这个记录之前的都会被加上 gap 锁

@Buffer2Disk 你这个死锁的原因就是因为两个事务都是修改大量数据， 这些数据的上锁顺序不一致导致的，这是产生死锁的主要原因之一。 一个通用解决方案就是每个事务都尽可能的只修改少量的数据, 从你这个 log 里面来看，这两个事务改动的都比较多， 执行时间都在 10s 以上，出问题概率还是挺大的。
ps: 可能还有一种解决方案就是，因为索引本身是有序的，索引 update delete 会按照索引顺序加锁，你可以修改插入事务，对 uid 排序后再插入，那插入时候获得锁的顺序就跟 delete 时是一样的，理论上也不会出现死锁，顶多就是会有一个事务等待时间较长.

补充: 处于可重复读模式下也不一定会产生 gap 锁，前提是你的语句会使用唯一索引， 但是你这个两条语句就这个信息来看使用的 uid 索引并不是唯一索引。

其产生的根本在于你 mysql 的隔离级别是可重复读，gap 锁仅在可重复读模式下出现。所以要解决这个死锁问题有两种方案:
1、修改你删除定时任务的连接的事务隔离级别为读已提交。
2、将插入定时任务修改为一个事务插入一行。

一个可能的解释:
1、事务 2 先执行，在索引 218 页的位置先获得了一把排它锁
2、事务 1 开始执行，顺序扫描索引并用 gap 锁锁住了处于 200 页的某条记录
3、事务 2 执行到要在 200 页获得插入意图锁的阶段，开始等待事务 1
4、事务 1 顺序扫描到了 218 页，需要获得排它锁，开始等待事务 2
5、至此，就产生了死锁。