【mysql 提高查询效率】Mysql 数据库查询好慢问题解决

mysql查询为什么会慢，关于这个问题，在实际开发经常会遇到。下面和大家一起聊聊如何解决这个问题。

遇到这种问题，我们一般也会想到是因为索引。看看是否没有建立索引，如果没有，相应应该建立索引。
如：

CREATE INDEX index_create_time ON temperature_new_output (create_time)

那除开索引之外，还有哪些因素会导致数据库查询变慢呢？要回答这个问题，我们先从sql 语句的查询原理来说。Mysql架构如下：

我们先来看下，一条查询语句下来，会经历哪些流程。
我们平常写的应用代码（pymysql之类），这时候就叫客户端了。

客户端底层会带着账号密码，尝试向mysql建立一条TCP长链接。
mysql的连接管理模块会对这条连接进行管理。
建立连接后，客户端执行一条查询sql语句
客户端会将sql语句通过网络连接给mysql。
mysql收到sql语句后，会在分析器中先判断下SQL语句有没有语法错误，如果有错误，会报错。
接下来是优化器，在这里会根据一定的规则选择该用什么索引。
接下来是通过执行器去调用存储引擎的接口函数。存储引擎类似于一个个组件，它们才是mysql真正获取一行行数据并返回数据的地方，存储引擎是可以替换更改的，既可以用不支持事务的MyISAM，也可以替换成支持事务的Innodb。这个可以在建表的时候指定。现在最常用的是 InnoDB 。
InnoDB 获取数据，返回客户端。

我们就重点说这个innoDB。InnoDB中，因为直接操作磁盘会比较慢，所以加了一层内存提提速，叫 buffer pool ，这里面，放了很多内存页，每一页16KB，有些内存页放的是数据库表里看到的那种一行行的数据，有些则是放的索引信息。

查询SQL到了InnoDB中。会根据前面优化器里计算得到的索引，去查询相应的索引页，如果不在buffer pool里则从磁盘里加载索引页。再通过索引页加速查询，得到数据页的具体位置。如果这些数据页不在buffer pool中，则从磁盘里加载进来。这样我们就得到了我们想要的一行行数据。最后将得到的数据结果返回给客户端。

下面我们可以进行慢查询分析

我们可以通过开启 profiling 看到流程慢在哪。

mysql> show variables like 'profiling';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling     | ON    |
+---------------+-------+
1 row in set (0.00 sec)如果没有开启，我们设置开启。
mysql> set profiling=ON;
Query OK, 0 rows affected, 1 warning (0.00 sec)

然后正常执行sql语句。这些SQL语句的执行时间都会被记录下来，此时你想查看有哪些语句被记录下来了，可以执行 show profiles;

mysql> show profiles;
+----------+------------+---------------------------------------------------+
| Query_ID | Duration   | Query                                             |
+----------+------------+---------------------------------------------------+
|        1 | 0.06811025 | select * from user where age>=60                  |
|        2 | 0.00151375 | select * from user where gender = 2 and age = 80  |
|        3 | 0.00230425 | select * from user where gender = 2 and age = 60  |
|        4 | 0.00070400 | select * from user where gender = 2 and age = 100 |
|        5 | 0.07797650 | select * from user where age!=60                  |
+----------+------------+---------------------------------------------------+
5 rows in set, 1 warning (0.00 sec)

关注下上面的 query_id ，比如 select * from user where age>=60 对应的query_id是1，如果你想查看这条SQL语句的具体耗时，那么可以执行以下的命令。

mysql> show profile for query 1;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000074 |
| checking permissions | 0.000010 |
| Opening tables       | 0.000034 |
| init                 | 0.000032 |
| System lock          | 0.000027 |
| optimizing           | 0.000020 |
| statistics           | 0.000058 |
| preparing            | 0.000018 |
| executing            | 0.000013 |
| Sending data         | 0.067701 |
| end                  | 0.000021 |
| query end            | 0.000015 |
| closing tables       | 0.000014 |
| freeing items        | 0.000047 |
| cleaning up          | 0.000027 |
+----------------------+----------+
15 rows in set, 1 warning (0.00 sec)

通过上面的各个项，大家就可以看到具体耗时在哪。比如从上面可以看出Sending data的耗时最大，这个是指执行器开始查询数据并将数据发送给客户端的耗时，因为我的这张表符合条件的数据有好几万条，所以这块耗时最大，也符合预期。

一般情况下，我们开发过程中，耗时大部分时候都在 Sending data 阶段，而这一阶段里如果慢的话，最容易想到的还是索引相关的原因。查询索引分析，我们可以用explain 命令，在select 前面加上。

