如何让你的数据库优化项目事半功倍

数据库优化分为常态化优化与数据库优化项目两种形态。对于日常数据库运维工作中的优化工作，一般都可以纳入常态化优化范围。而有时候企业需要针对数据库进行全面的优化，通过一个规范化的项目来解决目前数据库中存在的问题，那么这时候就涉及到了数据库优化项目这样的概念。数据库优化项目对于企业来说往往都是大事，无论企业大小，如果必须通过一个项目来优化数据库，说明数据库的性能已经对企业的业务造成了较大的影响，因此数据库优化的效果对于企业来说关系也十分重大。而作为数据库优化项目的实施者，对数据库优化的效果好坏也有十分重要的责任。那么我们该如何更好的实施数据库优化项目呢？技术是第一位的因素吗？事实上，一个数据库优化项目中的技术因素往往不是最大的，要让一个数据库优化项目事半功倍，必须掌握一些优化项目的实施技巧，今天我们就来讨论一下数据库优化项目中的一些技术和非技术因素，其重点放在非技术因素-工作流程上。

数据库优化项目是一个IT工程项目，因此所有的IT工程所有的特性都具备，所有的工作流程也十分类似。一个企业级的数据库优化项目涉及应用系统、中间件、网络、数据库、服务器、存储、云平台、大数据平台等多种IT组件，因此整个优化工作需要多部门的紧密协同。数据库优化如果脱离应用系统和其他的IT组件，那么将会是事倍功半的。

从工作流程上看，一个数据库优化项目大致分为项目管控流程、技术处理流程两个既相互独立又紧密关联的流程组成。

项目管理流程是确保优化项目能够有效执行，并取得良好效果的重要保证，也是我们经常忽略的。很多系统优化项目最终被做成了技术人员面对黑盒子埋头苦干的项目，虽然技术人员付出了很多努力，但是最终的结果往往差强人意。因此加强项目管控流程对大型数据库优化项目来说至关重要。考虑项目管控流程的完整的系统优化工作流程如下图：

开工会是优化项目中十分重要，但是往往被忽略的部分。开工会需要和优化相关的所有单位参与，包括项目管理方、优化项目组、用户单位、运维单位、系统建设单位等，通过开工会将明确这些部门之间的分工与接口，确保在优化工作进行过程中，不会因为部门之间的协作出现问题而导致工作受阻。同时用户单位的参与会对优化目标提出一些修正的建议，使优化工作的目标更为明确。同时开工会也让其他部门知道优化项目的存在，当项目组需要其他部门配合的时候，比较容易协调资源。另外一方面，开工会有业务部门的参与，因此优化项目组可以更多的听到业务部门对系统运行情况的看法，从而让项目组对系统的运行情况有一个更为全面的认识。

把定义优化目标放在这里似乎有些怪异，很多朋友会认为定义优化目标应该放在立项阶段，有了目标才好立项啊。事实上，在项目立项之初，很多企业都会存在优化目标不准确的问题，只能确定一个十分模糊的目标。这个目标作为最终的优化工作目标十分牵强。而开工会之后，需要根据开工会上各个单位的需求，重新修订优化目标，该优化目标在绝大多数情况下是高于立项时确定的优化目标的，如果开工会开的效果好，那么优化目标也会具体很多。对优化目标的调整，大多数情况下是根据立项的优化目标进行部分的调整，但是也不排除根据开工会的业务部门、运维部门提出的需求，要做较大的调整，此时是需要进行决策的，因为整个优化项目的成本是在立项时已经确定的，对于预算管理较为严格的企业来说，很难突破预算。因此优化项目组需要根据项目成本去设定合理的优化目标，而不是盲目的按照业务部门与运维单位的需求去简单的修改优化目标。如果在修改优化目标的时候，发现无法控制成本，则需要进行一些折中处理，先满足业务部门与运维单位较为紧迫的需求。

采集数据是优化项目前期需要做的主要工作，这个阶段的工作成效对于优化目标的达成十分关键。数据采集不能完全靠手工采集，必须配合一定的自动化工具，才能采集到准确和充足的数据。比如通过APM工具采集到关键应用模块的运行状态数据；通过操作系统监控工具nmon/osw等采集到CPU、内存、IO、网络方面的数据；通过数据库的性能采集工具采集到数据库性能指标与TOP SQL的数据。采集工作涉及的面很广，但是也不能过于发散，因为采集的数据往往是需要人去分析的，过多的数据采集会导致分析数据的人员不足。因此数据采集一般采用自顶向下的方法，首先采集顶层分析所需要的数据，用于定位关键性性能问题。一旦发现某个维度存在较为严重的问题，再进行深度采集，便于深度分析与故障定位。

