面向业务需求的数据库性能优化方法

冷友方

摘 要：数据库性能优化一直是IT领域的一个大课题。结合工作经验及问题总结，列出传统数据库优化方法中的一些误区，并提出一种全新的优化方法：面向业务需求的数据库性能优化方法。包括以下几个过程：问题的引出，部析优化目的，探讨优化方法，采集实验数据，建立优化模型，建立优化过程；通过这几个过程的循序渐进，层层深入，探索了这种优化方法的来源，建立方法，应用方法等等，给数据库的优化引出一个全新的研究方向。

关键词：数据库 性能优化 信息技术 性能评估

中图分类号：TP392 文献标识码：A 文章编号：1007-3973（2013）007-060-03

1 问题引出

很多IT技术人员一提到数据库调优，首先想到的就是如何调整CPU、内存、IO等问题，以技术细节做为出发点，很多已有的数据库调优文献都是如出一撤，教的是如何调整这些参数，但笔者在多年的数据库调优摸索中逐渐发现，其实调优的出发点不应该是技术参数，而是业务需求，具体来说，就是从数据库所服务的应用程序的业务类型和业务量出发。

打个比方，拿道路堵车方案来做类比：

数据库的优化方案就如同治理堵车方案一样，道路就是数据库，如果道路有2个车道，当只有非常少量的车在上面跑，一点也不堵，那性能肯定能打100分。

但如果同时跑海量的车在这2个车道上面，肯定堵得一塌糊涂，性能只能得0分。

同一条道路，性能评分有天壤之别，为什么呢？关键不在这条道（数据库）上，而在承载的车量（业务量）上面。

所以基于这个想法，笔者认为优化的出发点不应该是数据库，而是先分析业务模型。针对业务模型，再给出具体的数据库优化方案。

1.1 传统的数据库优化工作存在的问题

传统的数据库优化工作中，存在以下几点问题：

（1）数据库优化切入点：SQL/参数/CPU/Memory/IO不合理。

在传统的数据库优化方法中，技术人员脑海中首先闪现的就是sql写得有问题，要么就是参数设置有问题，再或者是硬件配置是否太小，这些都会把调优人员引入技术细节的歧途，也使得旁观者和初学者觉得调优工作是一件极其复杂的工作，从而望而生畏。

（2）没有固定的优化过程或模型。

如果切入点没找准，在进行具体的优化工作时，到底是SQL需要改写？亦或是参数需要调整？再或者是CPU需要提速？等等这一切，说明切入点越多，优化步骤和优化方向越迷茫，往往不能做到软件和硬件的协调统一。

（3）优化结果不可评估和量化。

传统的优化工作有时可以解决当前问题。但解决之后，给出的方案效果如何，如何评估？解决了当前问题，会不会引入其它问题？

1.2 本文的不同点

本文在做优化的过程中，有以下几个不同点：

（1）彻底抛开传统优化问题的切入点，以业务做为切入点。

正所谓知已知彼，百战不怠。在寻求优化切入点的问题上，也需要做到知已知彼。所谓知已，就是收集数据库自身的静态信息，其中包括数据库的辑逻结构和物理结构、数据量等等。所谓知彼，就是收集来自数据库之外的动态信息，在不同的时段，都有什么业务，业务量有多大，这些业务都发出了哪些数据库请求，以及数据库的响应时间等等。

（2）给出了一个可重用的优化过程模型。

传统的优化工作基本没有可重复使用的过程可以参考，使得优化工作只能是一些经验非常丰富的人员才能完成的工作。本文在基于业务做为出发点的前提下，给出了一个可以重复使用的优化过程模型，从而使即使初级的IT人员也可以遵循这个过程进行优化工作，提高了工作效率。

（3）优化结果可以量化。

本文提出了“响应时间-资源-业务”三要素的评价模型。响应时间是目标，资源是限制条件，业务是事实，基于这个模型来量化系统得分，从而评价优化结果。

2 剖析优化目的

2.1 优化目标：提高响应速度

随着信息化的迅速发展，信息技术已经逐渐发展成为一种服务。近年来，IT服务的理念已经深入人心，云服务也开始遍及。各种理论研究，如IT服务管理（IT Service Management），ITIL（IT Infrastructure Library），QoS（Quality of Service服务质量），Cloud Computing（云计算）等等，都是围绕“IT即服务”的理念展开的，它们都详尽阐述了如何建立服务模型，提高服务质量。毫不例外，数据库作为信息的存储中心，向应用程序提供数据的存取服务，当然也是一种服务。

当数据库作为一种服务时，应用程序无需知道数据存放的磁盘位置，数据的组织结构，以及发出数据请求（如SQL）时数据库的具体算法。对应用程序来说，它只关心为其提供服务的数据库的存取速度，即响应时间。所以在数据库优化中，最核心的目标就是提高响应速度，即减少响应时间。

