最佳化的極致

今天有人讓我幫忙看一個系統，檢查一下。因為這個系統暫時無人專職維護。我託人拿到後臺日誌，我看到有個系統的SQL是排名靠前的TOP-SQL，每天執行6000多次，每次12秒。把他找出來一看就是全表。從技術的角度，我們當然可以告訴他，應該加一個過濾條件。然後找到開發，告訴他你看我給你這樣的改進建議。開發拿著這個意見回去說評估一下。

     下午評估結果出來了，說理論上這樣改可以。不過他們查下來這個SQL不應該執行。因為這個不用了，很久以前有個場景：相關資料推送到微信公眾號和移動app，推送是一個定時任務（定時是10秒）完成的。後來APP，停用了。 但是 僅停用了呼叫app的推送方法， 未停用 定時任務，導致查詢方法一直在執行。所以打算停止這個定時任務。

   這樣做本身沒有問題。其實最佳化的極致就是不做。我這裡說的不做，不是不做最佳化。而是將待最佳化的SQL直接下線。SQL可以從10分鐘最佳化到1毫秒，但是有什麼比最佳化到0秒更快的嗎？

   另外我展開一下反思，這個功能如果不下線，看著原來的設計。10秒一次定時，結果他執行一次12秒。根本執行不完。所以感覺即使不下線這個都沒法正常使用。也恰好是這個沒人用，才沒被發現。這種場景我回想起我公安時候，開發做了一個功能，半小時檢查一下裝置狀態。結果開發做出來的結果是半小時執行一次，一次執行不止半小時。結果永遠出不了結果。後來我給他做了一個儲存過程5秒出結果，演示給他後，我說按照我這樣來寫你的程式。開發說，我還寫什麼程式啊。我直接調你的儲存過程出結果吧。

   這裡又引申出一個話題，儲存過程。很多開發喜歡寫儲存過程，也有很多開發不喜歡儲存過程。 喜歡的理由是快速實現功能，不喜歡的理由是不好除錯，不好管理，效能低。我本人對儲存過程不是喜歡也不是討厭。不過要說明的是儲存過程是可以除錯的、也很好管理、更加不存在效能低下一說。我們平時見到的儲存過程一般如果很慢的都是寫的有問題，寫的又多又長。這其實是本身開發寫的不好，寫的好的是沒有任何問題的。比如我寫儲存過程，一般不超過10行，超過10行的絕對是設計或者思路有問題。基本就是要錯的節奏，那是不好管理了。但是如果5行就解決問題，我不信管理不好。

    有人說Oracle重，MySQL輕量。其實我也看到過有人在MySQL上10表關聯ERP（這絕對是有問題的），我也看到過在Oracle上簡明扼要的簡單SQL。所以資料庫沒有輕重之分，只有用的對不對。看你怎麼樣。

    張無忌用木劍打贏了倚天劍，你能說倚天劍不行嗎？我又要說一句老話了，一般TB基本的企業，需求合理，SQL設計和實現的好點，要什麼hadoop？