一、 致使慢 SQL 的緣由mysql
在遇到慢 SQL 狀況時,不能簡單的把緣由歸結爲 SQL 編寫問題(雖然這是最多見的因素),實際上致使慢 SQL 有不少因素,甚至包括硬件和 mysql 自己的 bug。根據出現的機率從大到小,羅列以下:sql
SQL編寫問題數據庫
鎖服務器
業務實例相互幹繞對 IO/CPU 資源爭用併發
服務器硬件函數
MYSQL BUG工具
針對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()。
在平常開發工做中,咱們能夠作一些工做達到預防慢 SQL 問題,好比在上線前預先用診斷工具對 SQL 進行分析。經常使用的工具備:
mysqldumpslow
mysql profile
mysql explain
具體使用及分析方法在此就不贅述,網上有豐富的資源能夠參考。
提出這個問題顯然主要是針對剛開始工做的年輕同行們……實際上誤操做和程序 bug 致使數據誤刪或者混亂的問題並不是少見,可是剛入行的開發工做者會比較緊張。一個成熟的企業每每會有完善的數據管理規範和較豐富的數據恢復方案(初創公司除外),會進行數據備份和數據容災。
當你發現誤操做或程序 bug 致使線上數據被誤刪或誤改動時,必定不能慌亂,應及時與 DBA 聯繫,第一時間進行數據恢復(嚴重時直接中止服務),儘量減小影響和損失。對於重要數據(如資金)的操做,在開發時必定要反覆進行測試,確保沒有問題後再上線。