基线分析阶段主要针对发现系统中对性能影响较大的维度的相关指标数据，与企业或者被优化系统已经建立的基线数据进行比对与分析，进一步定位存在问题的关键指标点，从而更加精准的定位系统存在的性能隐患，便于设计方案进行消缺。传统的基线分析是十分依赖于专家的能力的，如果优化团队的专家能力不足，那么这个阶段的效果也很难提高。近年来，随着智能化运维技术的发展，一些分析工作可以由一些智能化运维工具或者一些智能化分析算法来替代。有这些智能化的手段加持，既可以对专家做到查漏补缺，又可以弥补专家在某些领域的能力不足。

经过上述分析后，可以生成优化方案了，优化团队根据以往的工作经验与技术分析的结果制定优化方案的初稿，对于某些优化项目，可能需要提出多个备选的优化方案，供后续多部门联合评审时选择。

优化方案评审阶段是由优化团队、运维部门、应用开发商与应用部门共同参与的，优化方案的涉及面很广，除了系统级的调整外，优化方案可能会对某个应用模块的编写方式提出优化建议，甚至有些优化方案会对应用部门的使用习惯与使用方式提出优化建议。因此这些优化建议是否能够被广泛接受，需要通过评审来最终确认。该过程有可能需要经过多次，当某次评审的参与方无法达成一致性的意见的时候，往往都需要优化团队对方案草稿进行调整。

优化方案评审后就进入优化实施阶段。根据经过评审后的优化方案完成优化实施方案的编写，然后根据优化实施方案完成优化消缺工作。在这方面不同企业的流程会有所不同，需要按照各个企业的流程设计实施方案。

优化实施后，需要人员在现场值守，值守的目的有两个，一个是一旦优化工作出现了副作用，可以及时处置，避免引起大问题；第二个是采集系统的指标数据，与优化前进行比对，评估优化效果。如果优化效果达到了优化目标的要求，则可以进入优化总结阶段，否则需要分析未能达到目标的原因，再次迭代数据采集到优化实施的过程，直到达标为止。

优化目标达成后，就进入优化总结阶段，分析本次优化的效果，并总结本次优化工作中的得失。很多企业都不太重视这个环节，实际上总结阶段可以让本次优化工作中发现的问题成为企业知识库中的核心内容，同时优化工作中发现的一些需要在今后运维工作中注意的问题，是企业改进运维工作质量的十分重要的来源。因为大多数企业并没有构建自己的知识库，或者企业的知识库无法很好的发挥作用，因此对于这些企业来说，哪怕是本次优化工作中已经总结出了不少好的经验，也无法转化为有价值的知识。对于一些大型企业来说，构建自己的“运维知识自动化系统”是十分重要的，因为这个系统可以让企业的知识库真正变成企业的核心价值之一。

最后一个环节是知识传递，优化团队在优化过程中发现运维、应用系统以及使用方面的经验需要总结出来，传递给现场人员。知识传递的目的是让优化效果可以长久保持下去。

上面讲述的是优化工作的业务流程，实际上从技术角度上，数据库优化工作中更关注的是另外一个流程，就是技术流程。无论是针对日常优化、常态化优化还是优化项目，技术流程是类似的。一个通用的技术流程如下图所示：

数据库优化的技术过程分为监控、识别、分析、提升、验证五个环节。监控主要是监控系统的当前活跃状态，近期活跃状态，中长期活跃状态，周期性特征，以及系统的重大特征与系统变更的情况。通过对数据库运行指标与日志信息的采集以及人工监控工作，从中我们需要识别处一些有价值的现象与数据，包括看资源争用的情况、关键资源使用的情况、SQL执行时间、系统状态不好时的争用情况等。当我们已经识别到了足够的信息，足以完成本次优化工作了，那么我们就进入了分析阶段，分析阶段主要的工作是分析整个系统运行的环境，发现系统存在的瓶颈，关键数据库对象的定义状态，以及这些对象是如何被访问的，应用代码与SQL语句是否合理等。在提升阶段，我们主要通过调整系统参数、调整数据库参数、优化I/O子系统、优化应用与SQL语句、调整SQL访问数据库对象的方式、调整数据库对象的存储方式、调整应用模型等方式来完成优化工作。在效果验证阶段，我们可以通过采集系统运行指标、听取用户的反馈、分析应用访问方式的优化与响应时间的提升等方式来采集数据，进行评估与分析。

无论是哪种优化工作，上述过程都是不断地循环迭代，从而让数据库的性能螺旋式上升，确保数据库运行的效率，提升数据库的可用性。