发现有MySQL锁超时的谬误日志。
不必想，必定有另一个事务正在批改这条订单，持有这条订单的锁。
导致以后事务获取不到锁，始终期待，直到超过锁超时工夫，而后报错。
既然问题曾经分明了，接下来就轮到怎么排查一下到底是哪个事务正在持有这条订单的锁。
好在MySQL提供了丰盛的工具，帮忙咱们排查锁竞争问题。
现场复现一个这个问题：
创立一张用户表，造点数据：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `name` varchar(50) NOT NULL DEFAULT '' COMMENT '姓名', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;事务1，更新id=1的用户姓名，不提交事务：
begin;update user set name='一灯' where id=1;事务2，删除id=1的数据，这时候会产生锁期待：
begin;delete from user where id=1;接下来，咱们就通过MySQL提供的锁竞争统计表，排查一下锁期待问题：
先查一下锁期待状况：
select * from information_schema.innodb_lock_waits;
能够看到有一个锁期待的事务。
而后再查一下正在竞争的锁有哪些？
select * from information_schema.innodb_locks;
能够看到，MySQL统计的十分具体：
lock_trx_id 示意事务ID
lock_mode 示意排它锁还是共享锁
lock_type 示意锁定的记录，还是范畴
lock_table 锁的表名
lock_index 锁定的是主键索引
再查一下正在执行的事务有哪些？
select * from information_schema.innodb_trx;
能够分明的看到正在执行的事务有两个，一个状态是锁期待（LOCK WAIT），正在执行的SQL也打印进去了：
delete from user where id=1;正是事务2的删除语句。
不必问，第二条，显示正在运行状态（RUNNING）的事务就是正在持有锁的事务1，MySQL线程id（trx_mysql_thread_id）是193。
咱们用MySQL线程id查一下事务线程id：
select * from performance_schema.threads where processlist_id=193;
找到对应的事务线程id是218，而后再找一下这个线程正在执行的SQL语句：
select THREAD_ID,CURRENT_SCHEMA,SQL_TEXT from performance_schema.events_statements_current where thread_id=218;
能够分明的看到这个线程正在执行的SQL语句就是事务1的update语句。
持有锁的SQL语句找到了，接下来再去找对应的业务代码也就轻而易举了。
以上是基于MySQL5.7版本，在MySQL8.0版本中有些命令曾经删除了，替换成了其余命令，下篇文章再讲一下MySQL8.0怎么定位MySQL锁超时问题。感兴趣的小伙伴能够本人再虚拟机上部署一套零碎本人尝试以下,博主比拟罕用的就是3A云服务器。