2.2 优化思路：以资源换时间

确定了提高响应速度的优化目标之后，就需要提出提高响应速度的方法。

在谈优化思路之前，先说一下经济学中的资源的稀缺性，在经济学领域中，研究的核心概念是“资源的稀缺性”：即整个社会的资源是有限的，资源的数量不足以满足人们的所有需要；而经济学就是研究如何实现稀缺资源的有效利用和合理配置，以使人类的需要得到最大限度满足的科学。

资源的有限性是经济学的核心内容，经济学研究的是整个人类社会的资源，而IT领域属于整个人类社会的一部分，同样也存在资源的有限性。在IT领域中，计算需要的资源包括CPU资源，内存资源，I/O资源，以及网络资源等等。由于这些资源的有限性，在提高响应速度时，有两种思路可以遵循：

（1）优化算法，减少使用的资源。

例如优化SQL，改变其执行计划，使其利用更少的计算过程完成同样的任务，从而提高响应时间。

（2）分配更多的资源。

从服务器所拥有的资源来说，分配更多资源分为以下几方面：

1）如果数据库的命中率很低，说明内存分配得比较少，很多数据都需要从硬盘上读取，此时可以为数据库分配更多的内存，使其直接从内存读取数据。这是一种以内存换时间的方法。

2）数据库中的索引技术本身就是一种数据冗余，但它能提高对特定列的检索速度，是一种以磁盘空间换时间的方法。

3）并行运算，就是利用更多地CPU协同完成一个任务，是以CPU换时间的方法。

不管是以CPU、内存、以及磁盘空间哪种方式来提高性能的方法，都是以资源来换取响应时间，因此，数据库的核心优化思路即是“以资源换时间”。

3 优化模型的建立

3.1 响应时间、资源、业务量三者之间的博弈关系

响应时间，资源以及业务量三者之间是存在一定的博弈关系的，举几个现实中的实例便可以定性地看出三者的关系，现在电子商务已经逐渐普及并且渗透到我们的日常生活中，所以拿电子商务来举例会更容易理解：

关系一：在资源固定的情况下，持续增加业务量，响应时间势必会增加。

Example 1：某个电商网站A商城，服务器资源是固定的，平时日访问量为100万用户，转化率为30%；如果在十一节假日采取了大量的促销优惠活动，比如打5折，并且此前做了充分的广告来宣传此活动，那么到了十一这一天，访问量肯定会巨增，如果访问量达到500万用户，并且转化率提高到80%，可以预见其响应速度势必会降低，系统甚至会瘫痪。

关系二：在特定的业务量下，为了减少响应时间，必须增加更多的资源。

Example 2：拿铁路售票系统12306为例，在春运等高峰期，经常登陆会堵塞，而铁道部为了解决这个问题，在二期的改造中，耗资几个亿来增加硬件资源的投入。

关系三：在保证响应时间不变的前提下，如果增加更多的资源，则系统能支持的业务量会增加。

Example 3：一个设计优化的系统在设计初期，不仅要考虑到当前支撑的业务量，还要考虑到系统的可扩展性，用来满足将来能支撑更多的业务量。

在现实世界中，人们对信息服务的质量会越来越高，也就是对响应速度的要求只增不减。系统的业务量也会随着信息技术的普及而客观增长，而资源却是有限的，这是需要在三者之间做出权衡抉择，给出一个合理的抉择结果，这个抉择的结果正是优化方案。

3.2 模型建立

上一小节讨论了资源、业务量、响应时间三者之间的定性关系，如果需要具体的优化方案，就需要建一个的可量化的模型，也就是三者之间的定量关系。本小节中通过实验的方式来获取数据，用于验证上一小节提出的三种关系。

需要从两个方向来采集数据：

（1）一方面，资源配置不变的前提下，获取系统当前的实际业务量q，然后通过压力测试软件，如loadrunner，录制业务脚本，通过加大系统压力来摸拟业务量增加的情况，实时采集系统响应时间t。

（2）另一方面，在特定业务量情况下，通过调整资源大小s，实时采集系统响应时间t。

通过以上两个方向的数据采集，就可以得出，在各种不同的资源以及不同的业务量情况下，系统的响应时间。

由于资源的多样性以及资源限制，如果使用多种资源的变化组合，数据将程现出多维状况，为了简化我们提出的“资源-业务量-响应时间”三维模型，在做实验的过程中，仅仅使用虚拟机来调整单一资源，即CPU的个数来验证我们的模型，实验结果如表1所示。

表1 实验数据采集

