1.1　优化的基本概念

数据库性能优化通过优化应用程序、修改系统参数、改变系统配置来改善系统性能，从而使得数据库的吞吐量得到最大限度的增加，相应的响应时间达到最小化。数据库性能优化的基本原则是：通过尽可能少的磁盘访问次数获得需要的数据。

1.1.1　为什么优化

优化的目的是避免因数据库性能下降导致的业务系统响应时间变长甚至停滞，从而影响业务工作的正常开展。随着大数据时代的到来，数据库应用越来越广泛，达梦数据库在国民经济建设中担负着越来越重要的任务。为了适应日益增长的业务系统需要，达梦数据库不断应用新技术，其自动化管理程度越来越高，已经实现了自动存储管理、自动共享内存管理等功能，并推出了结构化查询语言（Structured Query Language，SQL）调整顾问，为数据库的正常运行打下了良好基础。但是，由于不同业务的特殊性，达梦数据库还不能完全自适应各类业务特点，系统在运行到一定程度后，数据量增大、用户数增多等因素，可能会导致系统性能下降，从而影响业务工作。因此，在适当的时候仍然需要对数据库进行调整和优化。

1.1.2　谁来优化

一个业务系统的生命周期，大体经过设计、开发和应用3个阶段。在设计阶段，设计人员必须清楚业务应用系统的应用场景、部署方式、数据流程；在开发阶段，开发人员必须根据设计方案选择合适的实现策略，并通过合适的数据结构、交互方式、查询语句实现相关功能；在应用阶段，运维管理人员必须根据设计方案的部署方式、应用模式和系统的实现方式，选择合适的硬件环境和软件环境，搭建业务系统。可以看出，业务系统运行的好坏，并不仅仅是数据库管理员的职责，还涉及业务系统相关的所有人，包括系统体系结构设计者、设计人员、开发人员和数据库管理员。从软件可靠性和维修性角度来看，越早发现系统的漏洞，维护和维修的成本越低，因此，系统设计人员和开发人员也一定要熟悉达梦数据库的运行机制，从而使得开发的业务系统达到最佳性能。在运行维护阶段，如果出现问题，通常首先由数据库管理员（Database Administrator，DBA）尝试解决，但如果是设计的缺陷，往往还需要对业务系统进行升级完善。

1.1.3　优化什么

哪个数据库管理系统都会出现数据库运行效率问题，要使数据库的性能达到最优化，主要从操作系统、硬件性能、数据库结构、数据库资源配置、实例性能、SQL语句执行等方面进行优化，这些方面是相互依赖的。

1. 调整与优化数据库设计

要在良好的数据库应用方案中实现最优的性能，最关键的是要有一个良好的数据库设计方案。调整与优化数据库设计应在开发信息系统之前完成。虽然DM8系统本身已经提供了若干种调节系统性能的技术，但是，如果数据库设计本身就有问题，特别是在结构设计方面存在问题，那么再怎么对数据库进行调整和优化都无法达到很好的效果。因此，提高数据库应用系统的性能应从数据库设计开始。

数据库设计分为逻辑设计和物理设计。逻辑设计包括使用数据库组件为业务需求和数据建模，而无须考虑如何或在哪里存储这些数据。物理设计包括将逻辑设计映射到物理媒体上、利用可用的硬件功能和软件功能尽可能快地对数据进行物理访问和维护，包括索引技术。逻辑设计主要作用是消除冗余数据，提高数据的吞吐速度，保证数据的完整性，但对于多表之间的关联查询（尤其是大数据表），其性能将会受到影响。因此，在进行物理设计时需要折中考虑，根据业务规则和关联表的数据量大小、数据项访问频度，对关联查询频繁的数据表适当增加数据冗余设计。

2. 优化应用程序

据统计，对网络、硬件、操作系统、数据库参数进行优化而获得的性能提升，全部加起来只占数据库系统性能提升的40%左右，其余60%左右的系统性能提升来自对应用程序的优化。对应用程序进行优化通常可从源代码和SQL语句两个方面进行。由于SQL是目前使用最广泛的数据库语言，SQL语句消耗了70%～90%的数据库资源，应用程序对数据库的操作最终表现为SQL语句对数据库的操作，因此SQL语句的执行效率决定了数据库的性能。通过对劣质SQL语句及访问数据库方法的调整，可以显著地改善一个系统的性能，这对提高数据库内存的命中率、减少输入/输出（Input/Output，I/O）访问、减少对网络带宽的占用等具有非常重要的意义。

3. 调整数据库内存分配

每个数据库实例都是由一组数据库后台线程和一组共享内存区域组成的。用户进程对这个内存区域发送事务，并将该内存区域作为调整缓存读取命中的数据，以实现加速数据读取的目标。共享内存的使用效率会大大影响数据库系统的性能。内存分配是在信息系统运行过程中优化配置的，应在检查数据库文件的物理调整和磁盘I/O之前进行调整。

