数据库性能优化“路线图”

数据交互复杂度与频度的提升，导致了数据库在运维、迁移和规模扩展进程中的性能问题。作为一项确保企业IT基础部件健康运营的关键技术，数据库性能优化的实现路径和IT系统管理架构越来越密不可分。

南方某省级电信运营商的计费业务营账系统在上线运行后不久即出现性能问题。主要问题表现在最终用户的交互响应达不到预期，特别是在业务繁忙时段无法做出及时响应。从主机系统的角度观察，问题主要集中在系统的I/O（输入/输出）等待较大。而该营账系统由业务应用程序、甲骨文数据库、IBM AIX主机、IBM企业级存储服务器等部件构成，性能瓶颈的定位和优化过程均较为复杂。

数据库专家通过应用性能监测工具分析系统运行状况，在对主机和存储系统进行调优、并确保其能够满足现阶段生产系统的处理需求后，对甲骨文数据库的优化提出了针对性的建议。建议包括，为了应用系统扩容后处理压力的增大，对甲骨文数据库的性能参数进行修改；通过监测软件排查资源消耗最大的SQL语句的逻辑设计，将这些SQL语句的表结构与索引分别存储，建立合适的分区索引；通过监测软件对数据库和应用的数据分析，准确定位应用系统运行瓶颈，并做出相应的检查和调整。

这一典型案例浓缩了数据库性能优化过程中的几个关键步骤，及其在整体IT管理流程中的角色定位。在数据库成熟应用的时代，数据库的性能优化已经演变为一项相当严密的系统工程。作为企业IT基础设施的核心部件之一，数据库并不是孤立的系统，它与网络、操作系统、存储等硬件系统紧密相连，这种与其他IT部件的多重连接特性决定了数据库性能优化是一门综合技术。

在应用丛生、高度分布式的环境中，要总结出一套“放之四海皆准”的数据库性能优化方法论并不容易。但结合企业自身特色的性能优化流程却是有据可循的。在流程确立的过程之中，企业首先需要明确的问题就是，无论从什么样的角度切入，都要确保优化行为能够与IT系统的整体管理框架保持协调地联动，因为数据库的性能问题不仅仅局限在数据库内部。在大部分情况下，其优化行为都要围绕IT整体性能调优的思路展开。

路径全局谋划

古语云：“不谋全局者，不足谋一域。”说的是如果不从全局角度考虑问题，是无法获得局部智慧的。具体到数据库性能优化，通常包含针对应用、参数、存储、硬件、网络、操作系统的优化操作。有统计显示，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，只占数据库系统性能提升的40%左右，其余60%的系统性能提升则来自于对应用程序的优化。作为金融、电信行业的资深数据库顾问，庄梁科技(北京)有限公司数据库专家牛新庄博士指出，数据库性能优化在很多时候都需要解决数据库以外的问题，这要求实践者具有完整的知识体系，是一项非常具有挑战性的工作。

“系统资源紧张是导致数据库性能问题的根本原因。”牛新庄博士说。针对常见的来自CPU、内存、磁盘I/O、网络的系统资源损耗，他总结了一套常规的问题流程。具体包含定位性能瓶颈、判断最消耗资源的应用或SQL，对逻辑资源的重新划分、、分析性能问题是否局限于数据库、追溯问题原因等步骤。

在阐述数据库性能优化的整体性时，海关数据库专家王翔强调，单点调优对数据库性能的提升意义不大。他指出，在针对常见的分布式数据库引擎的优化过程中，DBA（数据库管理员）的主要任务包括网络、架构、存储的调优和业务应用的优化，除此之外，还有通常被IT部门所忽视的用户体验的优化。“数据库性能优化存在很多程式化的内容，每一个的DBA都有自己解决问题的套路，而这些套路的共同点是从全局角度出发实施具体操作。”王翔说。

现阶段，用户反馈和运行监控是DBA发现数据库性能问题的主要来源。发现故障后，DBA需要用手动指令或专业的监控分析软件排查系统故障点，并确定合理的性能优化步骤。其基本的指导原则为，通过尽可能少的磁盘访问获取所需要的数据（常规的调优策略如图1所示）。数据库系统外的应用优化通常涉及源代码和SQL语句的调整。比较而言，源代码修改存在较高的时间成本，同时可获得的性能提升收益有限；由于应用程序对数据库的操作通常最终表现为SQL语句对数据库的操作，因此SQL语句的优化能够以提升SQL执行效率的方式实现数据库性能的提升。

图1：数据库性能优化常规策略

每个DBA眼中都有一条数据库最佳优化路径。而企业间IT应用的天然差异是导致这一结果的根本原因。同时，数据库性能优化方法还具有浓重的行业色彩。“银行的数据库应用以短交易为主，即主要涉及银行内部的固定数据处理流程，数据库优化主要以集成式优化操作为主；而税务行业的主营业务以长交易为主，一些审批流程需要在系统外部运转，其数据库故障的定位和优化将与短交易优化操作有所区别。”牛新庄说。

王翔在分析海关数据库应用特色时指出，海关数据库应用主要集中在甲骨文和SQL Server平台，数据处理以短交易为主，强调数据交换能力，但数据总体容量不如金融、电信等行业，同时数据交换以内部为主，不存在大量用户基础对数据库系统的访问。围绕这些特性，在实际的操作中，海关IT部门的数据库性能优化操作主要围绕基于快照、单双向复制的集成式优化展开。应用优化方面，主要涉及数据库参数的合理配置、数据库端缓冲调整，以及对频繁调用应用服务的打包处理。王翔介绍，中国海关专门成立了IT优化小组，负责制定和执行包括数据库在内的IT整体优化策略。

而在行业应用内部，不同系统对数据库性能的要求也不尽相同。以电信应用为例，某省级电信公司就从实际需要出发，将计费系统和销账系统分离，各自独立承载不同的数据处理任务。之所以进行这样的划分，是由于承载原始话单采集计费系统的特点表现在用户数少、数据库连接数少，数据存储量大，磁盘I/O高，但对响应时间的要求不高；而负责缴费的销账系统面对的是柜台营业员和电信用户，用户数量多，数据库连接数量大，但数据存储量和磁盘I/O都相比计费系统小得多，同时对系统响应时间要求高，要做到不超过3秒的时间响应。考虑到两种应用对数据库资源的需求存在很大差异，采用一个数据库会导致容量过大和管理不利，而I/O数据量过大时可直接降低响应时间。出于保证应用可靠性和系统安全的需要，该电信用户最终决定在设计时对两种功能的支持系统进行了明确划分。

谈到不同品牌的数据库优化流程是否存在差异的问题时，牛新庄和王翔两位数据库专家均表示，主流关系型数据库的优化基本遵循固定的流程。在具体的操作过程中，都是通过分析数据库对CPU、内存、磁盘I/O和网络的占用情况，与具体的应用相结合做出最终的性能瓶颈定位。但是，不同类型数据库的优化则会体现出明显的差异性。王翔指出，关系型数据库和XML数据库在数据库参数配置时就会涉及完全不同的技术细节。“关系型数据库的优化主要涉及索引的合理使用、I/O改造等内容，而XML数据库的磁盘I/O表现不同，数据存储以大字段为主，与应用的结合更为紧密。针对XML特性，DBA需要运用介于数据仓库和关系型数据库之间的数据库参数进行调整。”王翔说。

设计规避风险

和其他IT基础组件一样，数据库性能下降很大一部分的风险是能够在数据库的设计阶段予以规避的。因此，设计优化也就成为了数据库性能优化技术的源头和方向。牛新庄指出，目前企业的数据库应用普遍表现出对设计阶段优化的忽视。根据多年的行业服务经验，他表示，企业对设计优化的不够重视主要体现在，工期紧张，开发时间短，以及系统匆忙上线后未经过充分优化和测试。“数据库逻辑结构的不合理、索引设计不合理，开发阶段的技术冲突无法调适，多种因素的累积作用导致了许多数据库系统上线后不久即出现性能故障”牛新庄说。

完整的数据库性能优化周期可以分为两个阶段，一是设计与开发阶段，主要负责对数据库逻辑和物理结构的优化设计，使其在满足具体业务需求的前提下，系统性能达到最佳，同时系统开销最小；二是数据库的运行阶段，其优化手段以数据库级、操作系统级、网络级为主。比较生命周期的调优成本与调优收益曲线，我们发现性能调优的成本随软件生命周期进程而增加，但调优收益却随软件生命周期进程而减少。由此可见，数据库上线之前的早期测试和调优工作不仅是日后数据库健康运维的基础，同时也可以有效避免那些应用后期不必要或需要付出高昂代价的优化操作。

为了减少因为数据库“被动”设计而导致的性能问题，王翔所在中国海关信息中心采用了DBA主动参与项目设计评审过程的方法，及早找出数据库的设计缺陷。项目协作方面，数据库专家还会与存储专家共同规划统一集中式存储架构，依据主干业务、其他业务等应用职能对数据库应用结构进行分割，并参与确立IT基础设施的备份、监控流程，力求将数据库的存储问题、物理布局等问题“消灭”在项目设计阶段。