MySQL在大數據、高併發場景下的SQL語句優化和"最佳實踐"。

本文主要針對中小型應用或網站，重點探討平常程序開發中SQL語句的優化問題，所謂「大數據」、「高併發」僅針對中小型應用而言，專業的數據庫運維大神請無視。如下實踐爲我的在實際開發工做中，針對相對「大數據」和相對「高併發」場景的一些應對策略，部分措施並無通過嚴格的對比測試和原理分析，若有錯漏歡迎各類批評指教。

減小查詢的影響結果集，避免出現全表掃描。

影響結果集是SQL優化的核心。影響結果集不是查詢返回的記錄數，而是查詢所掃描的結果數。經過Explain或Desc分析SQL，rows列的值即爲影響結果集（還能夠經過慢查詢日誌的Rows_examined後面的數字獲得）。

如下是我經常使用的一些SQL優化策略：

1. 去掉沒必要要的查詢和搜索。其實在項目的實際應用中，不少查詢條件是無關緊要的，能從源頭上避免的多餘功能儘可能砍掉，這是最簡單粗暴的解決方案。

2. 合理使用索引和複合索引。建索引是SQL優化中最有效的手段。查找、刪除、更新以及排序時經常使用的字段能夠適當創建索引。不過要注意，單條查詢不能同時使用多個索引，只能使用一個索引。查詢條件較多時，可使用多個字段合併的複合索引。切記，使用複合索引時，查詢條件的字段順序須要與複合索引的字段順序保持一致。

3. 謹慎使用not in等可能沒法使用索引的條件。索引也不是何時均可以發揮做用的，當出現"not in"，"!="，"like '%xx%'"，"is null"等條件時，索引是無效的。使用這些條件的時候，請放到能有效使用索引的條件的右邊。設計表結構時，我的建議儘量用int類型代替varchar類型，int類型部分時候能夠經過大於或小於代替"!="等條件，同時也方便知足一些須要按類型排序的需求，至於可讀性的問題，完善好數據庫設計文檔纔是明智的選擇。同時建議把全部可能的字段設置爲"not null"，並設置默認值，避免在where字句中出現"is null"的判斷。

4. 不要在where子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將沒法正確使用索引。儘量少用MySQL的函數，相似Now()徹底能夠經過程序實現並賦值，部分函數也能夠經過適當的創建冗餘字段來間接替代。

5. 在where條件中使用or，可能致使索引無效。可用 "union all" 或者 "union" （會過濾重複數據，效率比前者低） 代替，或程序上直接分開兩次獲取數據再合併，確保索引的有效利用。

6. 不使用select * ，倒不是能提升查詢效率，主要是減小輸出的數據量，提升傳輸速度。

7. 避免類型轉換，這裏所說的「類型轉換」是指where子句中出現字段的類型和傳入的參數類型不一致的時候發生的類型轉換。

8. 分頁查詢的優化。頁數比較多的狀況下，如limit 10000,10 影響的結果集是10010行，查詢速度會比較慢。推薦的解決方案是：先只查詢主鍵select id from table where .. order by .. limit 10000,10（搜索條件和排序請創建索引），再經過主鍵去獲取數據。

9. 統計相關的查詢。影響結果集每每巨大，且部分SQL語句自己已經難以優化。所以，應避免在業務高峯期執行統計相關的查詢，或者僅在從庫中執行統計查詢。部分統計數據，能夠經過冗餘的數據結構保存，同時建議把數據先保存在內存、緩存中（如redis），再按必定策略寫入數據庫。

不使用任何連表查詢，經過分庫和分表實現負載均衡。

隨着數據量的增長，連表操做每每會致使影響結果集大增，從SQL優化的層面已經解決不了問題了。

此時，分庫和分表是解決數據庫性能壓力的最優選擇（具體分庫和分表的方案一般結合實際業務的應用場景來肯定，此處略過）。這裏重點談，如何更好的實現或者過渡到分庫、分表的分佈式數據庫架構。

核心點就是必須先去除數據表之間的關聯，即不用外鍵，不使用任何連表查詢。爲了確保不進行連表操做，在設計數據庫表結構的時候，就須要設計適度冗餘的字段來達到不連表的目的。

對於一些操做日誌、支付記錄等，設計一些記錄用戶信息的字段，我的認爲其實不能算冗餘，畢竟用戶信息每每會更改，可是這種相似操做日誌的表確實是須要記錄用戶操做時的信息，而且不須要在用戶更新信息時同步更新。

實際開發中，爲了實現不進行連表而冗餘的字段，每每是須要在原表更新數據的時候同步更新冗餘字段的數據的，若是應用層沒有對數據表操做作合理封裝，這每每是個棘手的問題，也不方便維護。

固然，如今主流的應用框架，通常採用orm的方式處理數據表，因此問題不大。相反，不連表事實上還能夠提升開發效率，好比經過用戶ID獲取用戶姓名操做，若是不連表就能夠確保各個業務模塊都經過一樣的方式去獲取用戶姓名，調用同一個封裝好的方法，這樣，就能很方便的統一在應用層加入緩存機制或添加統一的業務邏輯。

同時若是要對用戶表進行分庫分表，經過應用層程序就能夠簡單平滑的實現。

使用Innodb。

關於Innodb和Myisam對比，我就很少說了。Myisam的表級鎖是致命問題，考慮到MySQL已經默認使用Innodb做爲數據庫引擎，我的建議大部分狀況能夠直接使用Innodb，其餘引擎這裏就不詳細討論了。

使用緩存。

1) 儘量在程序上實現經常使用數據的緩存，目前主流的應用框架應該都能快速實現緩存的需求。若是在程序上沒有實現數據緩存，開啓數據庫的query cache也是緩解數據庫壓力的方式之一，若是確認使用，記得定時清理碎片flush query cache。

服務器相關優化

MySQL服務配置以及分佈式架構的實現，請根據實際應用場景和業務需求定製，非本文重點，不作深刻探討。