關於SQL開發規範中的那些誤區！

在實際SQL應用場景中，SQL最佳化很重要，之前有開發者因一個SQL難題被困惑了5天5夜。最後只能找相關專家解決。那麼，如何最佳化SQL， 有哪些方案可以選擇呢?

1、假設一個表同時有兩個索引，idx_int_c1,idx_varchar_c2在:select*from tb where c1=100000 or c2='zhishutang';這個SQL會用到哪個索引?為什麼?

大多數人都會選擇第一個。其實選擇任何一個索引都是錯誤的。大多數企業都會基於CPU，或者說基於成本最佳化。如果按照c1來算，兩個條件同時滿足，它會選擇靠前的;如果只能滿足一個，它會選擇最優的，這是成本最佳化最核心的原理，選擇最適合的狀態。從成本最佳化的角度，應該誰處於空閒，誰就去工作。不一定是運程最快，最重要的是合適。

2、還有，如何判斷SQL執行的時候，哪個最好。

比如上圖中：一個是不加limit,一個是加了limit，如果整體時間都在1S以下，哪一個最好?很多人會說，肯定是加了limit的好。但是，如何證明?

在最佳化之前，在終端上做下狀態重新整理，分別執行這兩個SQL。然後對比資料。比如第一個SQL之前是1個Key,後來讀了17次。而第二個SQL是從1個Key開始讀了4次。這說明第二個動作少，效果更好。所以，判斷一個SQL好還是壞，是可以量化的。

3、另外是關於delete最佳化的問題。之前，有一個人求助，說一個delete語句執行了2個多小時了，還沒執行完，能不能把這個SQL回滾?答案是不能，如果你直接回滾，會死得更慘。

評價一個SQL能不能回滾，或者說進行到什麼程度?大家都有同樣一個感受是，有一個進度條該多好。但事實是，SQL沒有。有很多人很暴力，遇到這種情況會直接重啟。不重啟會卡死，因為它阻塞了後面的任務，SQL不能查詢。

筆者建議不要暴力重啟，先執行一個“show engine innodb status\G”語句，這樣能看到執行時間。如果沒有執行狀態，就可以Kill掉。

(本文根據資深資料庫專家 吳炳錫 老師 線上課堂內容整理。)