MySQL深刻淺出（二）：索引的設計原則、SQL優化、MySQL日誌、備份與恢復

上一篇：MySQL深刻淺出（一）：SQL基礎、數據類型、運算符

1、 索引的設計原則

1. 查看字段散列度/離散度：select count(distinct col_name),... from table_name，如性別的離散度比較低不適合作索引
2. InnoDB表的普通索引都會保存主鍵的值，因此主鍵要儘量選擇比較短的數據類型，能夠有效地減小索引的磁盤佔用，提升索引的緩存效果。

    插件式存儲引擎是MySQL最重要的特性之一
    優化表碎片：OPTIMIZE TABLE table_name
    存儲過程和函數是事先通過編譯並存儲在數據庫中的一段SQL語句的集合，能夠減小開發人員不少工做；

事務控制和鎖定語句

    lock tables 鎖定用於當前線程的表。若是表被其餘線程鎖定，則當前線程會等待，直到能夠獲取全部鎖定爲止

  

    事務控制：

start transaction/begin
...
commit/rollback

    當前分佈式事務只支持InnoDB存儲引擎。

    Tips:若是想更清楚地瞭解SQL的執行過程：show profile for query

2、SQL優化

2.1 經過show status 命令瞭解各類SQL執行頻率

show [session|global] status

session：當前鏈接
global：自數據庫上次啓動至今

show status like 'Com_%';

    

    經過以上幾個參數，能夠了解到當前數據庫的應用是插入更新爲主仍是以查詢操做爲主。

2.2 經過explain分析低效SQL的執行計劃

    

    各屬性含義：
    id: 查詢的序列號
    select_type: 查詢的類型，主要是區別普通查詢和聯合查詢、子查詢之類的複雜查詢

• SIMPLE：查詢中不包含子查詢或者UNION
• 查詢中若包含任何複雜的子部分，最外層查詢則被標記爲：PRIMARY
• 在SELECT或WHERE列表中包含了子查詢，該子查詢被標記爲：SUBQUERY
• 在FROM列表中包含的子查詢被標記爲：DERIVED（衍生）
• 若第二個SELECT出如今UNION以後，則被標記爲UNION；若UNION包含在 FROM子句的子查中，外層SELECT將被標記爲：DERIVED
• 從UNION表獲取結果的SELECT被標記爲：UNION RESULT

    table: 輸出的行所引用的表
    type: 訪問類型
    

    從左至右，性能由差到好

1. ALL: 掃描全表
2. index: 掃描所有索引樹
3. range: 掃描部分索引，索引範圍掃描，對索引的掃描開始於某一點，返回匹配值域的行，常見於between、<、>等的查詢
4. ref: 使用非惟一索引或非惟一索引前綴進行的查找
5. eq_ref：惟一性索引掃描，對於每一個索引鍵，表中只有一條記錄與之匹配。常見於主鍵或惟一索引掃描
6. const, system: 單表中最多有一個匹配行，查詢起來很是迅速，例如根據主鍵或惟一索引查詢。system是const類型的特例，當查詢的表只有一行的狀況下， 使用system。
7. NULL: 不用訪問表或者索引，直接就能獲得結果，如select 1 from test where 1

    possible_keys: 表示查詢時可能使用的索引。若是是空的，沒有相關的索引。這時要提升性能，可經過檢驗WHERE子句，看是否引用某些字段，或者檢查字段不是適合索引

    key: 顯示MySQL實際決定使用的索引。若是沒有索引被選擇，是NULL

    key_len: 使用到索引字段的長度

    注：key_len顯示的值爲索引字段的最大可能長度，並不是實際使用長度，即key_len是根據表定義計算而得，不是經過表內檢索出的。

    ref: 顯示哪一個字段或常數與key一塊兒被使用

    rows: 這個數表示mysql要遍歷多少數據才能找到，表示MySQL根據表統計信息及索引選用狀況，估算的找到所需的記錄所須要讀取的行數，在innodb上多是不許確的

    Extra: 執行狀況的說明和描述。包含不適合在其餘列中顯示但十分重要的額外信息。

