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 改寫后，執行計劃變得復雜了。我估計很多人蠢蠢欲動要改掉它。看著眼煩，往往是新手被自己情緒帶著走的節奏。

本故事純屬虛構，如有雷同純屬巧合

總結

以上是生活随笔為你收集整理的sql执行有时候快有时候慢_如何让你的 SQL 执行的飞起？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。