β

限定两小时!一次由权限类型归集引发的紧急SQL优化

36大数据 28 阅读

大数据

作者:黄浩

一、案例

这一天,I项目组的一个迭代版本需要上线,这是一个大版本,需要全员现场支撑,并要求上线后三天待命。

1 、不速之客,来者不善

而就在上线前两天,即9月24日下午4点钟,一直以来波澜不惊有惊无险的性能优化,突然被放了一个大招,某个页面被测出了严重的性能问题,大致情况如下:

测试人员在性能环境做了一轮压力测试,数据增加了5倍,其它功能点基本上达到了性能指标,而该功能则需要6s,整整超出了3s。

瞬间,大家都紧张起来了。

由于0926版本是公司级的大版本,不光是I项目组发布版本,H公司的其它系统也会同时发布版本。为了控制风险,会提前两天冻结代码。按照“不带BUG上生产”的原则,我们必须要在版本冻结截至时(9月24日18点准)“毙”掉这个性能BUG单。 而距离18点还不到2个小时。

PM在得知这一消息后也高度关注,责令优化小组全力攻关,要人给人。这样,组长、模块SE及我就组成了临时应急小组。大家全力以赴,很快就把问题梳理出来了,大致如下:

当时,组长当机立断,一方面要求对这些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的业务功能。

于是我跟SE表达了我诉求,SE立即安排了开发责任人跟我对接。在与开发人员长达20分钟的沟通后,终于理清了这个8个SQL的逻辑与关系,如下:

这是个重大发现:6s多的时间中,查询责任人花费了5s,这是要重点照顾的对象。我继续向开发责任人了解更多的信息:

“查询责任人SQL,SQL单独运行是3s,为何页面却花费了5s?”“因为页面需要对SQL返回的数据集进行判断。”“都做了哪些逻辑处理?”
作者:36大数据
关注大数据和大数据应用_大数据第一科技网

发表评论