MySQL实战优化高手06 生产经验：互联网公司的生产环境数据库是如何进行性能测试的？

1、申请了机器之后，你作为Java架构师就要心里有数

上一篇文章我们讲到了在真实的项目中，第一件事情就是申请数据库机器，一般来说我们需要申请8核16G或者16核32G的高配置机器下来，甚至要机器全部搭配SSD固态硬盘，然后让DBA兄弟在申请下来的机器上安装和部署一个MySQL，同时启动MySQL数据库。

当然如何安装和部署MySQL，以及如何启动MySQL，都是非常简单的，大家网络上随便一搜索就会看到大量类似的东西，那不是我们专栏要讲的东西。然后MySQL在生产环境下的各种纷繁复杂的高级参数的调整，暂时我们还不会立马涉及到，那些是属于MySQL DBA需要搞定的事情。

但是我们后续随着专栏的推进，会讲解一部分MySQL生产环境中的高阶参数的调优和配置，有一些是跟我们开发Java应用系统密切相关的东西，我们作为开发人员，也是需要了解MySQL一些高阶参数的调优的，有时候在我们优化系统性能的时候，可能就需要跟DBA一起配合进行调优。

但是简单来说，我们作为一个项目的核心Java工程师甚至Java架构师，必须要选择自己的数据库使用什么配置的机器，心里大致明白这个配置的机器部署的数据库，大致能帮我们抗下每秒多少并发请求。

比如你申请的是8核16G的机器来部署MySQL，那你作为项目的Java架构师，心里大致就该知道你这个数据库后续每秒抗个一两千请求还是可以的，如果你申请的是16核32G的机器，那你心里就知道妥妥可以抗个每秒两三千，甚至三四千的请求，你心里就有数了，这是你要做到的

2、把机器交给专业的DBA，让他部署MySQL

其次你要知道的是，你申请一台机器下来之后，接着这台机器在有一定规模的公司里，一定是交给公司专业的DBA去安装、部署和启动MySQL的，DBA这个时候会按照他过往的经验，用自己的MySQL生产调优参数模板，直接放到MySQL里去，然后用一个参数模板去启动这个MySQL，往往这里很多参数都是调优过的。

而且DBA还可能会对linux机器的一些OS内核参数进行一定的调整，比如说最大文件句柄之类的参数，这些参数往往也都是需要调整的。

接着当DBA搞定这台机器上的数据库之后，就会交给你来使用，你就知道这台机器的地址和用户名密码，然后就的Java系统就可以直接连接上去，就可以执行各种各样的SQL语句去实现业务逻辑了。

3、有了数据库之后，还需要先进行压测

当你手头有一个可以使用的数据库之后，你觉得就可以直接基于他开发Java系统了吗？

并不是这样的！这么做在一个互联网公司里往往会显得比较的业余，因为你首先得先对这个数据库进行一个较为基本的基准压测。

也就是说，你得基于一些工具模拟一个系统每秒发出1000个请求到数据库上去，观察一下他的CPU负载、磁盘IO负载、网络IO负载、内存复杂，然后数据库能否每秒处理掉这1000个请求，还是每秒只能处理500个请求？这个过程，就是压测。

你不光用工具每秒发送1000个请求，还可以模拟每秒发送2000个请求，甚至3000个请求，逐步的测试出来，这个数据库在目前的机器配置之下，他大致的一个负载压力如何，性能表现如何，每秒最多可以抗多少请求。

可能有的人会提出疑问了，他会说：老师，为什么刚开始就要对数据库搞一个基准压测？你完全可以等Java系统都开发完毕了，然后直接让Java系统连接上MySQL数据库，然后直接对Java系统进行压测啊！

如果有人提出这个问题，那就有所不知了，数据库的压测和他上面的Java系统的压测，其实是两回事儿，首先你得知道你的数据库最大能抗多大压力，然后你再去看你的Java系统能抗多大压力。

因为有一种可能是，你的数据库每秒可以抗下2000个请求，但是你的Java系统每秒只能抗下500个请求，这也是有可能的。所以你不能光是针对Java系统去进行压测，在那之前也得先对数据库进行压测，心里得有个数。

4、傻傻分不清楚：QPS和TPS到底有什么区别？

既然要压测了，那么肯定得先明白一点，我们压测数据库，最终是想看看这个数据库在现有的机器配置之下，每秒可以抗下多少个请求呢？这个每秒抗下多少个请求，其实是有专业术语的，分别是QPS和TPS。

就QPS而言，他的英文全称是：Query Per Second。

其实就是英文字面意思已经很明确了，QPS就是说，你的这个数据库每秒可以处理多少个请求，你大致可以理解为，一次请求就是一条SQL语句，也就是说这个数据库每秒可以处理多少个SQL语句。

对于QPS而言，其实你的一些Java系统或者中间件系统在进行压测的时候，也可以使用这个指标，也就是说，你的Java系统每秒可以处理多少个请求。

