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 改写后，执行计划变得复杂了。我估计很多人蠢蠢欲动要改掉它。看着眼烦，往往是新手被自己情绪带着走的节奏。

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