MySQL：为什么查询一行数据也要花费上百毫秒( 二 ) _MySQL

文章插图

文章插图
此时，由于sessionA启动了事务，占用了写锁，阻塞了sessionB的共享锁的获取。
在MySQL5.7可以使用sys.innodb_lock_waits表查询到占用写锁的线程：
mysql> select * from t sys.innodb_lock_waits where locked_table='`test`.`t`'G

文章插图
图片
可以看到，这个信息很全，4 号线程是造成堵塞的罪魁祸首。而干掉这个罪魁祸首的方式，就是 KILL QUERY 4 或 KILL 4 。不过，这里不应该显示“KILL QUERY 4” 。
这个命令表示停止 4 号线程当前正在执行的语句，而这个方法其实是没有用的。因为占有行锁的是 update 语句，这个语句已经是之前执行完成了的，现在执行 KILL QUERY，无法让这个事务去掉 id=1 上的行锁。
实际上，KILL 4 才有效，也就是说直接断开这个连接。这里隐含的一个逻辑就是，连接被断开的时候，会自动回滚这个连接里面正在执行的线程，也就释放了 id=1 上的行锁。
2 查询慢我们知道MySQL的使用规范中，长事务是严禁使用的，或者说不建议使用的。那么长事务是否也会导致慢查询呢？
在如下情况下，可能会出现查询慢的情况，如图所示：

文章插图
图片
第一条sql查询的是当前事务版本时，id = 1 时的值，但是第二条sql 查询可以得知当前值得最新版本的值为1000001，所以在查询数据时需要进行记录版本的回滚，拿到自己事务可见的记录的版本。所以如果当前事务比较老并且当前这个数据存在大量的版本，那么就对该记录进行大量的回滚操作，消费个更多的时间。
此时可以通过如下场景复现：

文章插图
图片
你看到了，session A 先用 start transaction with consistent snapshot 命令启动了一个事务，之后 session B 才开始执行 update 语句。
session B 执行完 100 万次 update 语句后，id=1 这一行处于什么状态呢？

文章插图
图片
session B 更新完 100 万次，生成了 100 万个回滚日志 (undo log) 。
带 lock in share mode 的 SQL 语句，是当前读（读最新版本的数据），因此会直接读到 1000001 这个结果，所以速度很快；而 select * from t where id=1 这个语句，是一致性读，因此需要从 1000001 开始，依次执行 undo log，执行了 100 万次回滚以后，才将 1 这个结果返回。
注意，undo log 里记录的其实是“把 2 改成 1”，“把 3 改成 2”这样的操作逻辑，画成减 1 的目的是方便你看图。