然后另外一个术语是TPS，他的英文全称是：Transaction Per Second。其实就是每秒可处理的事务量，这个TPS往往是用在数据库中较多一些，其实从字面意思就能看的出来，他就是说数据库每秒会处理多少次事务提交或者回滚。

因为大家应该都对数据库有一个基本的了解，就是他的事务到底是什么？

简单来说，一个事务就会包含多个SQL语句，这些SQL最好要么就是事务提交，大家一起成功了，要么就是最好事务回滚，大家一起失败了，这就是事务。

所以TPS往往指的是一个数据库每秒里有多少个事务执行完毕了，事务提交或者回滚都算是事务执行完毕了，所以TPS衡量的是一个数据库每秒处理完的事务的数量。有一些人往往会把TPS理解为是数据库每秒钟处理请求的数量，其实这是不太严谨的。

5、IO相关的压测性能指标

接着再给大家讲几个压测的时候要关注的IO相关的性能指标，大家也要对他做一个了解：

（1）IOPS：这个指的是机器的随机IO并发处理的能力，比如机器可以达到200 IOPS，意思就是说每秒可以执行200个随机IO读写请求。

这个指标是很关键的，因为之前我们在数据库架构原理中讲解过，你在内存中更新的脏数据库，最后都会由后台IO线程在不确定的时间，刷回到磁盘里去，这就是随机IO的过程。如果说IOPS指标太低了，那么会导致你内存里的脏数据刷回磁盘的效率就会不高。

（2）吞吐量：这个指的是机器的磁盘存储每秒可以读写多少字节的数据量

这个指标也是很关键的，因为大家通过之前的学习都知道，我们平时在执行各种SQL语句的时候，提交事务的时候，其实都是大量的会写redo log之类的日志的，这些日志都会直接写磁盘文件。

所以一台机器他的存储每秒可以读写多少字节的数据量，就决定了他每秒可以把多少redo log之类的日志写入到磁盘里去。一般来说我们写redo log之类的日志，都是对磁盘文件进行顺序写入的，也就是一行接着一行的写，不会说进行随机的读写，那么一般普通磁盘的顺序写入的吞吐量每秒都可以达到200MB左右。

所以通常而言，机器的磁盘吞吐量都是足够承载高并发请求的。

（3）latency：这个指标说的是往磁盘里写入一条数据的延迟。

这个指标同样很重要，因为我们执行SQL语句和提交事务的时候，都需要顺序写redo log磁盘文件，所以此时你写一条日志到磁盘文件里去，到底是延迟1ms，还是延迟100us，这就对你的数据库的SQL语句执行性能是有影响的。

一般来说，当然是你的磁盘读写延迟越低，那么你的数据库性能就越高，你执行每个SQL语句和事务的时候速度就会越快。

6、压测的时候要关注的其他性能指标

除了上面说的QPS、TPS、IOPS、吞吐量、latency这些指标之外，在压测的时候还需要关注机器的其他一些性能指标。

（1）CPU负载：CPU负载是一个很重要的性能指标，因为假设你数据库压测到了每秒处理3000请求了，可能其他的性能指标都还正常，但是此时CPU负载特别高，那么也说明你的数据库不能继续往下压测更高的QPS了，否则CPU是吃不消的。

（2）网络负载：这个主要是要看看你的机器带宽情况下，在压测到一定的QPS和TPS的时候，每秒钟机器的网卡会输入多少MB数据，会输出多少MB数据，因为有可能你的网络带宽最多每秒传输100MB的数据，那么可能你的QPS到1000的时候，网卡就打满了，已经每秒传输100MB的数据了，此时即使其他指标都还算正常，但是你也不能继续压测下去了

（3）内存负载：这个就是看看在压测到一定情况下的时候，你的机器内存耗费了多少，如果说机器内存耗费过高了，说明也不能继续压测下去了

7、后续的压测实战说明

接下来下一篇文章，我就会在我自己的电脑上安装一个MySQL数据库，然后交给大家如何使用方便的压测工具，对数据库进行一定的压测，压测的同时，应该通过哪些便捷的工具，去观察压测过程中的机器表现和各项指标。

8、今日思考题

今天想请每个人思考一下QPS和TPS两个术语，想请大家说说自己在看今天的文章之前，自己对QPS和TPS是怎么理解的，在你们公司里是否有相关的系统和数据库的QPS/TPS的统计？今天看完这篇文章之后，你对QPS和TPS两个术语的理解是否有所变化呢？

另外，我再给大家出另外一个思考题，假设现在你负责一个交易系统，对于这个交易系统，他拆分为了很多服务，一笔交易的完成需要多个服务协作完成，也就是说一次交易请求需要调用多个服务才能完成。
那么你觉得对于每个服务而言，他每秒处理的请求数量是QPS还是TPS呢？对于整个交易系统而言，他每秒钟处理的交易笔数是QPS还是TPS呢？请大家谈谈你的看法。