正在阅读：SQL2000数据库压力测试实例详解SQL2000数据库压力测试实例详解

　　整个测试过程分为大容量数据测试和大记录量数据测试：

　　大容量数据测试：

　　在大容量的数据测试中，我们通过插入图片来使数据库的容量膨胀，所以在以下的所有数据库操作中，例如插入数据，都是指的插入带图片的数据。测试中选择了一张41,958字节的图片，并且大容量测试是在插入100,000条记录以后的测试，因此我们可以大致估计当时的数据表的容量为 (41958 * 100000) / (1024 * 1024) = 4001.43MB。
 
　　首先通过测试程序按顺序进行如下测试，在空表中“插入2000条纪录->选择1000条记录->更新1000条记录->删除1000条记录”，并记录下各操作所需要的时间。测试结果如下表所示：

 
　　（表二）

 
　　上面的测试是在空数据表中进行数据库各种基本操作的测试，并且记录了所需要的时间。然后我们插入100，000条带有图片的纪录，使数据表的数据量膨胀到4001.43MB，接下来的工作就是测试大容量环境下的各种数据库操作情况。
 
　　同样按照以上的的步骤进行测试：“插入2000条纪录->选择1000条记录->更新1000条记录->删除1000条记录”，并记录下各操作的时间，如下：

 
　　（表三）

　　通过对比，我们发现：

　　在大记录量（百万条记录得数据量下），对SQL2K的影响并不算大，其性能影响也比较小。在需要大量时间的SQL操作中，SQL2K在大容量数据环境下的性能基本能保持，不会有太多的性能下降。

　　那让我们通过计算再来看一下了，下面是在大容量数据环境下，同样操作增加的时间与初始数据库环境下所需时间的百分比：

　　（表四）

　　从表中中可以看出，Update和Delete操作的时候，好像在大容量环境下的性能损失严重。但是考虑到，因为存取的数据库服务器与客户端位于不同的机器上，虽然通过100M的内部网连接，但是由于网络的问题，导致了存取中网络的延时。当操作所需要的时间比较大的时候，这一点延时对时间比例影响不大，而一旦操作所需要的时间比较短的时候，这个延时就显得尤为突出了。

　　对于Delete操作中的45.55%的性能损失，还有一个原因是，当删除纪录的时候，数据库会重建索引。当数据量太大的原因下，导致了重建索引耗费了较多的时间。