回归本源,方得美满
多次测验测验无不雅,在万般无奈之下,我又回到了问题的来源基本。
一、案例
这个SQL,在本场景中,除了第一个exists子萌芽履行了100次,第二个exists子萌芽履行了20次,其它四个exists子萌芽履行的19880*4次都是没有意义的。既然没有意义,那是否可以省略掉落呢?我很为本身这个天马行空不着边际的设法主意振奋。
因为就如开端测试时,将后面庞个exists注释掉落后,机能异常好。也就是说如不雅能成功避开无用的EXISTS子萌芽,也是可以达到机能优化之目标的。
但很显然,Oracle在履行SQL前,是无法辨认哪些EXISTS子萌芽是必须履行的?哪些EXISTS子萌芽是无须履行的?难道本身的┞封个设法主意就如许夭折了吗?
我持续着本身天马行空的设法主意。
既然Oracle在履行SQL的时刻未卜先知,那么我们在写这个SQL时,是否可以先卜上一卦,如不雅某类权限没有设备,就不在SQL中拼凑对应的EXISTS子萌芽。如许,本案例SQL就会只剩下两个EXISTS子萌芽了。机能也天然能获得知足。
以上设法主意仅仅是我一厢宁愿的幻想主义,其在实际应用中是否可行照样未知之数:这个SQL在Java代码中是固定的┞氛样拼凑的?某类权限是否设备的断定是否复杂?是否也会存在机能问题?如斯等等,毛骨悚然。但就如小马过后,不去测验测验又怎么知道是否真实可行呢?
于是,我带着这个不太正经的筹划与开辟人员沟通。开辟人员的表示让人喜忧闷半。喜的是,他并不否决这个筹划,如不雅真的能解决机能问题,他也是乐于接收该筹划;忧的是,这段5个exists子萌芽的SQL并不是他控制的。本来该案例的SQL地点的体系募块是义务治理,而5个EXISTS子萌芽是鉴权功能,附属于权限模块。这些EXISTS子萌芽都是由权限模块来开辟和保护的。用义务治理模块开辟人员的话说就是“这5个EXISTS是经由过程调用权限模块的办事获取的,如不雅权限模块给我们3个EXISTS,我们就拼凑三个EXISTS子萌芽,如不雅他们不给我们EXISTS,我就不拼凑EXISTS子萌芽。”
于是,我带着这个筹划又去“游说”权限模块的开辟人员。
【编辑推荐】
- 关于数据库萌芽优化的思虑
- 一个20秒SQL慢萌芽优化的经历与处理筹划
- MySQL SQL慢萌芽优化经历与处理筹划
- Mysql分页&接洽关系萌芽优化
- Oracle萌芽优化之is null和is not null优化
当我找到权限模块的开辟人员时,我们并没有直接拖出我的筹划,而是把机能问题表述了一边。意想不到的是,这位开辟人员很是淡定,似乎这一切早就知道了;却也满脸的无奈,他说:“这个机能问题照样裸露出来了,没有办法,当初权限这块的设置就是这么复杂,我们也不想如斯复杂。”
见机会成熟,我就把我的筹划全盘托出。没想到,这位开辟人员听完后,两眼大年夜放异彩,一脸精神抖擞,说到:“这很好,异常不错,我如今就按照你的筹划改写。这不单单是你的┞封个SQL有问题,其它所有涉及到鉴权的SQL都邑有这个问题。”
接下来,一切都水到渠成了。
二、心得
大年夜此爱上SQL Monitor
该案例的优化过程甚为曲折,几近山穷水尽前功尽弃。在为几个exists弄得焦头烂额束手无策之际,幸得SQL Monitor之助,方能拨开云雾,终见彼苍。大年夜explain plan中,我们能得知Oracle优化器的意图,而经由过程SQL Monitor,我们能获取到运行时的很多信息,比如本案例中涉及到的“实际返回行数”、“履行次数”。这一些对我们定位问题及原因分析异常有效。
感激SQL Monitor!
头疼医头,脚疼医脚
该案例对应的BUG单很快被封闭,但作为优化筹划的设计者,我异常清跋扈这个筹划的局限性和马脚。没错,针对该案例,“不见兔子不撒鹰”式的筹划切实其实能药参预除,但也仅仅是实用于该案例的营业场景。该筹划还存在一个致命的缺点:跟着设备的权限类型越多,其半数个SQL的机能影响越大年夜。我们将权限设备对SQL的机能影响设为P,则P的计算公式为:
由公式可见,当N=0时,是没有影响的,而当N=5时,影响是最大年夜的。
过后,我将这种隐患口头上与组长交换过,但组长也是无奈:“我也卖力研究过I项目标权限机制,发明存在必定的不合理的处所,要不然也不至于写出如斯复杂的鉴权语句。然则,今朝来看,弗成能将权限机制推倒重来。先就如许子吧。”
推荐阅读
2. 金融巨擘 CTO练习营 | 12月3-5日,深圳,是时刻成为优良的技巧治理者了 附一张阿里的级别对应薪资不仅限于 BAT,其他盈利才能强的互联网大年夜公司,高层技巧员工达到60万以上年薪是比较>>>详细阅读
本文标题:从此爱上SQL Monitor!记一次反常理的鉴权查询优化
地址:http://www.17bianji.com/lsqh/39321.html
1/2 1