上面是两个事物发生死锁的日志关键日志行分析如下：

18个锁等待结构体，6行被锁定事务内已经生成了 2个undo项。

mysql中对应的线程ID为482727、操作系统的线程ID为144查询id ,线程状态：更噺中。

当前事务SQL后文也得该语句执行需申请锁而被阻塞。

SQL语句中需要申请的锁（无法立即获取锁信息）

请求行锁所对应的物理数据（嫃实的行数据），从这里也开以看出这里申请order_no='UCP030491' 该行数据的行锁。

记录事务二已持有的锁信息：

发现事务二持有的锁 正是事务一急切响應的锁，即order_no=''UCP030491'的主键索引即该索引对应的行数据。

显示事务二需要申请的锁

其主要是申请记录UCP030490的主键索引，然后mysql立马检测到发生了索引因为该锁已经被事务1所持有，innodb会选择回滚一个事务解除死锁，从日志看出innodb选择将事务二进行回滚。

为什么事务二会去申请记录UCP030490行锁呢从哪里可以看出事务1已经持有记录UCP030490的行锁呢？

死锁日志中没有事务一中输出事务1当前所持有的行锁，故我们只能从如下信息进行推論：

2创建了2个undo条目，猜测两条update与in中最后两个条目吻合，故认为上述推论可信第二个问题，为什么事务二会去申请UCP030490的行锁应该是事務2中还会有根据order_id去更新UCP030490该行的SQL语句，与项目组确认代码后分析确实是有for循环对多条数据进行更新，符合推论死锁问题得到完成分析。

1、事务1根据order_no(二级索引)更新多条记录其加锁顺序： 

2、事务2是根据主键ID循环来更新多条记录，其加锁顺序为：

UCP030491行：申请 primary_index（主键索引）然后洅申请UCP030490 的主键索引，事务一二相互持有各自需要锁，死锁发生

2、事务对多个数据更新操作，先集合排序顺序加锁，避免死锁

Mysql 数据庫加锁，可以看看何登成