产品中心
随着我被拉入一个新的群聊“生产环境死锁问题排查解决”，打破了午后的悠然惬意，点开群聊秒送了一个648超级大礼包（业务不正常，死锁异常日志输出），领导怒斥并要求赶紧排除解决并总结经验，刚好我略懂略懂一点MySQL锁知识，这不得秀一下自己的实力
既然死锁已经发生，也完全不要慌啊，按我说着做，一定能找到原因然后解决
触发下面这条命令获取到线索
官方文档明确指出在 REPEATABLE READ 隔离级别下，默认查询条件下是加 next-key locks (record locks + gap locks ) 或 gap locks，当查询条件使用了唯一索引时，只会对当前查询的唯一记录进行加锁，此时锁为 record locks
官方文档强势占位
MySQL 隔离级别
MySQL InnoDB 锁的类型
MySQL InnoDB 中不同 SQL 语句如何置锁
从死锁日志信息可以得出
接下来我将用一个小例子来复现这次死锁现象
在 MySQL 事务隔离级别 REPEATABLE READ 的情况下，对于 update，delete 等操作语句，查询条件尽量使用索引，减少锁的范围，提高写的并发量，避免不必要的死锁发生影响业务正常运行
这次死锁的说明就到这里，希望大家能看得懂并有所收获，不得不说有些知识我是略过了，大家可以自行查看官方文档补充了解，更多关于update where无索引MySQL死锁的资料请关注其它相关文章！
