节选：第2章性能优化利器——PAT方法小节2.1+2.2-CSDN博客

第2章

性能优化利器——PAT方法

数据库系统出现性能问题，好比人得了病一样，需要治疗。俗话说，“症见于四肢五官，病隐于五脏六腑”。本章阐述如何从体系层面上运用PAT方法学定位问题、调理系统、优化性能。PAT方法学使用PAT树来定位数据库性能问题，其本质是提供了一套系统化的优化思路。这已成为一种标准，被大量实践证明是切实可行的。

在本章结尾的“案例分析总结”中，就记录了PAT方法学的现场应用。

如果对一位经常感冒的病人，医生只开出感冒药；对一位经常咳嗽的病人，医生只开出止咳药，那么患者可能碰到庸医了。因为这是在治标而非治本。庸医治病引发的后果就是，症状不但没好，病却越来越多。其实需要重点治疗的是发病的脏器，以及调理生活习惯。内在系统通顺了，外在症状自然消除。对于数据库性能的症状，我在第 1 章作了介绍，给出的是 PAT 方法系统，它可以协助你梳理问题的来龙去脉，从而清除掉性能优化的障碍。

接下来通过一个经营分析系统的优化案例，开始熟悉PAT的应用过程。在电信和金融行业中，经营分析系统能最大限度地整合企业的各类历史数据和交易数据，为企业提供统一的数据支撑平台，并提供相应的统计分析报表、多维分析（OLAP）、数据挖掘（Data Mining）等应用功能。经营分析的目的是发现数据中的趋势，从而能够更有效地满足企业的战略决策支持需求、业务操作需要及技术需求，同时也为企业进一步建立有效的客户关系管理系统提供坚实的数据基础。概括来说，经营分析系统是为企业经营管理、市场营销和业务运营提供分析决策支持的系统。

2.1 优化步骤

介绍经营分析系统的架构后，本案例采用本书第1章1.3.4节所阐述的优化步骤：即首先业务角度来确定性能问题，并设定每个问题的优化目标及优先级；随后，从系统角度确定性能问题的根本原因，找到时间是如何被消耗的；进而，使用PAT方法学四项原则制订优化策略；最后成功优化数据库并完成性能验证。

2.2 业务分析

2.2.1 经营分析系统的架构

如图2-1所示，经营分析系统是企业的信息集成平台，因为业务架构往往都是基于基础数据仓库的。与面向事务的数据库不同，数据仓库的重要特点是面向主题。主题是一个在较高层次将数据归类的标准，是用户使用数据仓库进行决策分析时所关心的重点方面。每个主题对应一个分析领域，通常与多个操作型信息系统相关。数据仓库数据的组织方式可能已经完全不同于原始的业务系统。根据业务需求的不同，数据仓库的组织形式以第三范式模型为主，在有的系统中也可能采用星型或雪花模型。

经营分析系统为应用提供了在线分析处理（OLAP）能力。这使得用户可对数据进行分析以获得透视能力，并在此基础上采取行动。用户可以访问、计算及共享信息，以便跨越产品、市场、职权、流程、时期和情景等进行绩效检查、质量评判及因果分析。信息门户网站为整个公司的内网用户管理报告出版及订阅，另外，既然已建起了信息访问平台，并且具备了实时信息，配置相应的门户网站应用程序必然轻而易举。

图2-1 经营分析系统

在本例中，从来源复杂的数据进入数据仓库之前，必须经过ETL（Extract、Transform. and Load）过程，来消除来自不同数据源的数据不一致之处，以保证数据仓库内的信息是一致的全局信息。全局信息包括未经汇总的客户交易数据，用户资料数据、客户服务数据等。此外一些相关数据如竞争对手，成本投资数据也包括在内。由于基础数据仓库中的数据是对原始业务数据的再现，所以数据量会非常庞大，根据不同业务的需要数据保留的时间在6个月到2年不等。通常根据需求将数据仓库数据分类成几个不同的数据集市，每个数据集市完成不同的分析和查询需求，数据集市中的数据通常由基础数据仓库的详细数据聚合而来。根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。数据聚合方式将依据数据量的大小和使用频度综合考虑。

本例中的经营分析系统从架构上来看，自下而上主要包括4层，即获取层、存储层、应用层和访问层，具有下面的特点：

<!--[if !supportLists]--&gt— <!--[endif]--&gt一个中心数据库，以便为所有可用信息资产提供在线目录。

<!--[if !supportLists]--&gt— <!--[endif]--&gt一组全面的、集成的信息视图。

<!--[if !supportLists]--&gt— <!--[endif]--&gt为决策所需信息提供简便的返回方式。

<!--[if !supportLists]--&gt— <!--[endif]--&gt完善的应用程序、门户网站产品、报告及商务智能工具、对迅速生成特定报告所需信息的快速建模及重建模能力。

<!--[if !supportLists]--&gt— <!--[endif]--&gt可满足现存报告及分析流程的灵活环境。

<!--[if !supportLists]--&gt— <!--[endif]--&gt对多变的业务需求的快速支持，同时需考虑到高度的可用性、性能及可伸缩性。

<!--[if !supportLists]--&gt— <!--[endif]--&gt通过有选择地将那些不需要实时处理的数据转移到数据仓库，从而使得操作型数据库系统减轻负担。

2.2.2 性能问题的提出

在第1章讲过基于CBA的性能优化策略，这个策略是用来找到成本和性能的最佳平衡点的。性能优化并不意味着片面追求性能的最大化，因为优化是无止境的。我们必须根据业务需求来设定目标，没有目标就不知道何时停止研究更好的解决方案。

我们知道，提升应用或者系统的性能是为了给业务带来价值，那么当开始处理性能问题的时候，必须先理解业务问题和需求。在系统分析前，首先向数据库管理员、应用程序开发人员及架构师了解了该经营分析系统的业务情况，如表2-1所示，最终确认了目前经营分析系统存在的6个性能问题。其中概要部分描述了每个问题的症状，影响范围说明了该问题仅仅存在于某个应用还是影响了整个系统。另外，对每一个性能问题，我们都制订了可量化的目标，例如对编号为“Perf_Load_App”的数据转入问题，我们的量化目标是“数据转入不超过30分钟”。在实际的优化过程中由于时间或预算是有限的，所以我们为每个问题排定了优先级。

表2-1 性能问题（业务角度）