MySQL 锁等待超时（Lock wait timeout exceeded）

问题：Lock wait timeout exceededtry restarting transaction

MySQL版本：5.6.44

官方文档

意思是：InnoDB在锁等待超时过期时报告此错误。等待时间过长的语句被回滚（而不是整个事务）。如果SQL语句需要等待其他事务完成的时间更长，则可以增加 innodb_lock_wait_timeout 配置选项的值；如果太多长时间运行的事务导致锁定问题并降低繁忙系统上的并发性，则可以减少该选项的值。

锁等待超时，可能是出现了死锁，也可能有事务长时间未提交

库：information_schema

表：

查看各表信息

innodb_trx 表

innodb_locks 表

innodb_lock_waits 表

processlist 表

模拟出现死锁

准备一张只有主键的表：t_test (id)

Navicat 新建查询1

Navicat 新建查询2

检查是否锁表

查询当前正在执行的事务

查询当前出现的锁

查询锁等待对应的关系

查询等待锁的事务所执行的SQL

最后，事务2 等待锁超时报错： Lock wait timeout exceededtry restarting transaction

通过事务线程ID查找进程信息

win10 查看端口信息

官方定义如下：两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。

这个就好比你有一个人质，对方有一个人质，你们俩去谈判说换人。你让对面放人，对面让你放人。

看到这里，也许你会有这样的疑问，事务和谈判不一样，为什么事务不能使用完锁之后立马释放呢？居然还要 *** 作完了之后一直持有锁？这就涉及到 MySQL 的并发控制了。

MySQL的并发控制有两种方式，一个是 MVCC，一个是两阶段锁协议。那么为什么要并发控制呢？是因为多个用户同时 *** 作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（ 可串行化调度 ）。具体的并发控制这里不再展开。咱们继续深入讨论两阶段锁协议。

官方定义：

对应到 MySQL 上分为两个阶段：

就是说呢，只有遵循两段锁协议，才能实现 可串行化调度 。

但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁，并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。

MySQL有两种死锁处理方式：

由于性能原因，一般都是使用死锁检测来进行处理死锁。

死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。

检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。

MySQL如何处理死锁

---