问题

作为一个程序员SQL查询慢的问题在工作和面试中都是会经常遇到的问题, 一般情况下我们都会联想到索引问题, 那么除了索引问题还有什么其他的场景会导致SQL查询慢呢?

MySQL执行查询逻辑

例如我们使用可视化工具执行这样一条SQL: select * from user_info where age = 10;

 首先可视化工具会携带mysql的用户名和密码与mysql建立连接, 然后执行select * from user_info where age = 10; 此条SQL会通过网络连接发送给mysql数据库, 数据库中的SQL分析器会先分析SQL是否有语法错误, 语法分析通过后会进入规则优化器, 规则优化器会对SQL进行分析选择该用什么索引,优化完毕后就会进入到SQL执行器,SQL执行器会调用存储引擎的接口函数来进行查询, 然后将查询到的数据返回给客户端

这里着重讲一下存储引擎

MySQL一般情况下我们都会选择InnoDB

InnoDB

我们知道如果直接查询磁盘内的数据是比较慢的, 索引InnoDB给自己加了一个缓存区BufferPool,用来实现快速查询, BufferPool中既有行数据又有索引数据

 BufferPool的原理与我们使用redis进行缓存差不多, 首先会先通过规则优化器中选择的索引到BufferPool中进行查询, 如果没有则先从磁盘中查询出来然后放到BufferPool中, 行数据也同理, 如果BufferPool中没有则从磁盘中查询放入到行数据中

SQL查询慢的原因

SQL规则优化器选错索引

一般情况下导致SQL慢的原因都是因为SQL规则优化器选择错索引导致的, 这类问题可以通过explain命令进行排查, 排查过程就不详细介绍了

连接数过小

这个问题可以举一个例子, 比如mysql现在只能建立一个连接, 但是我有多条SQL需要执行, 因此MySQL只能一条一条来执行, 如果可以建立多个链接这样就可以并发执行效率会快很多, 这种问题一般会受到服务端和客户端两方面的制约, Mysql服务端默认的最大连接数是100, 可以通过执行命令 set global max_connections=500; 将最大连接数改为500

应用端链接数过小

前面提到了服务端链接数过小, 那么应用端如果配置的连接数过小也会导致查询慢, 原理是因为应用端与服务端通信需要建立TCP长连接, 而建立长连接开销较大因此应用端会维护一个连接池, 每次需要有SQL执行的时候会从连接池中捞出一条TCP链接,用完之后再放回连接池, 如果此连接池的数量设置太小也会导致如同服务端一样的SQL需要排队查询的情况

BufferPool太小

前面介绍InnoDB的时候提到了BufferPool, 它会缓存磁盘中的数据, 加速查询,也就是说如果BufferPool越大那么能放的数据也就越多, 那么SQL查询时就更有可能命中BufferPool自然查询速度就更快, 因此我们可以通过更改BufferPool的大小来加速查询

那么问题来了, 如果不是因为BufferPool小导致的查询慢我们修改BufferPool的大小是毫无意义的, 所以我们怎么确定是BufferPool的问题呢?

可以通过sql命令: show status like 'Innodb_buffer_pool_%'命令来查询, 查询完毕我们可以看到一些数据, 我们可以通过 (读取磁盘次数/请求次数)来计算BufferPool的命中率, 一般情况下BufferPool的命中率在99%以上, 只要命中率高于这个值那么BufferPool的大小就是正常的