OR 不能瞎用
午饭间的小 C,答应着一起吃饭,却眼不离屏。
我知道准是上午人甲产品经理又来了一个脏活。话说 SQL 程序员本身是个光荣的职业,顷刻间百万数据、百亿金额从指间流过,心都不带咯噔的。在心如止水的 SQL 编码师眼里,金钱跟粪土没区别,非说有什么一样的属性,那都是臭的。却始终被人看做拉数据的,呼来喝去。
算了,似乎吃饭时候说这事儿不好。
小 C 现在已经是 BI Experienced Engineer 了,历练了 500W+ 电商用户的数据仓库项目后,对付日常的报表以及取数的需求,技术上绰绰有余。唯一不足可能就是脸皮薄,跟产品扯皮完全下风。要我说呢,现在的人精多的很,善于保护自己是每个程序员的弱项,包括保护自己的时间与精力。
“C, 还不吃饭啊?”
“L,你快来帮我看看,这段 SQL 效率有问题,人甲说太慢了”
“有这么复杂,我看看”
“就是这段,简单的 Join 拖慢了整个 sp ”
顺着小 C 的手指,总共 8 行的代码每次都要运行 7,8 秒,确实太慢。即使是第二次,第三次运行,时间误差不过 1 秒。那就肯定不是没建索引这种问题了。小 C 熟练的切换到执行计划的截图,她显然已经知道我对付慢查询的三板斧了。“现在的后生可畏啊,老师傅们快被他们榨干了”,当然我是不会这么对着她的面说的。
最显著的地方是那么厚厚的一根线
UNION ALL 带你飞
一看时间,12:15,饿扁了快。
我这人正常情况下,不发火,情绪还算稳定。但要我饿着肚子跟你磨性子,对不起,我可能真的是属于要跟产品干起来的那种。属猪,爱好吃!所以我也不想跟小 C 细讲为什么了。直接改了 SQL 语句。
从 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 改写后,执行计划变得复杂了。我估计很多人蠢蠢欲动要改掉它。看着眼烦,往往是新手被自己情绪带着走的节奏。
本故事纯属虚构,如有雷同纯属巧合
猜你喜欢: