突破瓶颈 数据库性能优化“路线图”

数据交互复杂度与频度的提升，导致了数据库在运维、迁移和规模扩展进程中的性能问题。作为一项确保企业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执行效率的方式实现数据库性能的提升。

 

每个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基 础设施的备份、监控流程，力求将数据库的存储问题、物理布局等问题“消灭”在项目设计阶段。

术业有专攻

利器善事。数据库性能优化不能缺少有着丰富经验和严密知识体系的数据库专家，同样不能缺少完整的数据库性能保障框架和专业化的优化工具。伴随着关系 型数据库三十余年的稳定发展，数据库性能优化已经成为商业IT管理软件供应商繁衍生息的乐土。老牌系统管理软件厂商BMC和CA都拥有数据库优化的产品工 具；同时，这一领域还催生出很多以数据库优化为主营业务的软件公司，例如分布式数据库优化的领导者Quest Software、应用性能管理厂商Precise（2003年被VERITAS公司以6亿美元的价格收购，并随VERITAS被赛门铁克连环收购，其 i3产品系列并入赛门铁克旗下），以及提供图形化异构数据库管理工具厂商Embarcadero（相关产品及关键特性如附表所示）等。与此同时，数据库原 厂商也向用户提供相关的优化工具。

“专业优化工具可以改变黑箱操作模式，为DBA呈现一张数据库实时运行状态的全息图。” Quest虹天软件（北京）有限公司高级经理田三稳说。据介绍，Quest Software的数据库优化工具Quest Central可支持甲骨文、DB2、SQL Server和MySQL平台, 能够快速诊断和解决多种数据库性能问题。通过直观的图形化用户界面，可以快速定位性能瓶颈，追溯问题根源，针对应用过程对最常见的SQL问题进行优化。 Quest Central提供的自动化SQL优化机制，可以在不执行应用的前提下，通过代码扫描找出低效率查询并加以优化，消除SQL语句中的性能瓶颈。而待优化语 句还会被自动重写为备份语句供DBA调整使用。

从甲骨文数据库优化起家的Quest Software，已经将其数据库性能优化产品扩展到多种关系型数据库平台。谈到以Quest为代表的专业优化软件的优势，田三稳表示，原厂商工具的局限 性体现在缺乏跨平台的监控和诊断能力，而跨平台的数据库应用优化恰恰是企业的普遍需求。他坦言Quest Software正面临着来自原厂商工具的竞争。“随着甲骨文数据库的不断升级，它所附带的优化工具也开始提供一些与我们类似的功能，同时价格更低，但我 们的优势是对跨平台数据库环境的透明支持，我们为客户提供了搭建集成化通用数据库性能优化平台的技术和方案”他说。他同时强调，与同类厂商相 比，Quest Software的特色之处包括，具有亲和力的图形化诊断界面、独特的表空间重组技术、完善的底层专家知识库、自动化SQL优化以及对系统性能的实时诊断 能力。

Quest Software拥有自己的数据库性能优化方法论，由监控、诊断和问题解决三个连贯的环节所构成，在兼容用户个性化管理需求的同时，可以为客户构建集中 式、跨平台的数据库管理解决方案。目前，其优化工具已经在北京移动、上海移动、北京地税、北京电力、山西网通、海关总署、中国工商银行、东芝复印机等客户 环境中得到部署。

一线数据库专家对专业优化软件持有自己的看法。牛新庄就指出，这些软件的主要功能是监控，能够定位问题却不能进行调整，当最后发现性能故障与应用或 数据库设计有关后，还是需要DBA做出手工调整。在现阶段，市场上的专用软件仍无法替代数据库专家手中基于脚本的定制优化工具；海关的王翔则表示仍然习惯 于脚本操作方式，大部分的数据库并没有安装图形化管理界面。“甲骨文的Web监控工具在实际的操作中还是不够实用，对于DBA来说，管理工具越轻量级约 好。”王翔说。而很多DBA没有采用专用软件还有一个原因，就是在系统宕机时，这些工具是无法使用的，DBA必须通过脚本语句查看数据库内部状况。

针对DBA对手工操作和脚本方式的偏爱，田三稳表示，专用工具的很大一部分价值体现在对性能故障的预见和主动管理能力，以Quest Software工具为例，它既提供事先预警机制，还提供实时诊断、历史回放和性能参数的分析报告功能。“数据库高手可以凭经验或编写脚本来解决问题，但 大部分中小企业的DBA并不具备这样的能力。Quest可以为这些企业提供一个功能齐全、使用方便的数据库监控管理平台，帮助他们建立起性能管理机制。” 他说。他同时指出，一些企业具有非常高的IT审计要求，限制使用手工编写管理脚本或对数据库进行修改，这时专业工具的优势就显现出来。另外，在发现空间问 题、空间重组和容量规划等数据库存储优化领域，Quest等工具也具备预防性维护和问题预测的能力。

经验、工具和全局观是做好数据库性能优化必不可少的三要素。今天的数据库性能优化不再是一个狭义的话题，当我们越来越深入其中，就会发现其覆盖了相 当广阔的技术和管理领域。数据库应用的复杂性决定了DBA智慧和专用工具的协同作战将成为未来应用的方向，而作为一个垂直的优化流程，数据库性能优化将与 新一代的IT管理框架实现更加透彻和更深层次的融合。

编看编想

这是个不断变化的话题，因为在IT应用快速进化的今天，数据库的职能和在IT系统架构中的角色定位在不停地变化着。这是我们仍会感觉这个话题如此鲜活而又充满探索可能的原因。

对每个DBA而言，这个话题所覆盖的庞大技术疆域都是极具诱人和挑战性的。在经验和专用工具之间，DBA们需要找到一条能够最快速发现问题和解决问 题的路线图。必须承认，我们真的很难为这种处在不断变化中的技术应用绘制一幅“百战百胜”的路线图，但是可以针对可能出现的数据库故障建立相对固化的处理 流程。所以，在DBA的脑海中，这幅路线图不一定有多么清晰或严谨，但它必须能够在你遇到问题时指引你该如何行动。

从某种意义上说，数据库性能优化是一项没有尽头的任务，因为用户对数据库性能的要求没有止境。在SOA时代，这一切会改变吗？很难预测重大架构变革 所引发的具体技术的联动效应，但可以肯定的是，SOA框架下的数据库性能优化所面对的挑战比今天毫不逊色。王翔表示，SOA所强调服务自治性，是原有性能 调优技术非常适用的；而在SOA的交互方面，应用对于服务编排和XML数据处理在交互过程中的重要性将进一步凸现，DBA需要根据应用“补补课”。

当数据库变身为数据服务，在成为独立服务的同时还要服务于众多的服务节点，这种超越以往的应用复杂性要求DBA刷新自己的知识体系、专用工具提供的管理功能更加精细化，同时也要求实践者在这个前所未有的开阔视野下，从崭新的战略全局观突破性能瓶颈。

 

 

转载于:https://www.cnblogs.com/xiefang1980/archive/2008/09/05/1284935.html