编者按
一、案例
这一天,I项目组的一个迭代版本须要上线,这是一个大年夜版本,须要全员现场支撑,并请求上线后三天待命。
1、不速之客,来者不善
而就在上线前两天,即9月24日下昼4点钟,一向以来波澜不惊有惊无险的机能优化,忽然被放了一个大年夜招,某个页面被测出了严重的机能问题,大年夜致情况如下:
测试人员在机能情况做了一轮压力测试,数据增长了5倍,其它功能点根本上达到了机能指标,而该功能则须要6s,整整超出了3s。
“真正的优化,最大年夜的空寄┞氛样在于大年夜底层的模型设计,以及写出规范和优良的SQL,是以应当在项目上设备专职的DBA………..”
刹时,大年夜家都重要起来了。
因为0926版本是公司级的大年夜版本,不然则I项目组宣布版本,H公司的其它体系也会同时宣布版本。为了控制风险,会提前两天冻结代码。按照“不带BUG上临盆”的原则,我们必须要在版本冻结截至时(9月24日18点准)“毙”掉履┞封个机能BUG单。而距离18点还不到2个小时。
PM在得知这一消息后也高度存眷,责令优化小组全力攻关,要人给人。如许,组长、模块SE及我就构成了临时应急小组。大年夜家尽心尽力,很快就把问题梳理出来了,大年夜致如下:
该页面加载共须要履行8条SQL,单条SQL的履行都不长,都在机能指标范围内,然则加起来跨越了5s;
剩下的2s耗在页面的逻辑处理。
当时,组长应机立断,一方面请求对这些SQL进行优化,优化到2s阁下;另一方面将页面的处理耗时降到1s内,如许就能确保3s的机能请求。
SQL优化义务天然落在我的头上,8个SQL的代码如下:
2、兵分两路,把鸡蛋放在两个篮子里
看着这8个不长不短整整洁齐的SQL,我的第一反竽暌功是:一个页面加载怎么会存在8个SQL语句?这8个SQL之间又有着什么样的接洽关系关系?是否还可以归并成一个?
如不雅做SQL归并的话,就意味着我须要详读这8个SQL,但时光的指针已经指在了17:00,离18:00下班不足一个小时。用中国足球赛事评论员的话说就是“如今留给中国对的时光已经不多了”,已经没有时光让我解读这8个SQL;何况,即便能快速解读,也未必能归并。
那么就要像组长提议的:寻求单个SQL的优化冲破。而8个SQL优化到2秒,也就是说单个SQL平均耗时在0.25秒,这个压力也是异常大年夜的。
我在与组长简短商讨后,为了降低风险,不至于背注一掷,做出了如下决定:兵分两路,由我履行归并筹划,优化小组的DBA负责单个SQL进行优化。
3、本来如斯,不过如斯
按照以往的习惯,我肯定会先本身解读这8个SQL,因为我信赖别人的时光也是时光,能本身解决的尽量不要占用别人的时光。但此次不可了,因为时光不许可了,我必须要快速懂得8个SQL的营业功能。
《SQL机能优化与批驳》是黄浩师长教师的系列新作,他将大年夜过往在项目技巧支撑中碰着的诸多案例入手,细化到每一条问题SQL的内涵病因,反思每一个案例的背后沉思。今天跟大年夜家分享的是第四个案例:获取义务人,须要回想前情的同窗请戳这里:案例一、案例二、案例三。
于是我跟SE表达了我诉求,SE急速安排了开辟义务人跟我对接。在与开辟人员长达20分钟的沟通后,终于理清了这个8个SQL的逻辑与关系,如下:
萌芽义务列表,共3个SQL,共耗时1s,主SQL,包含了count和详情
萌芽义务人:4个SQL,共耗时3s,然则页面自上而下共耗时5s
萌芽收集节点:1个SQL共耗时0.5s
这是个重大年夜发明:6s多的时光中,萌芽义务人花费了5s,这是要重点照顾的对象。我持续向开辟义务人懂得更多的信息:
“萌芽义务人SQL,SQL零丁运行是3s,为何页面却花费了5s?”
听完后,我豁然开朗,逻辑流程图如下:
“因为页面须要对SQL返回的数据集进行断定。”
“都做了哪些逻辑处理?”
“这四个SQL分别对应四类权限,权限的最小单位是实体DU,在义务列表中获取的DU,先用第一个SQL断定哪些DU具有第一类权限,比如有100个,那么传入第二个SQL的DU就是90个DU,由词攀类推,知道完成了4类权限的判。”
4、有的放矢,一蹴而就
四个SQL对应四种权限,如不雅我们把TASK_ID比作学生,把USER_ID比作班级,而将权限比作是学生选修的四门学科。那么“权限义务人萌芽”就改变成萌芽当前班级每个学生最高分的科目。
该筹划存在两个机能瓶颈:
- 将权限数据大年夜DB传输到JAVA办事器是要必定的成本开销的;
- 当JAVA拿到权限数据数据时,须要轮回一一归集权限类型,这个过程也会带来必定的机能问题。
如不雅我们能将权限类别归集放在DB中完成,即DB只须要返回当前用户的DUID所属权限类别即可,那么至少省却了4次数据传输的时耗。当然,权限类型归集无论是放在DB照样JAVA,都是须要成本开销,就看谁的算法更具优势。事实上Oracle则供给了完全的解决筹划,即竽暌姑rank over来实现优先级排序。
此不时光已经到了17:20,我来不及多想,立马对萌芽义务人的4个SQL进行归并改写,归并后的SQL如下:
推荐阅读
对MySQL 技巧成长比较懂得的同伙肯定知道解决高并发的问题常用的手段就是“拆锁和移除锁”。 MySQL 8.0版本应用多个更细粒度的mutex代替buffer pool mutex这把大年夜锁。本文大>>>详细阅读
本文标题:限定两小时!一次由权限类型归集引发的紧急SQL优化案例
地址:http://www.17bianji.com/lsqh/38369.html
1/2 1