1. Using index：表示使用索引，若是隻有 Using index，說明他沒有查詢到數據表，只用索引表就完成了這個查詢，這個叫覆蓋索引。若是同時出現Using where，表明使用索引來查找讀取記錄， 也是能夠用到索引的，可是須要查詢到數據表。
2. Using where：表示條件查詢，若是不讀取表的全部數據，或不是僅僅經過索引就能夠獲取全部須要的數據，則會出現 Using where。若是type列是ALL或index，而沒有出現該信息，則你有可能在執行錯誤的查詢：返回全部數據。
3. Using filesort：不是「使用文件索引」的含義！filesort是MySQL所實現的一種排序策略，一般在使用到排序語句ORDER BY的時候，會出現該信息。
4. Using temporary：表示爲了獲得結果，使用了臨時表，這一般是出如今多表聯合查詢，結果排序的場合。

2.3 索引問題

    索引是在MySQL的存儲引擎層實現的，而不是在服務器層實現的，因此每種存儲引擎的索引都不必定徹底相同。

    最左匹配原則能夠算是MySQL中B-Tree索引使用的首要原則

    以%開頭的like查詢不可以利用B-Tree索引，執行計劃中key的值爲NULL表示沒有使用索引

    數據類型出現隱式轉換的時候也不會使用索引，特別是當列類型是字符串，那麼必定記得在where條件中把字符常量用引號引發來。如select * from test where last_name='1';

    用or分割的條件，若是or前的條件中的列有索引，然後面的列沒有索引，那麼涉及的索引都不會被用到。由於or後面的條件列沒有索引，那麼後面的查詢確定走全表掃描，在存在全表掃描的狀況下，就沒有必要多一次索引掃描增長I/O訪問，一次全表掃描過濾條件就足夠了。

    查看索引使用狀況：

show [global] status like 'Handler_read%';
 
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Handler_read_first    | 2225  |
| Handler_read_key      | 2486  |
| Handler_read_last     | 0     |
| Handler_read_next     | 78    |
| Handler_read_prev     | 0     |
| Handler_read_rnd      | 2     |
| Handler_read_rnd_next | 47857 |
+-----------------------+-------+

    Handler_read_rnd_next的值高則意味着查詢運行低效，而且應該創建索引補救

    InnoDB類型的表是按照主鍵的順序保存的。
    優化insert語句，若是同時從同一個客戶端插入多行，應儘可能使用多個值表的insert語句，這種方式大大縮減客戶端與數據庫之間的鏈接、關閉等消耗

    優化嵌套查詢：有些狀況下，子查詢能夠被更有效的鏈接（join）代替。鏈接（join）之因此更有效率一些，是由於MySQL不須要在內存中建立臨時表來完成這個邏輯上須要兩個步驟的查詢工做

    優化分頁查詢：消息私信MySQL的limit用法和分頁查詢的性能分析及優化

    InnoDB採用redo log機制來保證事務更新的一致性和持久性

3、MySQL日誌

    在MySQL中有4種不一樣的日誌：錯誤日誌、二進制日誌（BINLOG）、查詢日誌和慢查詢日誌

• mysqlbinlog(日誌管理工具)
• mysqldump(數據導出工具)

3.1 二進制日誌

    二進制日誌記錄了全部的DDL和DML語句，可是不包括數據查詢語句。語句以「事件」的形式保存，它描述了數據的更改過程。此日誌對於災難時的數據恢復起着極其重要的做用。
    因爲二進制日誌以二進制存儲，不能直接讀取，須要用mysqlbinlog工具來查看：mysqlbinlog log-file

4、備份與恢復

    備份要在系統負載較小的時間進行

4.1 邏輯備份和恢復

    備份數據庫test:

mysqldump -uroot -p test > test.sql

    備份數據庫test下的表emp:

mysqldump -uroot -p test emp > emp.sql

    恢復：

mysqldump -uroot -p daname < bakfile

    物理備份：冷備份（停掉數據庫）和熱備份（本質是將要備份的表加鎖）