索引问题：

走了索引还是很慢，有些sql，用 explain 命令看，明明是走索引的，但还是很慢。一般是两种情况：

第一种是索引区分度太低，比如网页全路径的url链接，这拿来做索引，一眼看过去全都是同一个域名，如果前缀索引的长度建得不够长，那这走索引跟走全表扫描似的，正确姿势是尽量让索引的区分度更高，比如域名去掉，只拿后面URI部分去做索引。
第二种是索引中匹配到的数据太大，这时候需要关注的是explain里的 rows 字段了。它是用于预估这个查询语句需要查的行数的，它不一定完全准确，但可以体现个大概量级。当它很大时，一般常见的是下面几种情况。
如果这个字段具有唯一的属性，比如电话号码等，一般是不应该有大量重复的，那可能是你代码逻辑出现了大量重复插入的操作，你需要检查下代码逻辑，或者需要加个唯一索引限制下。如果这个字段下的数据就是会很大，是否需要全部拿？如果不需要，加个 limit 限制下。如果确实要拿全部，那也不能一次性全拿，今天你数据量小，可能一次取一两万都没啥压力，万一哪天涨到了十万级别，那一次性取就有点吃不消了。你可能需要分批次取，具体操作是先用 order by id 排序一下，拿到一批数据后取最大id 作为下次取数据的起始位置。

连接数过小问题
我们可以看到，mysql的server层里有个连接管理，它的作用是管理客户端和mysql之间的长连接。正常情况下，客户端与server层如果只有一条连接，那么在执行sql查询之后，只能阻塞等待结果返回，如果有大量查询同时并发请求，那么后面的请求都需要等待前面的请求执行完成后，才能开始执行。

因此很多时候我们的应用程序，比如go或java这些，会打印出sql执行了几分钟的日志，但实际上你把这条语句单独拎出来执行，却又是毫秒级别的。这都是因为这些sql语句在等待前面的sql执行完成。怎么解决呢？如果我们能多建几条连接，那么请求就可以并发执行，后面的连接就不用等那么久了。

而连接数过小的问题，受数据库和客户端两侧同时限制。数据库连接数过小。Mysql的最大连接数默认是 100 , 最大可以达到 16384 。

数据库端连接数过小：
可以通过设置mysql的 max_connections 参数，更改数据库的最大连接数。

mysql> set global max_connections= 500;
Query OK, 0 rows affected (0.00 sec)mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 500   |
+-----------------+-------+
1 row in set (0.00 sec)

上面的操作，就把最大连接数改成了500。

客户端连接数过小
数据库连接大小是调整过了，但貌似问题还是没有变化？还是有很多sql执行达到了几分钟，甚至超时？
那有可能是因为你应用侧（go，java写的应用，也就是mysql的客户端）的连接数也过小。
应用侧与mysql底层的连接，是基于TCP协议的长链接，而TCP协议，需要经过三次握手和四次挥手来实现建连和释放。如果我每次执行sql都重新建立一个新的连接的话，那就要不断握手和挥手，这很耗时。所以一般会建立一个长连接池，连接用完之后，塞到连接池里，下次要执行sql的时候，再从里面捞一条连接出来用，非常环保。

buffer pool太小
连接数是上去了，速度也提升了。有没有其他办法可以让速度更快呢？我们在前面的数据库查询流程里，提到了进了innodb之后，会有一层内存buffer pool，用于将磁盘数据页加载到内存页中，只要查询到buffer pool里有，就可以直接返回，否则就要走磁盘IO，那就慢了。也就是说，如果我的buffer pool 越大，那我们能放的数据页就越多，相应的，sql查询时就更可能命中buffer pool，那查询速度自然就更快了。

可以通过下面的命令查询到buffer pool的大小，单位是 Byte 。

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

也就是 128Mb 。

如果想要调大一点。可以执行

mysql> set global innodb_buffer_pool_size = 536870912;
Query OK, 0 rows affected (0.01 sec)mysql> show global variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 536870912 |
+-------------------------+-----------+
1 row in set (0.01 sec)

这样就把buffer pool增大到512Mb了。

但是吧，如果buffer pool大小正常，只是别的原因导致的查询变慢，那改buffer pool毫无意义。

但问题又来了。怎么知道buffer pool是不是太小了？这个我们可以看 buffer pool的缓存命中率。

通过 show status like ‘Innodb_buffer_pool_%’; 可以看到跟buffer pool有关的一些信息。

Innodb_buffer_pool_read_requests 表示读请求的次数。

