深入剖析MySQL事务锁 1205-Lock wait timeout exceeded; try restarting transaction

问题截图

该类问题出现的主要原因是：Mysql的 InnoDB存储引擎是支持事务的，事务开启后没有被主动Commit，导致该资源被长期占用，其他事务在抢占该资源时，因上一个事务的锁而导致抢占失败！因此出现 Lock wait timeout exceeded。

查看数据库版本

mysql> select version();
+------------+
| version()  |
+------------+
| 5.7.36-log |
+------------+
1 row in set (0.00 sec)

查看数据库事务

查看会话隔离级别(5.0以上版本)：select @@tx_isolation;
查看会话隔离级别(8.0以上版本)：select @@transaction_isolation;

mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set, 1 warning (0.00 sec)

什么是事务?
事务是逻辑上的一组操作，要么都执行，要么都不执行。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元。事务由事务开始（begin transaction）和事务结束（end transaction）之间执行的全部操作组成。
举个栗子
事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账1000元，这个转账会涉及到两个关键操作就是：将小明的余额减少1000元，将小红的余额增加1000元。万一在这两个操作之间突然出现错误比如银行系统崩溃，导致小明余额减少而小红的余额没有增加，这样就不对了。事务就是保证这两个关键操作要么都成功，要么都要失败。

事务的特性(ACID)
原子性（Atomicity）： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
一致性（Consistency）： 执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；
隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。
并发事务带来的问题
在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对统一数据进行操作）。并发虽然是必须的，但可能会导致以下的问题。

脏读（Dirty read）: 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
丢失修改（Lost to modify）: 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。
不可重复读（Unrepeatableread）: 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
幻读（Phantom read）: 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。
不可重复度和幻读区别：

不可重复读的重点是修改，幻读的重点在于新增或者删除。
举两个栗子
例1（同样的条件, 你读取过的数据, 再次读取出来发现值不一样了 ）：事务1中的A先生读取自己的工资为 1000的操作还没完成，事务2中的B先生就修改了A的工资为2000，导 致A再读自己的工资时工资变为 2000；这就是不可重复读。

例2（同样的条件, 第1次和第2次读出来的记录数不一样 ）：假某工资单表中工资大于3000的有4人，事务1读取了所有工资大于3000的人，共查到4条记录，这时事务2 又插入了一条工资大于3000的记录，事务1再次读取时查到的记录就变为了5条，这样就导致了幻读。

事务隔离级别
SQL 标准定义了四个隔离级别：

READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

在实际应用中，读未提交在并发时会导致很多问题，而性能相对于其他隔离级别提高却很有限，因此使用较少。可串行化强制事务串行，并发效率很低，只有当对数据一致性要求极高且可以接受没有并发时使用，因此使用也较少。因此在大多数数据库系统中，默认的隔离级别是读已提交（如 Oracle）或可重复读。

MVCC
读已提交解决脏读、不可重复读、幻读等问题，使用的是 MVCC：MVCC 全称Multi-Version Concurrency Control，即多版本的并发控制协议。下面的例子很好的体现了 MVCC 的特点：在同一时刻，不同的事务读取到的数据可能是不同的（即多版本）
MVCC 最大的优点是读不加锁，因此读写不冲突，并发性能好。InnoDB 实现 MVCC，多个版本的数据可以共存，主要是依靠数据的隐藏列（也可以称之为标记位）和undo log。其中，数据的隐藏列包括了该行数据的版本号、删除时间、指向undo log的指针等等；当读取数据时，MySQL 可以通过隐藏列判断是否需要回滚并找到回滚需要的undo log，从而实现 MVCC；隐藏列的详细格式不再展开。

InnoDB
InnoDB 实现的读已提交通过next-key lock机制避免了幻读现象。next-key lock是行锁的一种，实现相当于record lock(记录锁) + gap lock(间隙锁)；其特点是不仅会锁住记录本身（record lock的功能），还会锁定一个范围（gap lock的功能）。

事务隔离的原理是什么？
我们都知道事务的四种性质，数据库为了维护这些性质，尤其是一致性和隔离性，一般使用加锁这种方式。同时数据库又是个高并发的应用，同一时间会有大量的并发访问，如果加锁过度，会极大的降低并发处理能力。所以，对于加锁的处理，可以说就是数据库对于事务处理的精髓所在。