图1 响应时间随着业务量和资源量的变化趋势

说明：通过表1的数据，绘出图1的图表。图表1中，横轴是业务量（单位：万），纵轴是响应时间（单位：秒），蓝线为2cpu，红线为1cpu。

从图表1中可以看出：

（1）2CPU的响应时间比1CPU响应时间要小一倍左右，验证了资源对响应时间的影响关系。

（2）在相同的CPU数量上，当业务量增长时，响应时间程现出增长的趋势，验证了业务量对响应时间的影响。

（3）横向比较响应时间保持不变的情况（取40s），可以看出，如果增加资源的数量，从1CPU到2CPU，则支持的业务量也从4万增加到10万。

通过实验我们采集到了三者之间的数据，运用线性回归算法，就可以给出响应时间t和资源s以及业务量q之间的函数，称之为性能函数：

t=F（s，q）

得出此性能函数后，三者之间的定量关系就出来了，就能知道每增加一定量的资源，系统的响应时间会减少多少，或每增加一定量的业务量，系统的响应时间又会增加多少。系统架构师就可以依据此函数来准确地制定优化方案。

4 模型应用

性能函数t=F（s，q）有以下几种非常实用的应用场景：

4.1 计算要达到理想响应时间需要投入的资源

通过调研获取用户的目标响应时间T，采集到当前的业务量Q，通过性能函数T=F（s，Q）的运算就可以得出需要投入的系统资源S。

4.2 预测当业务增长后，资源的投入情况

确定了用户的目标响应时间T，预测为了满足将来业务量持续增长时，需要新投入的资源情况，使系统在设计初期充分考虑其可扩展性。

4.3 为系统评分

通过系统当前实际的资源S和业务量Q，算出理论响应时间T，并采集系统的实际响应时间t1，调查产生用户对系统的零容忍响应时间t0，即：如果响应时间大于t0，则认为系统得分为0，然后为系统打分。评分公式如下：

（t0-t1/t0-T）*100

例：通过函数运算，系统理论上响应时间为1s，用户对系统的零容忍响应时间为3s， 而系统实际响应时间为1.5s，那么此系统打分为：

（3-1.5）/（3-1）*100=75

说明：当得分为负数时，表明此时响应时间已经超过用户的零容忍响应时间。当得分大于100时，表明此时响应时间表现很好，比理论响应时间还小。

5 优化过程

作为专业的数据库工作者，笔者在实际工作中，经常遇到有IT人员谈到数据库性能问题时，总是望洋兴叹，认为数据库优化神秘而不可触，有时甚至寄希望于有一种通用的方法，或者打开一个优化开关，或调整一两个参数就可以快速解决当前问题。我们应该认识到，不同的系统对响应时间的要求不一样，资源也不一样，业务类型和业务量更是千差万别，因此，优化工作中没有银弹（Silver Bullet），也没有通用的开关，必须以系统工程的理念进行优化工作。

既然优化工作中没有银弹，在明确了以响应速度作为优化目标，以资源换时间作为优化思路，以及“速度-资源-业务量”三者之间的量化关系后，就需要建立一套切实可用的优化过程，来得出优化方案。

具体的优化过程如下：

（1）获取系统当前的资源情况以及业务量数据。

（2）建模推导出性能函数t=F（s，q）。

（3）确定优化方案。

得出性能函数t=F（s，q）后，求解优化方案就变成一个数学问题，确定了其中两个参数，就可以求解出第三个参数，三个参数的不同组合即为不同的优化方案，我们可以权衡抉择来选出折中的方案。

（4）实施方案。

（5）评估优化结果。

最后，通过4.3小节给出的评分标准来给优化方案打分，如果不满意则继续选择备用方案并评分，直到最终找出最合适的优化方案，那么优化过程也就结束了。

6 结束语

本文结合笔者长期的数据库工作经验，总结了响应时间、资源和业务量三者之间的博弈关系，并在此关系的基础上，通过实验采集大量的数据，并结合线性回归算法得出三者之间的关系函数，以此模型来指导数据库的优化工作。并给出了此模型的三种应用：解决当前问题、预测将来的性能扩展问题、为系统评分。在最后，说明了数据库性能优化没有银弹，并给出了性能优化的过程模型。

但本方法由于受到一些因素的限制，仍有需要改进的地方：

（1）资源大小的调整需要大量的硬件支撑，由于实验环境的限制，目前只能调整比较有限的资源。

（2）在评估优化结果时，理想响应时间和零容忍响应时间因人而异。

这些不足之处需要进一步地研究。

参考文献：

[1] 蒋洪迅，杨永艳，苏俊.IT系统管理中多应用综合性能优化的建模研究[J].计算机工程与应用，2007（27）.