首席DBA用SQL洪荒之力，造一把通向数据库的钥匙

这是Oracle执行计划简单的示例,说明了执行计划的大致内容.

前面讲了很多理论内容,下面通过几个案例说明一下.方便大家对前面内容的理解.

• 案例1：数据库对比

第一个例子,是一个优化器行为的对比案例.示例对比了三种数据库(四种版本)对于同样语句的行为.通过这个例子,大家可以了解,不同数据库(乃至不同版本)优化器的行为不同.对于数据库选型、数据库升级等工作,要做到充分的评估测试,也正是出于此目的.

简单构造了两张测试表,主要注意的是前一个字段是包含空值的.

第一种情况,是对于IN子查询的处理.对于Oracle来说,10g、11g行为相同,这里就列了一个.

对于这样的一个例子,不同数据库已经表现出不同的差异.Oracle和PG的行为类似,MySQL由于不支持哈希连接,因此采用了其他处理方式.具体的技术细节,这里不展开说明了.

第二种情况,是对于NOT IN子查询的处理.这种情况下,Oracle的不同版本、PG和MySQL表现出不同的行为.从上面例子可以看出,11g的优化器在处理此种情况是更加智能一些.

• 案例2：解决“ERP汇单慢”问题

这里我构造了类似的结构,模拟了上线的情况.

示例是一个关联子查询,其核心部分是转化为一个表关联,并使用了嵌套循环的一个变体-Filter实现关联方式.显然,如果外层表过大或内层探查效率过低,其执行效率可想而知.通常来说,两表关联,嵌套循环是最后的一种选择,如果能使用其他方式(例如HASH JOIN、SORT MERGE)可能会带来更好的效果.

这里优化器没有选择更优的计划,是优化器的Bug?还是功能所限?可通过人工手段干预,看看是否能达到意向不到的效果.

引入了一个Hint-unnest,主动实现子查询的解嵌套.将子查询部分提前,让优化器有了更多的选择.从执行计划来看,优化器生成了一个内联视图,然后跟外部表实现了一个哈希连接,整体效率大大提高.

这个示例说明,优化器的功能还是有所局限.在某些场合,可以人工干预语句的执行,提升整体执行效率.

• 案例3：处理“ERP清理数据”问题

下面这个示例,是因为结构设计不良导致的问题.

在日常的优化中,我们往往遵循着“语句级、对象级、架构级、业务级”的顺序考虑优化策略.但在项目需求、设计阶段,是按照反向的顺序进行.后者的影响力要远远大于前者.一个糟糕的对象结构设计,可能会带来一系列SQL的问题.示例中,就是这样的一个问题.

这是某公司后台的ERP系统,系统已经上线运行了10多年.随着时间的推移,累积的数据量越来越大.公司计划针对部分大表进行数据清理.在DBA对某个大表进行清理中,出现了问题.这个表本身有数百G,按照指定的清理规则只需要根据主键字段范围(>=)选择出一定比例(不超过10%)的数据进行清理即可.但在实际使用中发现,该SQL的是全表扫描,执行时间大大超出预期时间.DBA尝试使用强制指定索引方式清理数据,依然无效.

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!