作者：樑開權，叩丁狼教育高階講師，原創文章，未經同意不得隨意轉載

1、MySQL主從複製的原理。

（1）、主庫必須開啟二進位制日誌
（2）、當有增刪改的語句時，會記錄到主庫的binlog中
（3）、主庫通過IO執行緒把binlog裡面的內容傳給從庫的relay binlog（中繼日誌）（這是msyql複製是非同步複製的原因）
（4）、從庫的sql執行緒負責讀取它的relay log裡的資訊並應用到資料庫中

2、Seconds_Behind_Master的原理。

表示sql執行緒和io執行緒之間的時間差
具體的計算：從庫伺服器當前的時間戳與二進位制日誌中的事件的時間戳相對比得到的，所以只有在執行事件時才能報告延遲。
不足：
一些錯誤（例如主備的max_allowed_packet不匹配，或者網路不穩定）可能中斷複製，由於主從複製是非同步操作，Seconds_Behind_Master可能顯示為0

3、主從延遲的主要原因有哪些？

（1）、慢SQL語句過多
（2）、從庫的硬體比主庫差
（3）、同一個主庫下有過多的從庫
（4）、網路延遲
（5）、表分割槽過多
（還有一些原因，歡迎補充）

4、MySQL常見儲存引擎及各自特點。

（1）、InnoDB
支援事務、行級鎖、支援外來鍵約束，主要面向OLTP的應用，使用next-key locking 的策略來避免幻讀現象的產生.
（2）、MyISAM
不支援事務、表鎖設計、支援全文索引、讀寫互相阻塞、不支援外來鍵約束；主要面向OLAP應用場景；快取池只快取索引檔案，不快取資料檔案
（3）、Memory
將所有資料儲存在RAM中，在需要快速查詢引用和其他類似資料的環境下，可提供極快的訪問。如果資料庫重啟或者奔潰，資料都將丟失。
（4）、TokuDB
支援事務、高壓縮、告訴讀寫、基於稀疏樹索引設計；支援大多數線上修改索引、新增欄位。
（5）、Inforbright/infinidb
列式儲存、高壓縮、單列查詢快

5、innodb_flush_log_at_trx_commit引數0、1和2分別代表什麼？

innodb_flush_log_at_trx_commit引數可以控制將redo log buffer中的更新記錄寫入到日誌檔案以及日誌檔案重新整理到磁碟的操作時機。
0
每秒一次觸發log buffer寫入log file中，並且log file重新整理到磁碟。
（由於程序排程問題，不能保證每秒100%重新整理；如果mysql程序崩潰，可能會丟失1s的事務；效率最高，但最不安全）
1
每次事務提交觸發log buffer寫入log file中，並且log file重新整理到磁碟。
2
每次事務提交，log buffer寫入log file中；每秒log file重新整理到磁碟。
（如果作業系統崩潰或者停電，可能會丟失1s的事務）

6、Mysql中varchar和char的區別

CHAR列的長度固定為建立表時宣告的長度，範圍（0-255）
VARCHAR列的長度不固定，範圍（0-65535）

7、varchar(50)中的50代表的含義、int(20)中20的含義。

varchar(50)中的50代表最多能存放50個字元
int(20)中20的含義表示顯示寬度，跟著zerofill一起才有意義

8、MySQL binlog的幾種日誌錄入格式的涵義、適用場景和在複製中的優劣。

（1）、statement level模式
每一條會修改資料的sql都會記錄到master的binlog中，slave在複製時sql程序會解析成和原來master端執行過的相同的sql再次執行。
適用場景：對主從資料一致性要求不太高，並且很少用到函式、儲存過程、觸發器等場景
優點：bin-log日誌量少
缺點：部分新功能（函式、儲存過程、觸發器）同步會有障礙，比如now()
（2）、row level模式
日誌中會記錄成每一行資料被修改的形式，然後再slave端再對相同的資料進行修改
適用場景：對主從資料一致性要求比較高的場景。
優點：記錄的詳細
缺點：binlog日誌量過大
（3）、mixed模式
MySQL預設採用statement格式進行二進位制日誌檔案的記錄，但是在一些情況下會使用row格式，可能的情況有：
1）、表的儲存引擎為NDB，此時對錶的DML操作都會以ROW格式記錄
2）、使用了UUID(),USER(),CURRENT_USER(),FOUND_ROWS(),ROW_count()等不確定函式時
3）、使用了insert delay語句
4）、使用了使用者定義函式（UDF）
5）、使用了臨時表
適用場景：對主從資料一致性要求不太高，可能會用到函式、儲存過程、觸發器等場景
優缺點介於statement和row模式之間

9、重做日誌和二進位制日誌的區別（至少三點）

（1）涉及儲存引擎不一樣：
binlog記錄的是所有儲存引擎的操作記錄
redo log只記錄innodb儲存引擎的日誌
（2）記錄內容不一樣：
binlog記錄的是關於一個事務的具體操作內容。為邏輯日誌
而redo log記錄的是每個頁更改的物理情況
（3）寫的時間不一樣：
binlog檔案僅在事務提交前進行提交，即只寫磁碟一次
而在事務進行過程中，卻不斷有重做日誌條目被寫入到重做日誌檔案中。

10、Explain執行計劃中要關注哪些要素？

（1）、type:本次查詢表聯接型別，從這裡可以看到本次查詢大概的效率
（2）、key:最終選擇的索引，如果沒有索引的話，本次查詢效率通常很差
（3）、key_len:本次查詢用於結果過濾的索引實際長度
（4）、rows:預計需要掃描的記錄數，預計需要掃描的記錄數越小越好
（5）、extra:額外附加資訊，主要確認是否出現 Using filesort、Using temporary 類似情況