|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 > 结果评估与测试报告 > 数据库服务器性能问题及原因分析 >
|
|
考试要求：掌握
相关知识点：7个
|
|
|
|
|
响应时间（Response Time, RT）是系统完成事务执行准备后所采集的时间戳和系统完成待执行事务后所采集的时间戳之间的时间间隔，是衡量特定类型应用事务性能的重要指标，标志了用户执行一项操作大致需要多长时间。响应时间过长意味着用户完成执行一项命令需要等待相当长的时间。实践表明，通常情况下用户能够接受的响应时间最大为200 ms。不仅如此，响应时间过长也是造成系统锁冲突严重的重要原因之一。
|
|
|
|
造成响应时间过长的原因非常复杂，通常可以从以下几个方面考虑。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
数据库服务器负载过重不可避免地会造成响应时间过长。这标志着当前服务器系统的硬件条件不能满足实际用户对性能的需要。服务器负载过重主要表现在CPU使用率高、内存占用率大、I/O与页面交换频繁发生等方面。由于服务器系统本身一般都提供性能监控程序，定位服务器性能问题相对比较容易。解决这类问题的方法一般是升级服务器硬件，提高数据库服务器本身的处理能力。但是，通过升级服务器硬件获得的性能提升是很有限的，并且对于某些诸如算法复杂度过高等问题根本无法解决。
|
|
|
|
|
|
糟糕的数据库设计是导致单一事务响应时间过长的最重要原因。通常，数据库设计在系统开发初期进行，此时，数据库设计人员往往对数据的实际规模和特性没有足够的了解。在数据库设计方面，对响应时间影响较大的因素有数据库表的规模、索引的使用、数据的分布、查询优化等。其中索引的使用极大影响事务执行的响应时间。实际上，很多情况下应用程序在访问大规模数据库表时的确没有使用索引。造成这种情况的原因通常是开发人员的疏忽，也有用户的需求变化过多，某些数据库字段不适合建立索引的情况。在这里需要特别指出的是，对组合索引进行查询时，查询条件中字段的顺序与数据库设计的索引字段顺序要一致。如果顺序颠倒，组合索引根本不能被数据库使用。例如，表A（field1, field2, field3），有组合索引index（field1, field2），诸如
|
|
|
|
SELECT * FROM A WHERE（（field2=condition2）AND（field1=condition1））和SELECT * FROM A WHERE（field2=condition2）的查询无法使用index索引。此外，并非增加索引就一定能够提高单一事务执行的响应时间。过多的索引使用将极大地增加插入操作（INSERT）的花费，从而使响应时间变长。
|
|
|
|
数据库表规模过大，是指单一数据库表的记录数在百万行以上，对这类表直接进行检索而不采取必要的优化手段，必然造成单一查询响应时间过长。如果数据库表的规模一再增大，使用索引也不能很有效地解决响应时间过长的问题。对此类问题，可能的解决办法是对数据进行分布，使查询能够并行执行或缩小查询的范围。目前，主流关系数据库管理系统都提供表分区（分段）存储，以使得软件开发人员比较容易地实现数据分布。
|
|
|
|
查询优化对响应时间的影响也不容忽视，尽管优化活动由数据库管理系统完成。实际上一条结构化查询语句（SQL）的写法有很多种，不同的写法可能有不同的响应时间，这一差别可能非常大。如果开发人员在软件编写过程中恰好使用了执行效率低的SQL语句，其响应时间自然就会变长。目前，某些独立软件开发商已经注意到这种情况，并开发了相应的软件帮助应用软件开发人员找到执行最快的SQL语句的写法。但是，由于数据库本身是动态变化的，执行最快的SQL语句也可能变化，所以这种方法也是有局限性的。
|
|
|
|
|
|
事务粒度过大指单一数据库事务执行过程中，需要以某种并发控制机制访问多个数据库资源。通常采用的并发控制机制是互斥锁或者共享锁。这种大粒度事务的执行由于要访问多个数据库资源（如数据库表），本身就需要消耗相当长的时间。此外，由于通常事务在执行的时候会对数据库资源进行加锁，这类事务也对其他访问该资源的用户造成影响。由于这类事务通常使用的锁数量都在两个以上，如果不合理地进行控制，极容易造成死锁。因此，在应用软件设计过程中，应该尽量消除大粒度事务。
|
|
|
|
|
|
批任务是指一次操作将对数据库中大量数据进行互斥访问的数据库事务。这种类型的事务通常将更新同一个数据库表中的数千项乃至更多的数据。由于这类任务把所有操作放置在同一个数据库事务中，所访问的资源在其执行过程中始终被锁定，必然会对其他普通事务造成访问影响。此外，由于这类任务本身将对数据库服务器造成巨大的负担，使得服务器负载加重，从而影响独立事务的响应时间。通常情况下，批任务推荐在系统具有较长空闲时完成（如晚上），这样可以保证不对独立事务造成影响。如果由于业务的要求，批任务必须与独立事务混合运行，则必须对其加以改造，以减轻对其他事务的影响。
|
|
|
