2013数据库大会:盖国强-Oracle优化器与算法案例解析

盖国强 是ITPUB元老版主、云和恩墨创始人，他演讲的主题是"运用之妙 存乎一心 Oracle优化器案例与算法解析".分享了在云架构、大数据风起云涌的时代，企业在数据架构变革中面对的问题，以及Oracle优化器案例与算法解析。

▲ITPUB元老版主、云和恩墨创始人盖国强先生

　　在演讲中，盖国强表示，数据库架构的演进就是一个合久必分的过程。很多企业都经历过这样一个过程，随着企业不断发展，数据不断积累时，首先做的是拆分数据表、分割数据库、采用分布式数据库、进行异构与迁移，就是互联网企业所谓的去IOE。从Oracle最近的技术演进来看，Exadata最核心的架构演进在于存储，Exadata将存储拆分成多台分布式存储，这些存储又能 同时参与运算。同样，数据库架构的演进也是一个分久必合的过程。数据库面临合并整合，Oracle需要将其他数据库中的特性整合，以提升自身的性能，满足更多的需求。【编者按：这段内容是以前演讲的内容，应该是从别处转过来的】

　 　性能问题是最近几年来DBA们越来越关注的一个数据库技术领域，归根结底，造成它的原因是最近几年信息化进程的飞速发展，导致了很多系统的用户数量猛增，数据库中存储的数据量亦成几何级数激增，数据库作为数据处理和存储的最终受体，将必然直接承担这种变化导致的性能下降。因此在人们对信息的依赖性越来越强的时候，对信息使用的效率也变得越来越关注，这样数据库的性能优化问题就日益严重地压在DBA的身上。

　　优化器是SQL执行中最核心的部分，如果要分析SQL的性能，就不能不了解Oracle优化器的机制，这一章，我们就带你走进Oracle优化器-CBO的世界。

　　基于成本的优化器 - CBO

　 　对于我现在所做的ORACLE优化，其实还停留在SQL优化的层次（以前我的前辈曾给我说关于数据库优化的三个层次：一是针对SQL的优化，如使用正确是索引，使用ORACLE提示等；二是针对数据库对象的优化，如增加索引，微调表结构等；三针对业务的优化，需要更改业务逻辑或者表结果，此类优化一般代 价比较大，一般很少针对正在运行的系统做类似的操作）。

　　优化器算法 - 成败之所系

　　对于ORACLE应用系统的优化，大方向上有一个顺序，首先考虑优化业务系统、再考虑优化ORACLE系统本身的参数（如内存分配等），再考虑操作系统本身的优化；在优化业务系统中，首先是首先相关的SQL,以SQL入手分析表是否缺少索引，表连接顺序是否正确，使用的索引是否正确等，然后再考虑调整表结构，调整业务逻辑等等。因此，SQL语句是我们对一个ORACLE业务系统进行优化的敲门砖。

　　优化器算法 - 成本计算

　 　对于找到的SQL语句，盖国强表示，我们可以逐一分析其执行计划，结合涉及到的表的数据量，我们可以估算或者测试该语句的执行效率，分析表WHERE条 件中涉及的字段（术语叫做谓词），该字段数据分布如何，选择性是否好，是否有索引。这是一个非常繁杂和琐碎的工作，但从这些琐碎的工作中，我们能发现那些 SQL执行时选择的索引不对，哪些表缺少相应的索引导致了全表扫描，哪些语句条件不够导致对分区表进行了全表扫描。总之，对于一个给定的SQL,我们结合其表数据量的大小和分布，SQL中使用的查询条件，能够找到一个性能最优的执行方式，通过调整索引、使用ORACLE提示，使ORACLE系统按照最优的 方式来执行SQL.

　　解决之道

　　知己知彼 百战不殆

　　优化器依赖统计信 息，在变更和维护的过程中，充分考虑统计信息的变化；给DBA时间充分研究那些重要的技术；扬长避短，手工设置统计信息（SET_TABLE_STATS ）维持计划的稳定；在变化和边界中识别风险：月底月初、年底年初、分区增减等都可能带来问题；了解和研究那些被隐藏的秘密。

　　DBA 成功之道

　　不断积累，不断成长，举一反三；绕过问题是一种能力。

　　对于SQL的执行方式，需要在工作中不断积累经验，比如曾经在一次优化中发现对一个表安三个字段查询的非常多，因此决定建立该三个字段的复合索引，但结果其语句执行效率却更差。