4. 调整与优化磁盘I/O

数据库的数据最终要存储在物理磁盘上。磁盘I/O操作是影响数据库性能最重要的方面，它是系统消耗最大的数据库操作。为了避免与I/O相关的性能瓶颈，监控磁盘I/O并对其进行调整非常重要。影响磁盘I/O性能的主要原因有磁盘竞争、I/O次数过多和数据页空间的分配管理不合理。

5. 配置和调整操作系统性能

数据库服务器的整体性能很大程度上依赖操作系统的性能，如果操作系统不能提供优越的性能，那么无论如何调整数据库也不能发挥其应有的性能。

实施操作系统调整的主要目的是减少内存交换和内存分页，使共享内存池可留驻内存。如果为数据库分配更多的内存需要以增加系统的换页和交换为代价，那么这种方法不仅不会产生理想的效果，反而还会影响数据库的性能。

（1）为数据库规划操作系统资源。

为数据库调整操作系统的目的是为实例提供足够的资源。将计算机可用资源分配给数据库服务器的原则是：尽可能使数据库服务器使用资源最大化，特别在C/S（Client/Server，客户/服务器）模式中尽可能利用服务器上的所有资源来运行数据库。操作系统应提供足够的内存以保证操作系统本身和数据库均能实现其正常功能。

（2）调整计算机系统中的内存配置。

多数操作系统会使用虚拟内存来扩大内存，它实际上属于磁盘空间。当实际的内存空间不能满足应用软件的要求时，操作系统就将这部分的磁盘空间与内存中的信息进行页面替换，这将引起大量的磁盘I/O操作，使整个服务器的性能下降。调整操作系统的主要目的就是减少内存交换、减少分页，使共享内存池留驻内存。

数据库系统性能调整是一个系统工程，涉及很多方面，在实际应用中，应根据具体情况采用适当的优化策略。本书侧重业务系统上线之后的调整优化，重点围绕DM8实例、I/O和SQL语句3个方面的优化展开讨论。

1.1.4　何时优化

从软件可靠性和维修性的角度来看，越早发现系统的漏洞，维护和维修的成本越低，因此，优化应该贯穿整个业务系统的始终，从需求分析阶段、系统设计阶段、系统开发阶段、系统测试阶段到系统上线阶段。

但因为系统未上线之前，往往很难预见所有的困难或问题，所以在系统上线之后，随着业务不断开展、数据不断增长、用户不断增加，系统响应逐渐变慢，性能优化的问题逐渐出现。而此时进行系统优化往往会涉及系统、网络、存储、数据库和应用程序等众多因素，排除性能的问题难度加大。对于数据库管理员来说，在进行系统优化时，一定要充分考虑其他因素的影响，而不是一头扎进数据库里，花费了大量时间，结果发现问题并不在数据库本身，这种现象屡见不鲜。下面具体介绍一下不同时机DM8应用系统的特点及其优化。

1. 上线优化

一般而言，业务系统上线之前必须进行性能测试，如果未进行充分的性能测试就上线，就有很大可能会出现性能问题，没有出现性能问题的系统往往是因为硬件基础足够强大。之所以会出现性能问题，大部分情况是因开发人员在开发阶段考虑不周导致的，一般具有以下特点。

• 开发人员认为业务系统是在理想的环境下工作的，资源无限，可以随意使用。但实际上，任何系统都是在一个资源受限的系统中运行业务的。

• 开发人员认为只有自己一个人在工作，而没有考虑到有很多人在同时使用系统，缺乏并发性方面的考虑。

• 开发人员认为系统在任何时候的处理效率都是相同的，但实际上，由于各种情况的出现会导致性能上下波动，甚至出现异常。

• 各种任务调度频率远远超过业务实际需要。

• SQL语句消耗了无限资源。

• 业务系统无法充分利用资源，缺乏并行处理或异步处理能力。

• 缺乏有效的索引设计，业务系统并发能力低下。

• 具有很长的同步处理链条，性能表现极其脆弱。

• 数据库默认的参数与实际环境不完全匹配。

上线优化可能比较简单，也可能比较复杂。简单情况下，可能仅仅通过简单的数据库参数配置或操作系统配置就能解决问题。复杂情况下，就需要综合运用本书后续介绍的各种优化方法和手段来解决问题了。

2. 响应逐步变慢的系统优化

在业务系统运行了一段时间后，业务系统响应速度逐渐变慢，有时甚至难以忍受。这是普遍存在的现象，这时就需要对系统进行调整和优化。一般来说，这类系统具有以下特点。

• 业务系统和数据量具有较强的线性关系，随着时间的推移，数据量迅速增长。

• 业务系统与业务及资源具有较强的线性关系，随着时间的推移，业务在发展、公司规模在扩大，业务量迅速增长。

• 业务系统并发性设计不够周全，随着时间的推移，并发访问量增多，用户连接数增多。

