vlambda博客
学习文章列表

人人都会写SQL，但某些人的SQL，执行起来就是慢。要让运营等你20分钟出报表，今年你的KPI可就难了。

可，谁没傻过呢？

我刚毕业写代码那会，写了几个SQL脚本跑报表，就是硬着让厂办的党委书记等了15分钟左右，才跑出数据来。到现在每每想到当时的窘境，我都要打湿半条白衬衫。

自此，我养成了一个习惯，穿衬衫，我在里面一定加条小背心，就像尼古拉斯凯奇在《空中监狱》里穿的那条一样。有作用么？嗯，真香！

我想要说的是，谁的SQL都不是一开始就像迅雷般那么快。那么，你怎么知道自己的SQL快不快呢？写好的时候，跑跑很快，2年，3年过去了，还快吗？1000个人用着，挺快的，那5000人一起用呢？

谁管它？写完业务逻辑就已经累得剩下半条命了，有那心思不如K一把王者！

如果你一直秉承这个观念，相信5年后，你还会来再读我这篇文章的。

SQL是真简单，7天入门真不是瞎BB.但真要把7天学完SQL的朋友，放到BAT做做报表，你很难不心虚。谁处理过10T以上的数据量，应该明白我说的这意思。

既然我们的SQL不能一直快速地执行，那我们有什么办法呢？

有的朋友会说，这个交给DBA，有的朋友会说，让组里的高级工程师去处理。

其实，并不是每个组里都有DBA,或高级工程师。在小厂里面，DBA这个职位可能都不存在。DBA的价位放在那里，小厂哪里请得起？

大部分的毕业生，挑工作的时候，面临一个头疼的选择，究竟是去BAT,TMD这样的大厂，还是选择小而美的创业型公司？大厂资源多，大神也多，动动嘴皮子就能学到很多，小厂可能连吃饭都成问题，发了这个月工资，还有没有下个月都很难保证。综合下来，大家都跑大厂去了，一下子给大厂提高了N倍的竞争。

而小厂会有什么好处呢？没有大神，没有咖啡，没有心动的女孩。只有写不完的代码，fix不断的bug,还有一大堆杂事，比如调个SQL的优。

如果你处在小厂的位置，那么给SQL调优的时候，就可以用到我这个方法了。让你的SQL牢牢的跑在火速的轨道上，保证不出大的异常。

过年时，跟我老爹一起喝两杯的时候，老爹总要询问工作上的事情。看我这么颓，他老人家也急。不过他没明着教育我，让我快点成长。他只是喝着小酒，佯装小醉，迷迷糊糊的给我分析，他工地上的那班农民工，谁谁谁会偷懒，但说话漂亮，让人舒服；谁谁谁又会打小报告，5毛钱都算的清清楚楚；谁谁谁做事情勤奋又好学，难题都要找他解决，就是人比较直，话比较难听。

那时的我只是觉得人老了，比较爱唠叨，怎么大老爷们爱打听这些事儿，没事找事么。现在想想，挺为自己着急的。

好，回到正题。

当时的我也不懂什么巡检脚本，也还没关注盖国强，冯大辉这些大神，硬写了一个执行记录表，简单的5,6个字段，记录存储过程每次执行的开始时间，结束时间，用时等。

正巧Excel 2007刚出来，有个叫做Pivot Table的东西整天被微软拿出来夸，顺着刚学的BIDW(Businss Intelligence & Data warehouse)技巧，做了一个 Excel 的性能检测工具，如下图：

第一张图，是监控了每个存储过程的运行状态，按照从慢到快来排序每次的执行时间。这样我们就大概可以知道，哪个存储过程或者脚本出现了性能问题。

而第二张图，针对性能出现问题的存储过程，做进一步的解释，是什么时间出了问题，是经常出现问题，还是偶尔。以及最近一段时间，它的执行效率，据此判断性能问题是偶发性还是已经到了要更改的时刻。

作为SQL人，每天对自己的代码有个全局的了解，不正是对自己代码负责的最好表现嘛？虽然这个方法比较老套，但缺少资源的情况下，靠自己做一个闭环，也未尝不是件为职业加分的事情。