性能测试如何确定数据库是否是瓶颈

    具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。

   为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？

    相信大部分做数据库运维的朋友，都遇到这种情况。 数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert *** 作， 需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？

dba此时心中有无限的疑惑，到底是什么原因呢? 磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？ 还是数据库内部出问题？昨天不是还好好的吗？

 当数据库出现响应时间不稳定的时候，我们在 *** 作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO. 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么 *** 作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？

如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。

在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。

咱们先来提问题。 buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。

提问. 数据页不在buffer bool 里面该怎么办？

  回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool, 图片中显示

buffer_read_page函数栈的顶层是pread64(),调用了 *** 作系统的读函数。

buf_read_page的代码

 如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的 *** 作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer 中，无法直接使用该数据页，必须等待 *** 作系统完成IO .

再接着上面的回答提问：

当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？   代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。

试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool, 这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。 等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。

通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。

再继续扩展问题： 如果会话线程A 经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。

由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。

再回头来看上面的问题，mysql数据库出现性能下降时，可以看到 *** 作系统有读IO。 原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写 *** 作是不堵塞执行sql的会话线程的。所以，即使看到 *** 作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在 *** 作系统上基本看不到读的IO。  当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。

想要知道如何处理数据并发，自然需要先了解数据并发。

什么是数据并发 *** 作呢？

就是同一时间内，不同的线程同时对一条数据进行读写 *** 作。

在互联网时代，一个系统常常有很多人在使用，因此就可能出现高并发的现象，也就是不同的用户同时对一条数据进行 *** 作，如果没有有效的处理，自然就会出现数据的异常。而最常见的一种数据并发的场景就是电商中的秒杀，成千上万个用户对在极端的时间内，抢购一个商品。针对这种场景，商品的库存就是一个需要控制的数据，而多个用户对在同一时间对库存进行重写，一个不小心就可能出现超卖的情况。

针对这种情况，我们如何有效的处理数据并发呢？

第一种方案、数据库锁

从锁的基本属性来说，可以分为两种：一种是共享锁（S），一种是排它锁（X）。在MySQL的数据库中，是有四种隔离级别的，会在读写的时候，自动的使用这两种锁，防止数据出现混乱。

这四种隔离级别分别是：

读未提交（Read Uncommitted）

读提交（Read Committed）

可重复读（Repeated Read）

串行化（Serializable）

当然，不同的隔离级别，效率也是不同的，对于数据的一致性保证也就有不同的结果。而这些可能出现的又有哪些呢？

脏读（dirty read）

当事务与事务之间没有任何隔离的时候，就可能会出现脏读。例如：商家想看看所有的订单有哪些，这时，用户A提交了一个订单，但事务还没提交，商家却看到了这个订单。而这时就会出现一种问题，当商家去 *** 作这个订单时，可能用户A的订单由于部分问题，导致数据回滚，事务没有提交，这时商家的 *** 作就会失去目标。

不可重复读（unrepeatable read）

一个事务中，两次读 *** 作出来的同一条数据值不同，就是不可重复读。

例如：我们有一个事务A，需要去查询一下商品库存，然后做扣减，这时，事务B *** 作了这个商品，扣减了一部分库存，当事务A再次去查询商品库存的时候，发现这一次的结果和上次不同了，这就是不可重复读。

幻读（phantom problem）

一个事务中，两次读 *** 作出来的结果集不同，就是幻读。

例如：一个事务A，去查询现在已经支付的订单有哪些，得到了一个结果集。这时，事务B新提交了一个订单，当事务A再次去查询时，就会出现，两次得到的结果集不同的情况，也就是幻读了。

那针对这些结果，不同的隔离级别可以干什么呢？

“读未提（Read Uncommitted）”能预防啥？啥都预防不了。

“读提交（Read Committed）”能预防啥？使用“快照读（Snapshot Read）”方式，避免“脏读”，但是可能出现“不可重复读”和“幻读”。

“可重复读（Repeated Red）”能预防啥？使用“快照读（Snapshot Read）”方式，锁住被读取记录，避免出现“脏读”、“不可重复读”，但是可能出现“幻读”。

“串行化（Serializable）”能预防啥？有效避免“脏读”、“不可重复读”、“幻读”，不过运行效率奇差。

好了，锁说完了，但是，我们的数据库锁，并不能有效的解决并发的问题，只是尽可能保证数据的一致性，当并发量特别大时，数据库还是容易扛不住。那解决数据并发的另一个手段就是，尽可能的提高处理的速度。

因为数据的IO要提升难度比较大，那么通过其他的方式，对数据进行处理，减少数据库的IO，就是提高并发能力的有效手段了。

最有效的一种方式就是：缓存

想要减少并发出现的概率，那么读写的效率越高，读写的执行时间越短，自然数据并发的可能性就变小了，并发性能也有提高了。

还是用刚才的秒杀举例，我们为的就是保证库存的数据不出错，卖出一个商品，减一个库存，那么，我们就可以将库存放在内存中进行处理。这样，就能够保证库存有序的及时扣减，并且不出现问题。这样，我们的数据库的写 *** 作也变少了，执行效率也就大大提高了。

当然，常用的分布式缓存方式有：Redis和Memcache，Redis可以持久化到硬盘，而Memcache不行，应该怎么选择，就看具体的使用场景了。

当然，缓存毕竟使用的范围有限，很多的数据我们还是必须持久化到硬盘中，那我们就需要提高数据库的IO能力，这样避免一个线程执行时间太长，造成线程的阻塞。

那么，读写分离就是另一种有效的方式了

当我们的写成为了瓶颈的时候，读写分离就是一种可以选择的方式了。

我们的读库就只需要执行读，写库就只需要执行写，把读的压力从主库中分离出去，让主库的资源只是用来保证写的效率，从而提高写 *** 作的性能。

---