性能测试：数据库性能问题实战分析

淡淡的烟草味﹌ 2023-09-25 14:00 100阅读 0赞

**接口压测分析**  
现在我们来压测一个获取用户信息接口，这个接口会涉及到数据库的数据查询。我们的项目是部署正在应用服务器上面的，因此我们需要同时监控应用服务器和数据库服务器。![在这里插入图片描述][c099cbf4318242dbb7ab7351e4cbcd99.png]  
那么下面我们来看一下tomcat的这台服务器，cpu的使用率并不高，包括网络、磁盘IO等都没有什么问题。![!\[在这里插入图片描述\](https://img-blog.csdnimg.cn/694a21f136954a7fa281e2bde2cf33d9.png][https_img-blog.csdnimg.cn_694a21f136954a7fa281e2bde2cf33d9.png]  
下面我们在来看一下数据库的服务器，可以看到cpu已经高达100%了。存在非常明显的性能问题。那么我们可以初步分析，问题可能出现在数据库查询上面，因为我们只用了10个并发，这个并不算多。![在这里插入图片描述][12217f7a78f14e6b8f6016640e9a7228.png]  
**数据库性能分析-索引**

下面我们来回看一下我们前面压测所出现的现象：  
TPS很低，响应时间很长，数据库服务器cpu很高（接近100%），应用服务器负载比较低。

通常我们数据库服务器cpu很高，一般都是因为SQL执行效率低导致的。可能有三方面原因：

*  1、数据库表中缺少必要的索引；
 *  2、索引不生效；
 *  3、SQL不够优化；

**关于索引**

索引是对数据库表中一列或多列的值进行排序的一种结构，存储了表中的关键字段，使用索引可快速访问数据库表中的特定信息。

那么我们初步定位是由于SQL导致的性能问题，我们是不是可以对SQL进行监控呢？

**我们需要查询下mysql是否开启了慢查询**

1｜show variables like '%slow_query_log%

我们可以看到慢sql并没有开启  
![在这里插入图片描述][2a889d0dcf4248d6a7a1f47af8f65471.png]  
下面我们需要对mysql配置慢查询。具体如何配置，可以查看我的这篇博客：[https://blog.csdn.net/weixin\_42274846/article/details/128032102][https_blog.csdn.net_weixin_42274846_article_details_128032102]

下面我们开始对SQL进行监控，进入到mysql存放的日志路径下（之前慢查询配置中有返回具体的日志路径），因为压测前，我们并不知道里面的数据是不是我们之前压测的数据，所以我们输入 `> 文件名称，如 > mysql-slow.log` 来清空里面的数据，然后再进行压测。

压测过程中，我们可以看到日志中出现了大量的SQL日志，那么我们可以确定再压测的过程中，这些SQL的响应时间已经超过了我们原先配置的预期值了。![在这里插入图片描述][7997d3090d2a4b30b0e12adcd6652e44.png]  
那么我们已经知道有哪些慢SQL了，接下来应该如何对这些SQL进行分析呢？

在/usr/bin目录下，使用mysql自带命令 mysqldumpslow 。这个工具下面提供了一些参数，关于参数的介绍，可以再我之前的慢sql配置的博客中，有介绍。

那么我们下面用如下命令进行分析：

1｜mysqldumpslow –s at -t 5 mysql-slow.log
    // 显示出耗时最长的5个

![在这里插入图片描述][ab4eae044ddb40f6be0891c7c1af109a.png]  
上面我们可以看到返回了一条SQL。我们来具体看看这些返回的数据到底是什么含义：

1.  Count：顾名思义，就是这条SQL执行的次数
2.  Time：SQL执行的时间，这里我配置的慢SQL时间是（0.05s）,这里0.07s相当于是70ms，可能很多人会觉得70ms算短的，时间确实很短，但是对于一个接口而言，数据库就用到了70ms，那么整个http请求，包含业务逻辑、网络因素、以及前端渲染等时长，最终用户所得到的响应是非常长的。
3.  下面显示了超时的SQL

我们可以看到这是一条非常基础的查询SQL，那么我们已经知道SQL非常慢了，具体我们应该怎么去做分析呢？我们mysql提供了`explain`方法。

**explain的简介**  
mysql中可以使用explain这个关键字来获取（查询）sql语句的查询执行计划的。使用explain关键字，可以模拟mysql优化器执行的sql语句，从而知道mysql是如何处理sql语句的。通过explain可以分析查询语句或表结构的性能瓶颈。

**explain的作用**  
①、查看表的读取顺序

②、数据读取操作的操作类型

③、查看哪些索引可以使用

④、查看哪些索引被实际使用

⑤、查看表之间的引用

⑥、查看每张表有多少行被优化器执行

打开`navicat`数据库连接工具，做过测试的朋友，几乎每个人电脑都会安装这个工具。下面我们输入这条SQL语句，再SQL前，加上 `EXPLAIN`， EXPLAIN指的是执行计划。  
![在这里插入图片描述][4a842a4174c042baab6b33dd578709df.png]  
我们的SQL为什么执行的慢的，主要查看的就是结果的type。Type指的是我们对索引的使用情况。下面是关于MYSQL执行计划 TYPE值的关系：![在这里插入图片描述][52023fe0cbcd4f299833235247bd4fc4.png]  
性能：`all < index < range < index_merge < ref_or_null < ref < eq_ref < system/const` 性能在 range 之下基本都可以进行调优

那我们可以看到上面的SQL查询，他返回的type值为all，这个性能是非常差的。通常出现all的情况下，主要是因为该表没有建索引导致的。下面我们打开该表的表设计可以看到果然表中没有建索引。  
![在这里插入图片描述][443c8798da204944a43bcbef90ca8715.png]  
给他加索引，通常索引是加sql where后面的条件。（通常发现是索引问题，可以让开发通知DB去加就行。）![在这里插入图片描述][ba5f45e8ee804e7d847999aaa6b0985d.png]  
下面我们把这个索引值给加上。上方我们可以看到有个索引类型，通常工作中常用的类型有`NORMAL`和`UNIQUE`。选择类型需要根据业务类型也决定，UNIQUE 是唯一值，如果说我们选择了`UNIQUE`，那么之后user\_name就是唯一的，之后插入相同的user\_name，数据库就会报错。

这里我们公司的业务是user\_name是唯一的。所以选择 `UNIQUE` 。后方的索引方式，默认都是选择`BTREE`。

保存之后，我们再来看一下sql的执行计划。我们可以看到直接变成const了。从最差变成了最好。![在这里插入图片描述][84af5029e97b4d8eb6de1acc87d84c12.png]  
现在我们加了索引，再重新做一下压测。我们来看一下压测的数据。性能明显提升上去了，由原先的40个tps到了400多，响应时间也从原来的200ms变成了20ms左右。  
![在这里插入图片描述][25ff4b138d8b42bcbe2bb8f59e796e95.png]  
下面我们再来看一下数据库服务器，cpu的空闲率现在也变成了70%左右了。![在这里插入图片描述][f9d876221dfd4048a6ffdda5d549accc.png]  
我们再来看一下应用服务器，但是现在压力到了应用服务器上面。通常情况下应用服务器如果性能不好我们可以进行扩容，但是如果是数据库服务器性能问题，会比较麻烦，这个涉及到了架构问题。![在这里插入图片描述][0fb9035faedd49a0a2ccee2597898b49.png]  
**结果总结**，  
如果我们的SQL是全表扫描会非常影响服务器的性能，直接导致数据库服务器的cpu飙升。因此可以得出索引的设置，直接影响到了我们的性能，索引的选择相差也是非常大的。

[c099cbf4318242dbb7ab7351e4cbcd99.png]: https://img-blog.csdnimg.cn/c099cbf4318242dbb7ab7351e4cbcd99.png
[https_img-blog.csdnimg.cn_694a21f136954a7fa281e2bde2cf33d9.png]: https://img-blog.csdnimg.cn/8fd9e2e0351f4065b06a71d7583e5670.png
[12217f7a78f14e6b8f6016640e9a7228.png]: https://img-blog.csdnimg.cn/12217f7a78f14e6b8f6016640e9a7228.png
[2a889d0dcf4248d6a7a1f47af8f65471.png]: https://img-blog.csdnimg.cn/2a889d0dcf4248d6a7a1f47af8f65471.png
[https_blog.csdn.net_weixin_42274846_article_details_128032102]: https://blog.csdn.net/weixin_42274846/article/details/128032102
[7997d3090d2a4b30b0e12adcd6652e44.png]: https://img-blog.csdnimg.cn/7997d3090d2a4b30b0e12adcd6652e44.png
[ab4eae044ddb40f6be0891c7c1af109a.png]: https://img-blog.csdnimg.cn/ab4eae044ddb40f6be0891c7c1af109a.png
[4a842a4174c042baab6b33dd578709df.png]: https://img-blog.csdnimg.cn/4a842a4174c042baab6b33dd578709df.png
[52023fe0cbcd4f299833235247bd4fc4.png]: https://img-blog.csdnimg.cn/52023fe0cbcd4f299833235247bd4fc4.png
[443c8798da204944a43bcbef90ca8715.png]: https://img-blog.csdnimg.cn/443c8798da204944a43bcbef90ca8715.png
[ba5f45e8ee804e7d847999aaa6b0985d.png]: https://img-blog.csdnimg.cn/ba5f45e8ee804e7d847999aaa6b0985d.png
[84af5029e97b4d8eb6de1acc87d84c12.png]: https://img-blog.csdnimg.cn/84af5029e97b4d8eb6de1acc87d84c12.png
[25ff4b138d8b42bcbe2bb8f59e796e95.png]: https://img-blog.csdnimg.cn/25ff4b138d8b42bcbe2bb8f59e796e95.png
[f9d876221dfd4048a6ffdda5d549accc.png]: https://img-blog.csdnimg.cn/f9d876221dfd4048a6ffdda5d549accc.png
[0fb9035faedd49a0a2ccee2597898b49.png]: https://img-blog.csdnimg.cn/0fb9035faedd49a0a2ccee2597898b49.png