如何让你的 SQL 执行的飞起?

OR 不能瞎用


午饭间的小 C,答应着一起吃饭,却眼不离屏。


我知道准是上午人甲产品经理又来了一个脏活。话说 SQL 程序员本身是个光荣的职业,顷刻间百万数据、百亿金额从指间流过,心都不带咯噔的。在心如止水的 SQL 编码师眼里,金钱跟粪土没区别,非说有什么一样的属性,那都是臭的。却始终被人看做拉数据的,呼来喝去。


算了,似乎吃饭时候说这事儿不好。


小 C 现在已经是 BI Experienced Engineer 了,历练了 500W+ 电商用户的数据仓库项目后,对付日常的报表以及取数的需求,技术上绰绰有余。唯一不足可能就是脸皮薄,跟产品扯皮完全下风。要我说呢,现在的人精多的很,善于保护自己是每个程序员的弱项,包括保护自己的时间与精力。


“C, 还不吃饭啊?”

“L,你快来帮我看看,这段 SQL 效率有问题,人甲说太慢了”

“有这么复杂,我看看”

“就是这段,简单的 Join 拖慢了整个 sp ”


顺着小 C 的手指,总共 8 行的代码每次都要运行 7,8 秒,确实太慢。即使是第二次,第三次运行,时间误差不过 1 秒。那就肯定不是没建索引这种问题了。小 C 熟练的切换到执行计划的截图,她显然已经知道我对付慢查询的三板斧了。“现在的后生可畏啊,老师傅们快被他们榨干了”,当然我是不会这么对着她的面说的。



640?wx_fmt=png


最显著的地方是那么厚厚的一根线


640?wx_fmt=png



UNION ALL 带你飞


一看时间,12:15,饿扁了快。


我这人正常情况下,不发火,情绪还算稳定。但要我饿着肚子跟你磨性子,对不起,我可能真的是属于要跟产品干起来的那种。属猪,爱好吃!所以我也不想跟小 C 细讲为什么了。直接改了 SQL 语句。



640?wx_fmt=png


从 8300 ms (也就是 8 秒)一下跳到 46 ms. 性能提升了近 200 倍。


很多人对 SQL 程序员有种偏见,认为就是 CRUD Girl/Boy. 我不说,也不评论,理解偏差每个人都会有。大火的 Java Pk C#,SQL Pk NoSQL, 文科 Pk 理科,这些无脑的例子还少么,对于这类浅见的认识,除了浪费自己的时间与精力,对自己毫无用处。做 JS 的随便写段 SQL 去 10T 的数据库上跑跑就能找到挫败感了;而写 SQL 的你去写个 UI Chart, 头发掉不少。不信啊,你知道 CPU Time, Elapsed Time 是怎么调出来的啊?术业有专攻,练好自己的本事再说。


三流人才,没本事,但臭脾气!



To Do Or Not To Do 是大问题


代码洁癖要不要?


有些程序员有严重的代码洁癖。看到长段的 SQL 总想着要去动手改一改,看到不按自己喜欢的代码格式写的 SQL 总想着去调调格式。比如强制使用大写来规范数据库语法关键字,用驼峰来命名变量,一行一个字段等等。有时候是好事,有时候也不见得。Union all 和 Or 不就是这样么!


做事,还是要有所取舍。


上面的 SQL 改写后,执行计划变得复杂了。我估计很多人蠢蠢欲动要改掉它。看着眼烦,往往是新手被自己情绪带着走的节奏。


640?wx_fmt=png



本故事纯属虚构,如有雷同纯属巧合 


猜你喜欢:


听说你们的数据库并发 2 万就跪了?

动态 SQL 你还敢用?

SQL 人要敢于说不


640?wx_fmt=jpeg


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

dbLenis

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值