《收穫，不止SQL優化》前言閱讀小記

前不久買了一本書《收穫，不止SQL優化》，那是由於通過金融服務那塊的時候，看到有這麼一本書，看着封面和目錄仍是酷酷的，回去我也買了一本，發現是以Oracle數據庫來說的，不少沒法下手呀，其實我當時覺得是一本講sql語言的，而後已經放下這本書好久了，看不下去呀。

可是這個前言講的故事仍是挺有趣的「前言與意識，從優化方法到全書脈絡，傳說：一入IT深似海，今後菜鳥淚成河」。

下面簡單梳理一下書中前言中講的故事：

故事一：某天小王被告知系統的某個菜單訪問很是慢，因而他負責介入優化，經過觀察發現某條sql的執行計劃訪問某張表的時候沒有走索引，以爲應該表應該加一個索引，他花了1個小時發現這個問題很是興奮，因而動手開始創建索引，花了幾分鐘創建索引，隨後發現sql走索引了，而且真的快了不少。

故事二：小王正在明明得意的時候不久，就被運營告知雖然這個菜單變快了，可是剛纔持續幾分鐘時間出現訪問該菜單一直報錯的狀況，隨後正常。？？？爲何程序會出錯，怎麼又恢復了？

故事三：當天下午小王又接到電話，被告知菜單訪問又變慢了。小王吃了一驚。因而登陸檢查，還真的變慢了，sql執行計劃是正常走索引的，小王很鬱悶。正在他素手無策的時候，小王接到電話，該菜單又變快了。暈，但是他什麼都沒有幹。這是怎麼回事？當晚，小王展轉反側，無意睡眠。次日。小王又接到電.....他奔潰了。

故事四：小王崩潰後沒法正常工做，而後領導把這個問題給了別的同事處理，小王又滿血復活地投入戰鬥。幾天後下網迎來一個新任務，項目組中有一條sql很慢，但願能夠優化一下。小王看了一眼以爲歪瓜裂棗的寫的很不舒服，因而挽起袖子決定重寫SQL，改改改。小王對新寫完的sql一運行，發現比以前的sql慢不少，可憐的小王又崩潰了。

故事五：在小王再度崩潰以前，公司的sql優化大師正好通過，他分析了以後，建議將sql語句設計的某標的外鍵加上索引。後來你們發現真的變快了，他告訴小王，優化前可經過各類手段觀察sql設計的表結構，索引等，看有沒有不合理的地方，急於動手改造太盲目了，沒有抓木矛盾的要點，並且改代碼要測試預發，上線。小王頻頻點頭

故事六：老王成長了，一週以後，小王又面對一條sql優化，此次他不動手改了，嘗試加了索引，又嘗試了調整表結構，結果效果都不明顯。而後呢，崩潰了.......好在sql優化大師又出現了，此次沒有修改表結構，而是和開發人員進行了半小時交談，而後對sql進行重寫，而後sql就變得飛快了。小王傻眼了，不是說盡可能不着急動手改sql嗎？悲催呀,怎麼改纔是對的？更讓小王悲催的是，優化後的sql並不複雜，那是怎麼變快的？

一入SQL深似海，今後菜鳥淚成河！！！

書中後面繼續分析了這裏的每個故事出現的緣由，太長了，我稍微摘錄一點。小王的仍是掌握了預約的sql優化基礎技能的，可是由於經驗少，同時也缺少由經驗轉換成作事的方法論。

小王接到電話就開始優化了，難道不該該多問一句這是一直存在的問題，仍是今天忽然出現的。若是事忽然出現的，那要看昨天晚上發佈了什麼，由於此次發佈引發的故障可能性比較大，因而目標就清晰了。而若是是常常出現的故障，那應該同事已經處理過，那麼獲取他們以前的分析成果和經驗，或者收集以前的日誌與如今做比較，難道沒有幫助嗎？

故事三中，加了索引變快又變慢，系統複雜了，可能性是不少的。有可能也是這樣一種狀況，此時整個系統或者依賴的系統都很是慢，根本不僅是這個菜單慢。 求助者沒有提出其餘模塊慢或許她平時只用這個菜單模塊。還有數據庫所在的主機耗盡了cpu，內存等資源。忽快忽慢的，也多是有坑人程序在。

故事二的幾分鐘失敗多是建索引的時候，鎖了全表，致使更新數據失敗。因此在業務高峯作DDL操做，嚴重影響了生產。

故事四吧小王動手改改改，效果差差差。解決問題要有目的性，不能沒找到問題就動手。你以爲sql寫的很差，實際上應該看慢在什麼地方。

故事五，優化大師只是加了索引就變快了，有時候不須要改寫sql就能夠，改寫的代價比較高，須要測試，預發，上線等。

故事六是小王沒有生搬硬套了，他根本沒有找到問題的本質。須要更具業務需求，砍掉多餘的邏輯。

做者寫了作事要有方法論，先總體後局部，解決問題要注重效率，先儘可能考慮不應改寫的優化，再考慮改寫的優化。不改寫的優化靠的是體系結構知識的沉澱，而改寫則要考慮邏輯等價改寫和業務改寫兩大思路，其中業務改寫是sql優化的最高境界。