sql語句的效能達不到你的要求，執行的效率讓你忍無可忍，一般會是下面幾種情況。
1.網速不給力，不穩定。
2.伺服器記憶體不夠，或者sql被分配的記憶體不夠。
3.sql語句設計不合理
4.沒有相應的索引，索引不合理
5.沒有有效的索引檢視
6.表資料過大沒有有效的分割槽設計
7.資料庫設計太2，存在大量的資料冗餘
8.索引列上缺少相應的統計資訊，或者統計資訊過期。
select查詢藝術
1.保證不查詢多餘的列與行。
（1）盡量避免select * 的存在，使用具體的列代替 * ，避免多餘的列；
（2）使用where限定具體要查詢的資料，避免多餘的行；
（3）使用top，distinct關鍵字減少多餘重複的行。
2.慎用distinct關鍵字。
（1）distinct在查詢乙個字段或者很少欄位的情況下使用，會避免重複資料的出現，給查詢帶來優化效果。
但是查詢字段很多的情況下使用，則會打打降低查詢效率。
（2）帶distinct語句cpu時間和占用時間都高於不帶distinct的語句。原因是當查詢很多欄位時，如果使用distinct，資料庫引擎就會對資料進行比較，過濾掉
重複資料，然而這個比較，過濾的過程則會毫不客氣的占用系統資源，cpu時間。
3.慎用union關鍵字
此關鍵字主要功能是把各個查詢語句的結果集合合併到乙個結果集中返回給你。
用法：<
select 語句1>
union
<
select 語句2>
union
<
select 語句3>
...
滿足union的語句必須滿足：1.列數相同。2.對應列數的資料型別要保持相容。
執行過程：
依次執行select語句-- >>合併結果集 -->> 對結果集進行排序，過濾重覆記錄。
如果不對結果集排序過濾，顯然效率是比union高的，那麼不排序過濾的關鍵字有嗎？
答：是有的，他是union all，使用union all能對union進行一定的優化。
4.連線查詢的優化
首先你要弄明白你想要的資料是什麼樣子的，然後再做出決定使用哪一種連線，這很重要。
各種連線的取值大小為：
（1）內連線結果集大小取決於左右表滿足條件的數量。
（2）左連線取決與左表大小，右相反。
（3）完全連線和交叉連線取決與左右兩個表的資料總數量。
由此可見減少連線表的資料數量可以提高效率。
優化修改刪除語句
如果你同時修改或刪除過多資料，會造成cpu利用率過高從而影響別人對資料庫的訪問。
如果你刪除或修改過多資料，採用單一迴圈操作，那麼會是效率很低，也就是操作時間過程會很漫長。
這樣該怎麼做呢？
這種的辦法就是，分批運算元據。
delete product where id <1000
delete product where id >=
1000
and id <
2000
delete product where id >=
2000
and id <
3000
當然這樣的優化方式不一定是最優的選擇，這要根據你系統的訪問熱度來定奪，關鍵你要明白什麼樣的語句是什麼樣的效果。
總結： 優化，最重要的是在於你平時設計語句，資料庫的習慣，方式。如果你平時不在意，彙總到一塊再做優化，你就需要耐心的分析，然後分析的過程就是看你的悟性，需求，知識水平啦。
參考：
SQL 語句優化 OR 語句優化案例
從上海來到溫州，看了前幾天監控的sql語句和資料變化，發現有一條語句的io次數很大，達到了150萬次io，而兩個表的資料也就不到20萬，為何有如此多的io次數，下面是執行語句 select ws.nodeid,wi.laststepid,wi.curstepid from workflowinfo ...
sql語句的優化
1 in 操作符 用in寫出來的sql的優點是比較容易寫及清晰易懂，這比較適合現代軟體開發的風格。但是用in的sql效能總是比較低的，從oracle執行的步驟來分析用in的sql與不用in的sql有以下區別 oracle試圖將其轉換成多個表的連線，如果轉換不成功則先執行in裡面的子查詢，再查詢外層的...
SQL語句的優化
通過使用者反饋獲取存在效能問題的sql 通過慢查日誌獲取存在效能問題的sql 實時獲取存在效能問題的sql mysqldumpslow pt query digest pt query digest explain h 127.0.0.1,u root,p p ssword slow mysql.l...