从此爱上SQL Monitor！记一次反常理的鉴权查询优化

CTO练习营 | 12月3-5日，深圳，是时刻成为优良的技巧治理者了

经由过程反复注释加测试，诡异的现象出现了：

好气象，坏SQL

金秋10月，如同阳春三月般，是一个令人难以忘记与等待的季候。而在这个好梦的季候了，我拿到了一个不怎么令人愉悦的SQL。

按照膳绫擎的流程与算法，就很轻易懂得上述那组数字了。同样的，也明白了为何权限设备匀毁的时刻机能越差，设备越多的时刻机能反而越好。

优化小组的测试MM给我发了封关于机能问题的邮件，在邮件琅绫擎，问题描述是如许的：权限设备匀毁，机能越差，当设备了全部（2万）du的权限时，只须要2s，当只设备了120个DU的权限时，须要半小时以上。

看到这个描述，我心里也咯噔了一下：这是违背了常理的。一般来说，只有越大年夜越慢，如今反而是越小越慢。

按照习惯，我照样想先见识见识这个一反常理的SQL，看看到底是何方神圣。我找开辟人员拿到了SQL，打开代码如下：

大年夜体量上看，这个SQL并不大年夜，总共才130多行。这在I项目组中是比较常见的。而大年夜体型上看，似乎不怎么调和：尾巴太大年夜。在WHERE前提子句，拖着5个EXISTS前提，并且都是OR的关系。这已经很不平常了，会不会就是问题中描述的问题地点呢？

我向开辟人员咨询了这5个EXISTS子萌芽的营业功能，获得的信息是：

1、这5个EXISTS子萌芽的功能是鉴权，即权限辨别；

2、不合EXISTS子萌芽代表不合类型的权限集合；

3、鉴权的对象粒度是DU，即每个EXISTS子萌芽与EXISTS子萌芽的接洽关系字段都是LINE.DU_ID

大年夜SQL自身看，找不到明显的“马脚”，我就测验测验着看看履行筹划，在SQL DEV中按下了F5，显示的履行筹划如下：

履行筹划比较长，我们可以只看exists部分，发明根本上都是索引扫描，cost值也异常低，也就是说履行筹划中也看不出问题。那问题到底出在哪里呢?

笨办法，好效不雅

当时就在想：是单个exists慢？照样5个放在一路慢呢？

为了弄清跋扈这个原因，我就逐个注释掉落EXISTS，并不雅察注释后的机能。固然这个办法有些愚蠢，甚至很多人都不齿于该办法，但有些时刻这确切也是定位问题的有效的手段和门路。

1、5个exists前提零丁感化时，没有机能问题；

2、第一个和第三个exists前提结合感化时，也没有机能问题；

3、第三个、第四个和第五个exists前提结合感化时，机能问题就凸显了。

由此看来，问题越来越复杂了。Oracle在履行这条SQL时到底产生了什么呢？千头万绪理还乱，束手无策想不通。万般无奈之下，只能祭出必杀神器：SQL Monitor。

神器不出，莫与争锋

不见兔子不撒鹰

在拿到SQL Monitor的结不雅后，似乎一切都晴明起来了，SQL Monitor的截图如下（因为当时的原始数据损掉，以下仅给出模仿数据）：

因为已经明白了是在exists子萌芽存在机能问题，我就重点存眷了EXISTS的Monitor信息，欲望能大年夜中发明有价值的信息与启发。

在比较了5个exists的履行筹划后，“履行次数”引起了我的留意：5个EXISTS的履行次数及实际施数竟然不一样！

（1）这组数字之间也有着奇妙的接洽：第一个的履行次数为20000，及正好是总的DU数量，第二个的履行次数等于第一个的履行次数-第一个实际施数，即知足如下算法：

（2）第一个和第二个exists的实际返回行数的和是120，恰好是邮件中说起的权限设备数量；而第三个19880加上120正好等于2万，又恰好是全部DU数。难道这一切仅仅是偶合罢了？照样另有隐情呢？

个中f(n)为第n个exists的履行次数，e(n)为第n个exists的实际返回行数，并且n>1。

基于以上两点信息，我豁然开朗仗然大年夜悟，个中启事了然于胸。我们可以大年夜致揣摸出Oracle的履行道理如下图所示：

为了更好地舆解，这里可以举两个极端的例子。如不雅有没有设备任何权限，那么每个DU都须要遍历5个exists子萌芽，就意味着总共要履行10万次（2万DU，每个DU履行5次）exists子萌芽。反过来，如不雅我们将2万DU都设备了权限，并且是第一类权限（即第一个exists的权限），那么每个DU只须要履行第一个exists，后面4个exists子萌芽不须要履行。是以只须要履行2万次。2万次与10万次的差别（别的还须要推敲不合exists之间本身机能也是有差别的），对机能的影响照样异常明显的。

拨开云雾不等于立见天日

覆盖在诡异机能问题上的云雾终于被揭开了，但我却涓滴没有欣喜之感。问题的原因固然已经“大年夜白于世界”，但解决筹划让我束手无策。

一开端，我测验测验着基于现有SQL经由过程SQL Hint干涉履行筹划，然则机能毫无起色。我又测验测验着改写这个SQL，将OR EXISTS子萌芽改写成LEFT JOIN，机能问题却变本加厉。我还测验测验着创建基于该SQL的特定索引，仍然无济于事。

1/2 1 2 下一页尾页

　　推荐阅读

　　程序员如何做到年薪超过60万？

2. 金融巨擘 CTO练习营 | 12月3-5日，深圳，是时刻成为优良的技巧治理者了附一张阿里的级别对应薪资不仅限于 BAT，其他盈利才能强的互联网大年夜公司，高层技巧员工达到60万以上年薪是比较>>>详细阅读

本文标题：从此爱上SQL Monitor！记一次反常理的鉴权查询优化

地址：http://www.17bianji.com/lsqh/39321.html

1/2 1