为什么查询数据不多,却慢的离谱,在我请教了隔壁新来的阿里大佬后

本文已收录GitHub，更有互联网大厂面试真题，面试攻略，高效学习资料等

这篇文章主要记录，造成查询数量不大的情况下，造成查询缓慢的原因，以及相应的解决方法。

环境说明：

MySQL 版本 5.7.27
隔离级别：RR

锁等待造成查询速度很慢

MDL 锁

如开启如下事务：

Session A 持有表 t MDL 写锁。Session B 需要 MDL 读锁。这时读写锁互斥，Session B 被阻塞。

flush 阻塞

flush 操作一般来说很快就能执行完，当通过查询进程状态后，看到被 flush 操作被阻塞，一般都是由其他语句引起的。

如下面事务：

Session A 在扫描每一行时会休眠1s，而 Session B 的 flush tables t; 需要关闭表 t，要等 Session A 结束。后面的 Session C 被 Session B 阻塞了。

flush 的操作示范：

#  flush 表 t
flush tables t with read lock;
# flush 所有表
flush tables with read lock;
flush 的作用在 全局锁 文章中已经介绍过，FTWRL 主要用于 MyISAM 这样不支持事务的引擎，保证在备份时视图数据一致性。

行锁

这里的行锁，用两阶段锁来体现。其他如间歇锁和 next-key 锁都会可以造成这样的现象。

Session A 拥有 id=1 这行的写锁，Session B 想要拥有这一行的读锁，读写锁互斥。

解决方法

首先通过 show processlist; 命令查询被阻塞的状态信息。如需进一步分析的话，可以将 performance_schema=on 打开，通过查询 select blocking_pid from sys.schema_table_lock_waits; 具体造成锁等待的原因。然后 kill掉相应的 session.

在打开 performance_schema 会有一定的性能损失。

查询确实慢

没有设置合适的索引

如果没有设置合适的索引，导致扫描行数过多，时间自然就慢了。对于这种情况，可以开启慢查询日志，查看语句的执行过程，然后进行分析。

默认情况，慢查询日志时关闭的，打开方式如下：

# 查询慢查询日志状态及存储位置
# show variables  like '%slow_query_log%';

# 查询慢查询日志的设置时间
show variables  like '%long_query%';

# 临时打开慢查询日志，MySQL 重启后失效
set global slow_query_log=1;

# 改变时间
set long_query_time=0;