性能优化漫谈之五：性能优化工作的分类-CSDN博客

本文介绍了五种性能优化工作的分类：上线优化、响应速度逐步变慢的系统优化、运行过程中突然变慢的系统优化、基于降低资源消耗的系统优化以及预防性的日常性能优化，并探讨了各类别的特点。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

虽然大家都说性能优化，但事实上性能优化工作是具有不同分类。我们可以基本上把性能优化分为以下几类工作：
（1）、上线优化或者从未达到过性能期望的系统优化工作。
在缺乏充分性能测试的业务系统上线，相当一部分会出现性能问题，不会出现性能问题的系统往往建立在强大的硬件基础之上。这类缺乏性能设计考虑的业务系统基本具有部分或者全部特征：

开发人员假设资源是无限的，可以任意使用，忘记了任何系统都是在一个资源受限系统中运行业务。
开发人员认为只有我一个人在做事，忘记了同时会有很多人在使用，缺乏并发性方面的考虑。
开发人员认为程序在任何时候其处理效率是一样，不应该出现大的波动，不应该出现异常。
远远超过业务实际的各种任务调度频率。
消耗资源无限的SQL语句。
无法充分利用资源，缺乏并行处理或者异步处理能力以充分利用资源。
长长的同步处理链条，性能表现极其脆弱。

（2）、具有相对明显或者不明显感觉的响应速度逐步变慢的系统优化。
在业务正常运行了一段时间或者很长时间之后感觉到业务系统在渐渐的变慢，直到性能表现不可忍受。事实上，不仅仅Oracle数据库，任何IT设备，任何提供服务的物品以及生命体（包括人、动物和植物）都会体现出这个特征，慢慢的我们的性能变差了。这个时候我们需要做保养、做修理或者做优化。一般来说，这类系统存在着一下部分或者全部的特征：

随着时间的推移，数据量在渐渐变大，而我们的业务系统具有和数据量比较强的线性关系设计。
随着时间的推移，业务在发展，公司在变大，而我们的业务系统具有业务和资源较强的线性关系。
随着时间的推移，访问量在变多，而我们的业务系统在并发性上的考虑设计不够。
随着时间的推移，数据不断被分享使用，不同业务之间出现并发性上和资源上的碰撞。

        当然可能还存在其他的时间堆积，但是主要是以上变化度量。既然业务系统性能是一个逐渐变化的过程，我们只要记录相关指标的长时间关系，自然就可以知道为什么性能会变差，甚至可以简单获得哪些因子的线性关系比较重。我们只要简单的打破这个线性关系或者降低线性斜率就可以优化性能，使业务系统恢复正常运行。
（3）、运行过程中突然变慢的系统优化。
       除了Oracle的bug，在这个Oracle世界中没有无缘无故的性能问题。即使是Oracle bug，也还是因为变化引起了bug被触发。所以优化这类系统相对比较简单，只要简单检测突然变化。即使你不知道为什么，只要把变化恢复原状，一般业务系统也就恢复了。当然对于这类业务系统性能故障，用户的紧迫度也往往比较高。
（4）、基于降低资源消耗的系统优化。
       事实上在实际的业务系统性能优化中，有相当一部分并未观察明显的吞吐量或者响应时间异常，而仅仅是资源消耗达到了非预期值。这类优化时间充裕，优化也比较简单，只要简单分析特定资源的影响因子从大到小排序，逐步优化或者仅仅优化影响大的影响因子即可。
（5）、预防性的日常性能优化。
       基于降低资源的消耗的系统优化应该是预防性的日常性能优化的一个变种。预防性的日常性能优化依赖于日常监测的性能因子，当这些性能因子达到预先设定的警戒值之后就进行优化，使其回到正常范围或者减缓其增加速度。保证一个系统始终保持高性能的运行，预防性的日常性能优化是其中的关键因子，甚至比一个业务系统优良的性能设计还要重要。作为一个性能优化工作者或者一个运维DBA来说，业务系统的优良性能设计不是他可以控制的，但是尽可能延缓业务系统性能问题的降临完全是他可以完成的。
   在良好的预防性的日常性能优化支持下的业务系统运行性能具备以下图形表现的特征，预防性优化的作用主要在于延缓业务系统的硬件扩容，延迟资金投入。其次，预防性优化可以使用户对于未来性能预期具有一定的明确性，从而可以合理安排扩容采购窗口，避免业务系统出现性能问题，提高服务质量。而缺乏预防性优化往往意味着一段时间糟糕的业务系统性能表现以及硬件扩容的紧急采购。