• 数据交换共享增多，不同业务之间出现并发性和资源上的碰撞，系统后台等待事件增多。

总体而言，这些问题都与业务系统运行时间的长短有很大关系，因此，只要记录好相关指标随时间的变化，一般就能比较容易地发现系统性能变差的原因，从而有针对性地采取相应措施，使业务系统的运行快速恢复正常。

3. 运行过程中性能突然下降的系统优化

这类问题也被称为应急性性能优化，是日常运行中针对业务系统的最常见的优化工作。从性能突变的角度来看，一般存在以下情况。

• 新的业务模块上线或进行了补丁修复。

• SQL语句执行计划发生变化。

• 数据库定义语言（Data Definition Language，DDL）操作导致SQL依赖对象发生变化。

• 意外的配置变化。

• 依赖资源发生故障或性能降低，导致吞吐量下降。

• 执行了某个意外操作。

• 某关键进程被挂起或被kill。

这类问题的优化也相对比较简单，只要检测出突然变化的原因即可。即使无法检测出原因，也可以通过恢复系统的操作来恢复业务系统的运行状态。当然，这类问题由于突发性强，往往要求处理时间短，因此，要注意日常收集关键指标及版本变化。

4. 性能时好时差的业务系统优化

性能时好时差的业务系统优化与上述第3种情况类似，但其形成原因不同。这种业务系统性能降低的场景通常是周期性发作的，维持时间从几秒、几分到几小时不等。一般来说，发生原因为应用系统无法度过业务高峰期，达到了吞吐量限制。

对达到吞吐量限制的业务性能进行优化时，优化者需要熟悉吞吐量与响应时间的关系曲线，了解各种资源的最大吞吐量或能力限制。扩容往往是针对吞吐量限制型优化最直接的方式，但因为涉及额外投资且需要持续较长时间，所以性能优化者必须有充分的理由来支持扩容，并且要保证扩容后可以满足业务性能的要求。扩容通过扩展资源来支持更高的吞吐量突变点，从而完成业务性能的改善。与扩容相对应的另一种方式是更加有效地利用资源，如减少单位操作数据或单位操作消耗的资源。

5. 预防性日常性能优化

预防性日常性能优化依赖日常监测的性能因子，当这些性能因子达到预先设定的警戒值时就会进行优化，使其回归到正常范围或减缓其增加速度。要想保证一个系统始终保持高性能的运行，预防性的日常性能优化是关键因子，甚至比性能设计还重要。作为一个性能优化者或运维DBA，虽然业务系统的性能设计不受其控制，但是尽可能地延缓业务系统性能问题的来临是完全可以的。

预防性日常性能优化的作用主要在于：首先，延缓业务系统的硬件扩容，延迟资金投入；其次，可以使用户对未来性能预期有一定的明确性，从而可以合理安排扩容采购窗口，避免业务系统出现性能问题，提高服务质量。而缺乏预防性日常性能优化意识往往会造成一段时间内糟糕的业务系统性能表现及硬件扩容的紧急采购。

1.1.5　优化到什么程度

优化不是无极限的，不是想优化到什么程度都可以。优化往往与投入的成本有关，一般而言，投入越多，收效越好，但这不是绝对的。因此，往往在投入和性能之间取得一个平衡。优化不是每时每刻进行的，每次优化要么是为了解决某一问题，要么是为了让业务系统达到合同约定的某一服务等级。因此，在优化之前一般会设定一个优化目标，该目标往往是具体、可量化、可实现的。

具体的目标是指针对某一业务在规定的一段时间内能够完成的程度。例如，“系统响应应尽可能快”就不是一个具体的目标，而“周报表套件完成时间应小于1小时”则是一个具体的目标。

可量化的目标具有可以度量的客观数量。如果目标是可量化的，那么目标是否达到就很清楚了。具体的目标也很容易成为可量化的目标。例如，“用户响应请求的时间为10秒”既是一个具体的目标，也是一个可量化的目标。但要明确此目标是否针对所有用户请求、是否为平均响应时间、如何度量平均响应时间，对目标中的用词进行具体的定义是十分必要的。如果将目标表述改为“用户响应特定请求的时间为20秒或更短时间”，那么就可以客观地确定在何时能够达到目标。

可实现的目标是指可能的，并且在优化负责人的控制范围内的目标。在不同的阶段，不同的人都可能对系统进行优化。对于数据库管理员来说，以下目标则是无法实现的。

• 如果目标是优化实例以创建高性能的应用程序，但是不允许DBA更改SQL语句或数据结构，那么可实现的优化量就会受到限制。

• 如果目标响应时间为1秒，但是服务器与客户机之间的网络延迟为2秒，那么若不对网络进行更改，则无法实现1秒的响应时间。

为了确定是否进行了足够的优化，通常需要制定可量化的优化目标，DM8优化目标清单如表1-1所示。