information_schema这张数据表保存了MySQL服务器所有数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权限等。再简单点，这台MySQL服务器上，到底有哪些数据库、各个数据库有哪些表，每张表的字段类型是什么，各个数据库要什么权限才能访问，等等信息都保存在information_schema表里面。

记得以前，当出现：ERROR 1205 (HY000): Lock wait timeoutexceeded; try restarting transaction，
要解决是一件麻烦的事情 ；
特别是当一个SQL执行完了，但未COMMIT，后面的SQL想要执行就是被锁，超时结束；
DBA光从数据库无法着手找出源头是哪个SQL锁住了；
有时候看看show engine innodb status , 并结合 show full processlist;能暂时解决问题；但一直不能精确定位；

在5.5中，information_schema库中增加了三个关于锁的表（MEMORY引擎）；
innodb_trx ## 当前运行的所有事务
innodb_locks ## 当前出现的锁
innodb_lock_waits ## 锁等待的对应关系

注意：如果使用select * from table for update时，上面的参数无法看到锁的情况，只有在show engine innodb status能查到。

innodb锁性能监控

mysql> show status like 'innodb_row_lock_%';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 0     |
| Innodb_row_lock_time          | 25    |
| Innodb_row_lock_time_avg      | 6     |
| Innodb_row_lock_time_max      | 16    |
| Innodb_row_lock_waits         | 4     |
+-------------------------------+-------+
5 rows in set (0.04 sec)

Innodb_row_lock_current_waits  当前等待锁的数量
Innodb_row_lock_time          系统启动到现在、锁定的总时间长度
Innodb_row_lock_time_avg      每次平均锁定的时间
Innodb_row_lock_time_max      最长一次锁定时间
Innodb_row_lock_waits         系统启动到现在、总共锁定次数

表字段说明

desc information_schema.innodb_trx;

desc information_schema.innodb_locks;

desc information_schema.innodb_lock_waits;

解决方法：

查看数据库线程情况

show full PROCESSLIST;

字段注释：
id       #ID标识，要kill一个语句的时候很有用
use      #当前连接用户
host     #显示这个连接从哪个ip的哪个端口上发出
db       #数据库名
command  #连接状态，一般是休眠（sleep），查询（query），连接（connect）
time     #连接持续时间，单位是秒
state    #显示当前sql语句的状态
info     #显示这个sql语句

如果要关闭上面的线程可以执行：kill id

没有看到正在执行的很慢SQL记录线程，再去查看innodb的事务表INNODB_TRX，看下里面是否有正在锁定的事务线程，看看ID是否在show full processlist里面的sleep线程中，如果是，就证明这个sleep的线程事务一直没有commit或者rollback而是卡住了，我们需要手动kill掉

select * from information_schema.innodb_trx;

其他的记录不需要关注，因为其他的记录“trx_state”状态为“RUNNING” 即正在执行的事务，并没有锁。
当“trx_state”为LOCK WAIT为占用系统资源的语句，我们需要杀掉这个锁，执行 kill 线程id号，trx_mysql_thread_id为id号，执行命令：kill trx_mysql_thread_id 即可

或者可以把执行线程用时很久的用户直接强制关闭掉

SELECT * from information_schema.`PROCESSLIST` WHERE Time > 1000 AND USER = 'root' ORDER BY TIME desc;

kill id编号

上面是把用户为root执行线程耗时大于1000秒的进程给关闭掉，具体可以自行斟酌执行

总结分析

表数据量也不大，按照普通的情况来说，简单的update应该不会造成阻塞的，mysql都是autocommit，不会出现update卡住的情况，去查看下autocommit的值。

mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+
1 row in set (0.00 sec)

mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.01 sec)

如果值是0的话，这个设置导致原来的update语句如果没有commit的话，你再重新执行update语句，就会等待锁定，当等待时间过长的时候，就会报ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction的错误。
所以赶紧commit刚才执行的update语句，之后 set global autocommit=1;

autocommit详解：

mysql事务支持的引擎是InnoDB，默认情况下autocommit的值为1或者on，也就是开启状态，当autocommit为开启状态时，即使没有手动start transaction开启事务，mysql默认也会将用户的操作当做事务即时提交。如果手动开启了事务可以看如下解释：