一个典型的多表参与连接的复杂SQL调优(SQL TUNING)引发的思考

Posted 数据库生态圈(RDB & NoSQL & Bigdata)

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一个典型的多表参与连接的复杂SQL调优(SQL TUNING)引发的思考相关的知识,希望对你有一定的参考价值。

今天在看崔华老师所著SQL优化一书时,看到他解决SQL性能问题的一个案例,崔华老师成功定位问题并进行了解决。这里,在崔华老师分析定位的基础上,做进一步分析和推理,以便大家一起研究探讨,下面简述该案例场景。

1、发生性能问题的SQL语句:

技术分享图片cu

技术分享图片

技术分享图片

--注:

  1)十几张表参与连接的较复杂SQL语句。

 

2、发生性能问题的执行计划:

技术分享图片

--注:

  1)计划中节点19在表S_EVT_ACT上发生了FTS,据说该表上有700多W的数据量。

  2)计划中节点34在表S_ACT_EMP上发生了index range scan(索引范围扫描)。

3、不存在问题的执行计划:

技术分享图片

--注:

  1)计划中节点23在表S_EVT_ACT上走了index unique scan(唯一索引扫描)。

  2)计划中节点19在表S_ACT_EMP上走了index range scan(索引范围扫描)。

 

4、分析:

    1)性能问题解决前,计划中节点19在S_EVT_ACT上发生了FTS;节点34在表S_ACT_EMP上发生了index range scan。

    2)性能问题解决后,计划中节点23在S_ECT_ACT上发生了index unique scan,且由原来的节点19推后到节点23;节点19在表S_ACT_EMP上发生了index range scan,访问方式与性能问题解决前没发生变化,而为之由原来的节点34被推前到节点19。

    3)对比性能问题解决前后,有两个变化,一个是表S_EVT_ACT由原来的FTS变为index unique scan,且为之被推后;另一个是表S_ACT_EMP为之被推前。变化的原因是optimizer_mode有原来的first_rows_10变为all_rows。

    4)针对前面讲到的,性能问题解决前后的两个变化,我们讨论下变化的起因和作用。性能问题解决前,因为optimizer_mode设置为first_rows_10,那么,CBO在这个模式下,面对这种比较复杂的多表连接的SQL语句,不会逐个去查询和计算每个参与连接的表的统计信息和成本,而是给出一个粗略评估的结果或默认值,为什么会这样,大家自己思考吧,其实,即使按照这个方法,也未必就一定出现性能问题,因为这种模式下,求的是反应速度,如果表S_EVT_ACT和其他表的连接字段的匹配性足够好,那么,也能达成反应速度最优的效果,这里,问题不在于走了FTS,而是在于表S_EVT_ACT连接字段的匹配性,可这种模式下,CBO不可能得出这个匹配性的准确结果的。因此,这是个非常冒险的决定,可这种模式就是这样,没办法。此外,针对表S_ACT_EM上index range scan在设置为all_rows模式后被推前,这个是无论如何都是应该的,大家看看这个SQL语句就明白了,只是在first_rows_10模式下,CBO发生了错误评估而已,这一点,也许也是影响性能的重要因素之一。

    5)由此可见,all_rows_X模式下,尤其是x比较低时,复杂的SQL语句就要小心了,也许,这个模式更适用于oltp业务,而不是olap业务。

个人之见,仅供参考。

注:本文素材来自崔华老师所著SQL优化一书。

 

以上是关于一个典型的多表参与连接的复杂SQL调优(SQL TUNING)引发的思考的主要内容,如果未能解决你的问题,请参考以下文章

性能调优复杂 SQL 连接

Orancle的SQL语句的多表查询和组函数

SQL数据库的多表查询

数据库SQL的多表查询

SQL怎么连接查询2个表?

MySQL千万级多表关联SQL语句调优