>[success] ### 第九難 高性能MySQL簡介 >[info] ### 從架構層上做優化，可以做分布式 >[info] ### 數據表設計層 * 選擇合適的存儲引擎（innoDB，MyISAM會使用回行操作） * 合適的列類型（占用的存儲空間盡可能的小），如性別這些可以用tinnyint存儲，能固定長度的盡量用固定長度char（因為有時候不可避免的需要用到文件排序filesort，使用變長類型varchar的話會直接使用該列的最大長度，導致資源不必要的消耗） * 盡量使用符合三范式的表設計結構（原子性：列是最小單元不可分割，唯一性：可以由主鍵字段來唯一的確定一條記錄，依賴性：將一張表拆分為兩張由主鍵字段關聯的的表（比如學生表，班級表）） * 根據業務對數據庫進行分割：垂直分割（將不同的表拆分到不同的服務器上，如微服務），水平分割（如以學校id取模進行分表） * 將使用頻率不多的字段存放到另外一張表中 * 補充說明: [char與varchar的區別分析](http://www.jb51.net/article/23575.htm)(myisam 存儲引擎 建議使用固定長度，數據列代替可變長度的數據列, innodb 存儲引擎 建意使用varchar 類型 ) >[info] ### 索引設計層（索引是一種空間換時間的策略, 在換取時間的同時也有一定的開銷, 若索引失當, 可能開銷大于收益） * 對于連接查詢所需要的連接的字段，使用索引 * 對于經常出現where條件后的字段與用于排序的字段，使用索引 * 使用復合索引（在排序的時候，如果排序字段跟where條件后的字段分開建立索引，會導致mysql使用where條件后的索引查詢出結果，然后再在此結果上使用filesort進行排序；還有where條件后多個單列索引最終會使用到的也只是一個，這個時候按照規則建立復合索引就能加大檢索的效率） * 對于一些列類型比較大的字段，可以使用索引的前綴原則，對其固定長度前綴建立索引(長度較長字段建立索引, 索引文件會比較大, 占用較多磁盤空間的同時, 檢索索引的時候對io資源消耗也較大)，或者使用一種偽造哈希索引，額外增加一個字段， 作為該大字段的索引，在插入數據的時候，先對需要進行建立偽哈希索引的索引用哈希函數計算出哈希值，再一起存入數據庫中。 * 對于修改的比較頻繁的字段，盡可能避免建立索引（避免索引樹的頁分裂） * 避免冗余索引，比如已經有了一個索引a,現在又建立了一個a,b 那么a索引就是冗余索引，因為a,b 與 a在已a為條件搜索時索引起到的功能是一樣的，如果在a字段插入數據的時候，就得同時維護兩個索引，造成了不必要的開銷 >[info] ### SQL應用層的優化 * 查詢了大量的數據，如limit的查詢，舉個例子，一張有著三百多萬條數據的用戶表，跟一張和它一樣多的用戶詳情表，現有一個需求，需要查詢出每頁20條用戶，有以下一句sql select a.username,a.userid,b.face,b.mood,b.date,b.... from user as a inner join user_info as b using userid limit 2500000,10; 再沒有帶where限制條件的情況下，該語句執行時間達到了30多秒，如果要帶上一些排序，那將會產生一個巨大的臨時表，將會占用太多的資源 * 使用合理的索引覆蓋，分頁的情況下使用延遲關聯 * 不要連接太多的表（mysql連接查詢優化機制是根據每個表的行數，索引來制定查詢計劃，如果表數量達到8個，那么將會有8 * 7 * 6 * 5 * 4 * 3 * 2 * 1種方式選擇，那么mysql制定的查詢計劃可能就沒那么準確） * 關注執行計劃，盡可能的使用到索引，避免掃描過多的行數，避免產生臨時表，filesort