慢 SQL 問題經驗總結
1、 導致慢 SQL 的原因
在遇到慢 SQL 情況時，不能簡單的把原因歸結為 SQL 編寫問題(雖然這是最常見的因素)，實際上導致慢 SQL 有很多因素，甚至包括硬體和 mysql 本身的 bug。根據出現的概率從大到小，羅列如下：
-
SQL編寫問題
-
鎖
-
業務例項相互幹繞對 IO/CPU 資源爭用
-
伺服器硬體
-
MYSQL BUG
2、 由 SQL 編寫導致的慢 SQL 優化
針對SQL編寫導致的慢 SQL，優化起來還是相對比較方便的。正如上一節提到的正確的使用索引能加快查詢速度，那麼我們在編寫 SQL 時就需要注意與索引相關的規則：
-
欄位型別轉換導致不用索引，如字串型別的不用引號，數字型別的用引號等，這有可能會用不到索引導致全表掃描；
-
mysql 不支援函式轉換，所以欄位前面不能加函式，否則這將用不到索引；
-
不要在欄位前面加減運算；
-
字串比較長的可以考慮索引一部份減少索引檔案大小，提高寫入效率；
-
like % 在前面用不到索引；
-
根據聯合索引的第二個及以後的欄位單獨查詢用不到索引；
-
不要使用 select *；
-
排序請儘量使用升序 ;
-
or 的查詢儘量用 union 代替 （Innodb）；
-
複合索引高選擇性的欄位排在前面；
-
order by / group by 欄位包括在索引當中減少排序，效率會更高。
除了上述索引使用規則外，SQL 編寫時還需要特別注意一下幾點：
-
儘量規避大事務的 SQL，大事務的 SQL 會影響資料庫的併發效能及主從同步；
-
分頁語句 limit 的問題；
-
刪除表所有記錄請用 truncate，不要用 delete；
-
不讓 mysql 幹多餘的事情，如計算；
-
輸寫 SQL 帶欄位，以防止後面表變更帶來的問題，效能也是比較優的 ( 涉及到資料字典解析，請自行查詢資料)；
-
在 Innodb上用 select count(*)，因為 Innodb 會儲存統計資訊；
-
慎用 Oder by rand()。
3、分析診斷工具
在日常開發工作中，我們可以做一些工作達到預防慢 SQL 問題，比如在上線前預先用診斷工具對 SQL 進行分析。常用的工具有：
-
mysqldumpslow
-
mysql profile
-
mysql explain
具體使用及分析方法在此就不贅述，網上有豐富的資源可以參考。
4、誤操作、程式 bug 時怎麼辦，解決方案
提出這個問題顯然主要是針對剛開始工作的年輕同行們……實際上誤操作和程式 bug 導致資料誤刪或者混亂的問題並非少見，但是剛入行的開發工作者會比較緊張。一個成熟的企業往往會有完善的資料管理規範和較豐富的資料恢復方案（初創公司除外），會進行資料備份和資料容災。
當你發現誤操作或程式 bug 導致線上資料被誤刪或誤改動時，一定不能慌亂，應及時與 DBA 聯絡，第一時間進行資料恢復（嚴重時直接停止服務），儘可能減少影響和損失。對於重要資料（如資金）的操作，在開發時一定要反覆進行測試，確保沒有問題後再上線。