性能测试(4) - 数据库

其实性能测试我前面已经提到了很多，为什么还要把数据库单拿出来说呢？

因为数据库服务器本身与其他的一些普通的APP服务器是很不一样的。 之前我接触过很多项目，都是因为数据库的原因导致了很多性能问题，比如死锁，索引等等

关于内存

我们在进行服务器的内存的测试的时候，如果是普通的APP server，当我们对内存进行监控时，通常都是有一个metrics, 比如某个APP的service的内存使用量不能超过总量的百分之多少，对于整个sever来说，通常也会有比较多的内存剩余。

而当我们去查看一个数据库server的时候，会发现可用的内存量通常只有10M或者5M(取决于你的配置)...... 而当你把你的数据库的内存增加一倍，可用的内存通常还是只有10M左右，这是什么原因呢？

其实这于数据库本身的工作原理有关系，数据库中io操作的基本单位为页，当数据库执行一条语句，比如一条查询语句，他会先从物理磁盘中把相应的页加载到内存，然后在进行操作。

因为数据库本身就不停的读写的过程，所以数据库中内存当中会缓存各种各样的数据，为了更快的读写速度，数据库会有算法去维护这些内存中的数据，以保证尽可能的使得数据都是从内存中获得，而不是从物理内存中得到（内存的访问速度是纳秒级，硬盘是微秒级）。所以一般来说，数据库会基本用光所有的内存。

这就是为什么数据库会吃内存了，这与他的工作原理有关系，只要能保证系统能正常运行就可以了，其他的内存都可以用来缓存数据。

关于死锁

死锁通常是指争抢资源不当，让双方因为对方掌握了自己的资源而无限期的等下去。如下图所示：

发生死锁的原因很多，大部分是由于事务之间对资源访问顺序的交替，或者并发修改统一记录导致的，数据库对待死锁有着不同的策略，对于SQL server来说，它会随机杀掉其中的一个，至少保证另外一个事务的正常运行；而对于Oracle来说，它会对两个事务进行一个评估，会杀掉它认为不那么重要的一个。

所以我们在数据层面，需要去监控死锁的发生情况，一般来说，死锁是不可避免的，但是一旦死锁发生频率很多，必定会影响到业务。

我们可以用很多工具去监控死锁，比如SQL Profile。对于死锁的修正也是对于高并发的事务，尽量减少长度；把锁的优先级调整低一些（用低隔离级别）；按同一顺序访问对象，尽量避免事务中的用户交互。

关于磁盘

因为对于数据库来说，最重要的就是读写的操作，磁盘对于数据库来说是非常重要的。

现在好多数据库都是直接放在云盘上的，云盘上的磁盘有这自己的结构，但是很多年前，如果是自己的服务器，我们还要考虑到磁盘阵列，来保证磁盘的效率和安全性。

对于磁盘来说，我们通常会从读写方面来衡量，有几个比较通过的指标可以用来衡量数据库磁盘的性能，比如Average Disk queue lenth，数据生命周期等等。

另外值得一提的是数据库的碎片整理。当数据库读写一段时间之后，由于频繁的插入数据，会导致数据并不是按照顺序排列在磁盘上面，这样当我们在查相关的数据的时候，磁盘往往要去不同的区域查找数据，导致性能降低，这个时候我们很有必要去运行磁盘的碎片整理的一些job，来保证我们的数据库性能。

但是这个job本身就很占磁盘的i/O,所以尽量选择系统不忙的时候进行。

关于索引

我相信索引是大家很熟悉的一个话题了，当数据量很小时，不建索引，进行全表扫描的的性能尚可接受。但是数据量大时，必须借助索引。所以索引的适当与否，是性能还坏的关键。

比如执行一条语句

SELECT UserName, UserID  FROM US.UserDetail WHERE UserName = “李四”

这条语句这样执行过程与创建的索引有关系，如果没有索引就需要进行全表扫描，这样加载到内存当中的页在数据量很大的情况下就相当多了。如果建立了适当的索引，可能只需要加载几页内存就可以了。

当我们用一些工具比如sql profile跟踪到一些长的查询的时候，我们就需要去看看索引是否建立恰当。这在数据库的优化中也是很重要的一个方面。当然，索引虽然对读的性能有帮助，但是对写的性能却有影响。

我们也需要再适当的时候reindex索引，原因就是如果索引在物理存储上不连续，也会导致性能的下降，这与磁盘的碎片整理是一个道理。

一般来说，如果系统设计合理，最终的瓶颈都会出现在数据库上，而我们在做性能测试时，也需要了解数据库的特殊之处，去更好的做性能测试