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

桃扇骨 2024-02-05 12:13 24阅读 0赞

在使用MySQL时，仅仅是一次很简单的查询响应时间居然需要上百毫秒甚至1秒以上，到底是什么原因导致的这种非常异常的情况？这节课我们一起探究一下。

本篇文章使用的SQL数据如下所示。

mysql> CREATE TABLE `t` (
    
      `id` int(11) NOT NULL,
      `c` int(11) DEFAULT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB;
    
    delimiter ;;
    create procedure idata()
    begin
      declare i int;
      set i=1;
      while(i<=100000) do
        insert into t values(i,i);
        set i=i+1;
      end while;
    end;;
    delimiter ;
    
    call idata();

1 查询长时间不返回  
假设存在如下这种场景，根据主键id查询如果出现长时间不返回，比如如下的语句：

select * from t where id = 1;

像这种根据主键查询还会长时间等待的语句，一般的猜测是有可能被锁。一般是执行show processlist命令查看当前的语句状态。

1.1 等待MDL锁  
使用show processlist命令查看Waiting for table metadata lock的示意图。出现这个状态原因是：现在正在有一个线程正在表t上请求或者持有MDL写锁，把select语句阻塞。

在MySQL5.6版本可以用锁的章节进行复现；

在MySQL8.0版本可以使用三个连接client，一个执行select sleep(1) from t，一个执行alter，一个执行select，可以复现。  
![在这里插入图片描述][dafa8a7d11214d9b94b4bb6cab5a19b5.png]

在MySQL5.7.30版本：

sessionA：begin; select c from t order by rand() limit 3;  
sessionB: alter table t add f int;\[blocked\]  
sessionC: select c from t order by rand() limit 3;\[blocked\]

文中的实例是在MySQL5.7复现，为：  
![在这里插入图片描述][2b088edb7a69489d9a5d7f757a42d949.png]  
sessionA通过锁表获取MDL写锁，写锁具有排他性，因此sessionB虽然是执行读仅需要MDL读锁，也会被阻塞。

这类问题的处理方式，就是找到谁持有 MDL 写锁，然后把它 kill 掉。

但是，由于在 show processlist 的结果里面，session A 的 Command 列是“Sleep”，导致查找起来很不方便。不过有了 performance\_schema 和 sys 系统库以后，就方便多了。

通过查询 sys.schema\_table\_lock\_waits 这张表，我们就可以直接找出造成阻塞的 process id，把这个连接用 kill 命令断开即可。  
![在这里插入图片描述][a83938dfd0f0433ea7183638ca5d25f8.png]  
1.2 等待flush  
如果是执行如下语句出现卡顿：

mysql> select \* from information\_schema.processlist where id=1;  
注意其中的STATE字段，显示为：Waiting for table flush，也就是等待刷盘。  
![在这里插入图片描述][756efe8e1368499fa2b895fc8b021324.png]  
即，此时数据不在内存中，会从磁盘读取到数据后加载到buffer pool中，如果此时buffer pool已经被占满，则会使用LRU淘汰掉旧数据，如果要淘汰的数据时脏页，就会触发flush，造成卡顿。

flush表有两种格式：

/**
    指定表t，代表只关闭表t
    */
    flush tables t with read lock;
    /**
    没有指定表，代表只关闭MySQL打开的所有表
    */
    flush tables with read lock;

关闭所有已打开的表对象，同时将查询缓存中的结果清空。就是说Flush tables的一个效果就是会等待所有正在运行的SQL请求结束。 因为，SQL语句在执行前，都会打开相应的表对象，如select \* from t1语句，会找到t1表的frm文件，并打开表内存对象。为了控制表对象使用的内存空间和其他资源，MySQL会隐式（后台表对象管理线程）或显式（flush tables等）来关闭已打开但并没有使用的表对象。 然而，正在使用的表对象是不能关闭的（如SQL请求仍在运行），因此，Flush Tables操作会被正在运行的SQL请求阻塞。

![在这里插入图片描述][0a14b6469c0f4ee3870f39ec8a941bc0.png]  
![在这里插入图片描述][10ec82b1eb7c4c9091723fc575b81098.png]  
根据show processlist查询的id，将select sleep(1) from t的进行先结束，然后flush table t的命令执行完，sessionC就会执行。

1.3 等待行锁  
还有第三种情况就是我们最为熟悉的锁。假设执行语句如下，在查询时开启共享锁：

mysql> select * from t where id=1 lock in share mode;

在语句执行的加锁会增加锁冲突的几率，从而导致语句之间的相互等待锁释放。  
![在这里插入图片描述][c2594bf174c540cbb67032faf85ab48f.png]  
![在这里插入图片描述][c1e205a1616945509e0591151eee2417.png]  
此时，由于sessionA启动了事务，占用了写锁，阻塞了sessionB的共享锁的获取。

在MySQL5.7可以使用sys.innodb\_lock\_waits表查询到占用写锁的线程：

mysql> select \* from t sys.innodb\_lock\_waits where  
locked\_table=‘`test`.`t`’\\G

![在这里插入图片描述][ecd5d4c1c77f47c18d8ffb52e4ce43e7.png]  
可以看到，这个信息很全，4 号线程是造成堵塞的罪魁祸首。而干掉这个罪魁祸首的方式，就是 KILL QUERY 4 或 KILL 4。不过，这里不应该显示“KILL QUERY 4”。

这个命令表示停止 4 号线程当前正在执行的语句，而这个方法其实是没有用的。因为占有行锁的是 update 语句，这个语句已经是之前执行完成了的，现在执行 KILL QUERY，无法让这个事务去掉 id=1 上的行锁。

实际上，KILL 4 才有效，也就是说直接断开这个连接。这里隐含的一个逻辑就是，连接被断开的时候，会自动回滚这个连接里面正在执行的线程，也就释放了 id=1 上的行锁。

2 查询慢  
我们知道MySQL的使用规范中，长事务是严禁使用的，或者说不建议使用的。那么长事务是否也会导致慢查询呢？

在如下情况下，可能会出现查询慢的情况，如图所示：  
![在这里插入图片描述][7bf3852af6f84a1989d8ef9fb7cbd173.png]  
第一条sql查询的是当前事务版本时，id = 1 时的值，但是第二条sql 查询可以得知当前值得最新版本的值为1000001，所以在查询数据时需要进行记录版本的回滚，拿到自己事务可见的记录的版本。所以如果当前事务比较老并且当前这个数据存在大量的版本，那么就对该记录进行大量的回滚操作，消费个更多的时间。

此时可以通过如下场景复现：

![在这里插入图片描述][e9d2f58cf39745ebb3d15501aa4f91fd.png]  
你看到了，session A 先用 start transaction with consistent snapshot 命令启动了一个事务，之后 session B 才开始执行 update 语句。

session B 执行完 100 万次 update 语句后，id=1 这一行处于什么状态呢？  
![在这里插入图片描述][49980a2722f949bba31527bf62e8e64f.png]  
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 的目的是方便你看图。

[dafa8a7d11214d9b94b4bb6cab5a19b5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/b0ca2d630501472797d919c8a01a2d9b.png
[2b088edb7a69489d9a5d7f757a42d949.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/ca2e945c0b5c49678cb30b07c93fcfb6.png
[a83938dfd0f0433ea7183638ca5d25f8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/6e8e74771f63483f8213a9e8af6f4795.png
[756efe8e1368499fa2b895fc8b021324.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/2a7679df88dd4f749a031cabe5b8ea64.png
[0a14b6469c0f4ee3870f39ec8a941bc0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/0eba64e0d9814075b35962e2fc2c6eb8.png
[10ec82b1eb7c4c9091723fc575b81098.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/3dca40469cd646479f485e7b40c6a525.png
[c2594bf174c540cbb67032faf85ab48f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/e04b8bb8e5824f2294950d6a0a7483be.png
[c1e205a1616945509e0591151eee2417.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/cc532ffd38a14051ac9ee9134b323e22.png
[ecd5d4c1c77f47c18d8ffb52e4ce43e7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/a0156959831c4336adec5e497610150b.png
[7bf3852af6f84a1989d8ef9fb7cbd173.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/01d77a8894aa43f1a86af60b89caa22a.png
[e9d2f58cf39745ebb3d15501aa4f91fd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/8a74de8713de417f9f285fadc25ee217.png
[49980a2722f949bba31527bf62e8e64f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/05/c11fb115d0464c6dbe8f3cebb52d0746.png