Innodb_buffer_pool_reads 表示从物理磁盘中读取数据的请求次数。

所以buffer pool的命中率就可以这样得到：
buffer pool 命中率 = 1 - (Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests) * 100%

比如我上面截图里的就是，1 - (405/2278354) = 99.98%。可以说命中率非常高了。

一般情况下 buffer pool命中率都在 99% 以上，如果低于这个值，才需要考虑加大innodb buffer pool的大小。

当然，还可以把这个命中率做到监控里，这样半夜sql变慢了，早上上班还能定位到原因，就很舒服。

总结

数据查询过慢一般是索引问题，可能是因为选错索引，也可能是因为查询的行数太多。
客户端和数据库连接数过小，会限制sql的查询并发数，增大连接数可以提升速度。
innodb里会有一层内存buffer pool用于提升查询速度，命中率一般>99%，如果低于这个值，可以考虑增大buffer pool的大小，这样也可以提升速度。

【mysql 提高查询效率】Mysql 数据库查询好慢问题解决相关推荐

mysql的查询分析工具下载_万能数据库查询分析器(ODBC数据库查询分析工具)V7.03 最新版...
万能数据库查询分析器(ODBC数据库查询分析工具)是一款功能强大,性能良好的数据库查询辅助工具,对开发人员来说是一款省时省力的数据库分析工具. 功能特点: 可以通过它查询ODBC数据源(包括世面上所有 ...
Oracle 查询分析器的数据库查询工具。
最近找到了一个小巧的Oracle 工具不过要注册,真不爽 Canoe是一个相当于Toad.SQL Server查询分析器的数据库查询工具. 支持Oracle 8i,Oracle 9i, 无需先安装客 ...
mysql嵌套查询效率低,连接查询代替嵌套查询提高select效率
当数据库中含有大量数据时,而我们所需要的信息不再是仅仅局限于一个表中的数据信息,这时我们需要将对一个表进行信息查询转而变成对多个表进行信息搜索并进行组合. 解决这样的问题我们通常是运用嵌套查询的方法, ...
mysql 查找数据过程_mysql数据库查询过程探究和优化建议
查询过程探究我们先看一下向mysql发送一个查询请求时,mysql做了什么? 如上图所示,查询执行的过程大概可分为6个步骤: 客户端向MySQL服务器发送一条查询请求服务器首先检查查询缓存,如果命 ...
mysql数据库查询工具''_数据库查询工具
多肉数据查询系统是一款非常实用的查询多肉植物小工具,软件提供了多肉植物的习性.照片.如何培养等等功能,对于喜欢在家里养些花花草草的用户会有很大的帮助,操作也很简单,基本一看就会.接下来非凡软件站小编就 ...
MySQL在存经纬度的数据库查询最近距离的应用
A点经纬度:x1,y1 B点经纬度x2,y2 计算公式: 距离可以用r*arccos[cos(y1)*cos(y2)*cos(x1-x2)+sin(y1)*sin(y2)]来算r是地球半径6370k ...
mysql php 缓存机制_mysql数据库查询缓存原理是什么
mysql数据库查询缓存原理是:1.缓存SELECT操作的结果集和SQL语句,key为sql,value为查询结果集:2.如果新的SELECT语句到了,以这个sql为key去缓存中查询,如果匹配,就把 ...
mysql 创建查询删除_MYSQL数据库查询删除创建企业基本知识
数据查询语言(DQL)从表中获取数据 select + where (位置) order by(排序) group by haveby 查询用户:select user,host,passwo ...
mysql创建全外连接的视图_「MySql学习」Mysql学习系列之常用数据库查询语句
一.简单查询简单的Transact-SQL查询只包括选择列表.FROM子句和WHERE子句.它们分别说明所查询列.查询的表或视图.以及搜索条件等.10.5pt;font-family:"A ...
mysql读数据入库es_es数据库查询
DB 与 Elasticsearch 混合之应用系统场景分析探讨作者介绍李猛,Elastic Stack深度用户,通过Elastic工程师认证,2012年接触Elasticsearch,对Elas ...

【mysql 提高查询效率】Mysql 数据库查询好慢问题解决

【mysql 提高查询效率】Mysql 数据库查询好慢问题解决相关推荐

最新文章

热门文章

【mysql 提高查询效率】​Mysql 数据库查询好慢问题解决

【mysql 提高查询效率】​Mysql 数据库查询好慢问题解决相关推荐

最新文章

热门文章

【mysql 提高查询效率】Mysql 数据库查询好慢问题解决

【mysql 提高查询效率】Mysql 数据库查询好慢问题解决相关推荐