数据库死锁引发的掉单问题排查
建议手动复现一下，和只看是两码事、、、、、、、、、、、
1、问题描述
场景：订单支付成功后用订单号批量通知修改计息状态发生死锁
2、前提：数据库表订单号varchar类型唯一索引跟图中name字段相同
3、操作流程
update book set platform_version=400 where name=1111
由于修改订单为批量操作，并且为一条一条修改库表
4、分析：name为唯一索引应该锁行修改，为什么会发生死锁，猜想肯定是两个事物相互依赖导致
分析一：show engine innodb status;命令
第一部分，关键词是：
（1）Transaction 1，事务105528；
（2）在执行update book set platform_version=400 where name=2222
（3）正在等待锁释放(waiting for this lock to be granted)，记录锁(record locks)，主键索引上(index primary)，互斥锁(lock_mode X)，物理记录(physical record)，asc 3333;
分析完这个最近一次死锁后还是有疑问：2222唯一索引干嘛还要拿3333的锁，闹腾、、、、、
分析二：explain小工具查看执行计划
select_type：UPDATE
这是一个简单类型的SQL语句，不含子查询或者UNION。
type：index
访问类型，即找到所需数据使用的遍历方式，潜在的方式有：
（1）ALL（Full Table Scan）：全表扫描；
（2）index：走索引的全表扫描；
（3）range：命中where子句的范围索引扫描；
（4）ref/eq_ref：非唯一索引/唯一索引单值扫描；
（5）const/system：常量扫描；
（6）NULL：不用访问表；
这里为什么是index，唯一索引不应该是走单条吗，怎么会扫全表
key: PRIMARY
实际使用索引：这个是走的主键索引
ref：NULL
哪些列，或者常量用于查找索引上的值，我们条件name说明索引没好使、、、、
rows：7
找到这条数据预读了7行，，尴尬，这不正是全表吗
到这里很明显我们的name唯一索引并 没有起作用，为什么、、、、、
这个时候回到表结构name 是varchar类型，而sql
update boot set platform_version=400 where name=3333;
name用的number类型，，，
类型转换，导致锁升级，造成全表扫、、、
重新执行sql：
果然印证了猜想：
（1）type：range，变为了走索引的字符串比对，范围扫描；
（2）possible_keys：index_name，通过index_name索引找到了记录；
（3）key：index_name，实际使用index_name索引；
（4）ref：const，使用了常量' 3333'进行比对；
（5）rows：1，预估读取行数是1；
就本例而言：需要注意字符串与整数之间的强制类型转换，有时候少一个引号，就会使得行锁升级为表锁。
死锁是MySQL中非常难调试的问题，常见的思路与方法有：
（1）通过多终端模拟并发事务，复现死锁；
（2）通过show engine innodb status; 可以查看事务与锁的信息；
（3）通过explain可以查看执行计划
公众号主要记录各种源码、面试题、微服务技术栈，帮忙关注一波，非常感谢
