現(xiàn)在mysql相關(guān)的面試，面試官總會問一些相關(guān)的技術(shù)問題。在這里，因此就總結(jié)一些常見的mysql面試題，都是自己平時工作的總結(jié)以及經(jīng)驗。希望大家看完，能避開”面試坑”。

1、MySQL主從復(fù)制的原理。
（1）、主庫必須開啟二進(jìn)制日志（2）、當(dāng)有增刪改的語句時，會記錄到主庫的binlog中（3）、主庫通過IO線程把binlog里面的內(nèi)容傳給從庫的relay binlog（中繼日志）（這是msyql復(fù)制是異步復(fù)制的原因）（4）、從庫的sql線程負(fù)責(zé)讀取它的relay log里的信息并應(yīng)用到數(shù)據(jù)庫中
2、Seconds_Behind_Master的原理。
表示sql線程和io線程之間的時間差具體的計算：從庫服務(wù)器當(dāng)前的時間戳與二進(jìn)制日志中的事件的時間戳相對比得到的，所以只有在執(zhí)行事件時才能報告延遲。不足：一些錯誤（例如主備的max_allowed_packet不匹配，或者網(wǎng)絡(luò)不穩(wěn)定）可能中斷復(fù)制，由于主從復(fù)制是異步操作，Seconds_Behind_Master可能顯示為0
3、主從延遲的主要原因有哪些？
（1）、慢SQL語句過多（2）、從庫的硬件比主庫差（3）、同一個主庫下有過多的從庫（4）、網(wǎng)絡(luò)延遲（5）、表分區(qū)過多（還有一些原因，歡迎補(bǔ)充）
4、MySQL常見存儲引擎及各自特點。
（1）、InnoDB支持事務(wù)、行級鎖、支持外鍵約束，主要面向OLTP的應(yīng)用，使用next-key locking 的策略來避免幻讀現(xiàn)象的產(chǎn)生.（2）、MyISAM不支持事務(wù)、表鎖設(shè)計、支持全文索引、讀寫互相阻塞、不支持外鍵約束；主要面向OLAP應(yīng)用場景；緩存池只緩存索引文件，不緩存數(shù)據(jù)文件（3）、Memory將所有數(shù)據(jù)保存在RAM中，在需要快速查找引用和其他類似數(shù)據(jù)的環(huán)境下，可提供極快的訪問。如果數(shù)據(jù)庫重啟或者奔潰，數(shù)據(jù)都將丟失。（4）、TokuDB支持事務(wù)、高壓縮、告訴讀寫、基于稀疏樹索引設(shè)計；支持大多數(shù)在線修改索引、添加字段。（5）、Inforbright/infinidb列式存儲、高壓縮、單列查詢快
5、innodb_flush_log_at_trx_commit參數(shù)0、1和2分別代表什么？
innodb_flush_log_at_trx_commit參數(shù)可以控制將redo log buffer中的更新記錄寫入到日志文件以及日志文件刷新到磁盤的操作時機(jī)。0每秒一次觸發(fā)log buffer寫入log file中，并且log file刷新到磁盤。（由于進(jìn)程調(diào)度問題，不能保證每秒100%刷新；如果mysql進(jìn)程崩潰，可能會丟失1s的事務(wù)；效率最高，但最不安全）1每次事務(wù)提交觸發(fā)log buffer寫入log file中，并且log file刷新到磁盤。2每次事務(wù)提交，log buffer寫入log file中；每秒log file刷新到磁盤。（如果操作系統(tǒng)崩潰或者停電，可能會丟失1s的事務(wù)）
6、Mysql中varchar和char的區(qū)別
CHAR列的長度固定為創(chuàng)建表時聲明的長度，范圍（0-255）VARCHAR列的長度不固定，范圍（0-65535）
7、varchar(50)中的50代表的含義、int(20)中20的含義。
varchar(50)中的50代表最多能存放50個字符int(20)中20的含義表示顯示寬度，跟著zerofill一起才有意義
8、MySQL binlog的幾種日志錄入格式的涵義、適用場景和在復(fù)制中的優(yōu)劣。
（1）、statement level模式每一條會修改數(shù)據(jù)的sql都會記錄到master的binlog中，slave在復(fù)制時sql進(jìn)程會解析成和原來master端執(zhí)行過的相同的sql再次執(zhí)行。適用場景：對主從數(shù)據(jù)一致性要求不太高，并且很少用到函數(shù)、存儲過程、觸發(fā)器等場景優(yōu)點：bin-log日志量少缺點：部分新功能（函數(shù)、存儲過程、觸發(fā)器）同步會有障礙，比如now()（2）、row level模式日志中會記錄成每一行數(shù)據(jù)被修改的形式，然后再slave端再對相同的數(shù)據(jù)進(jìn)行修改適用場景：對主從數(shù)據(jù)一致性要求比較高的場景。優(yōu)點：記錄的詳細(xì)缺點：binlog日志量過大（3）、mixed模式MySQL默認(rèn)采用statement格式進(jìn)行二進(jìn)制日志文件的記錄，但是在一些情況下會使用row格式，可能的情況有：1）、表的存儲引擎為NDB，此時對表的DML操作都會以ROW格式記錄2）、使用了UUID(),USER(),CURRENT_USER(),FOUND_ROWS(),ROW_count()等不確定函數(shù)時3）、使用了insert delay語句4）、使用了用戶定義函數(shù)（UDF）5）、使用了臨時表適用場景：對主從數(shù)據(jù)一致性要求不太高，可能會用到函數(shù)、存儲過程、觸發(fā)器等場景優(yōu)缺點介于statement和row模式之間
9、重做日志和二進(jìn)制日志的區(qū)別（至少三點）
（1）涉及存儲引擎不一樣：binlog記錄的是所有存儲引擎的操作記錄redo log只記錄innodb存儲引擎的日志（2）記錄內(nèi)容不一樣：binlog記錄的是關(guān)于一個事務(wù)的具體操作內(nèi)容。為邏輯日志而redo log記錄的是每個頁更改的物理情況（3）寫的時間不一樣：binlog文件僅在事務(wù)提交前進(jìn)行提交，即只寫磁盤一次而在事務(wù)進(jìn)行過程中，卻不斷有重做日志條目被寫入到重做日志文件中。
10、Explain執(zhí)行計劃中要關(guān)注哪些要素？
（1）、type:本次查詢表聯(lián)接類型，從這里可以看到本次查詢大概的效率（2）、key:最終選擇的索引，如果沒有索引的話，本次查詢效率通常很差（3）、key_len:本次查詢用于結(jié)果過濾的索引實際長度（4）、rows:預(yù)計需要掃描的記錄數(shù)，預(yù)計需要掃描的記錄數(shù)越小越好（5）、extra:額外附加信息，主要確認(rèn)是否出現(xiàn) Using filesort、Using temporary 類似情況

提到MySQL 相信很多人都不陌生，MySQL 作為目前最流行的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，在很多的應(yīng)聘中，都會頻繁被面試官問及。于是就自己總結(jié)了一些在面試中，經(jīng)常面試官被提及的一些問題，希望能帶給更多人幫助。
接下來就跟著我的步伐來了解一下吧！

1、MySQL主從復(fù)制的原理。
（1）、主庫必須開啟二進(jìn)制日志（2）、當(dāng)有增刪改的語句時，會記錄到主庫的binlog中（3）、主庫通過IO線程把binlog里面的內(nèi)容傳給從庫的relay binlog（中繼日志）（這是msyql復(fù)制是異步復(fù)制的原因）（4）、從庫的sql線程負(fù)責(zé)讀取它的relay log里的信息并應(yīng)用到數(shù)據(jù)庫中
2、Seconds_Behind_Master的原理。
表示sql線程和io線程之間的時間差具體的計算：從庫服務(wù)器當(dāng)前的時間戳與二進(jìn)制日志中的事件的時間戳相對比得到的，所以只有在執(zhí)行事件時才能報告延遲。不足：一些錯誤（例如主備的max_allowed_packet不匹配，或者網(wǎng)絡(luò)不穩(wěn)定）可能中斷復(fù)制，由于主從復(fù)制是異步操作，Seconds_Behind_Master可能顯示為0
3、主從延遲的主要原因有哪些？
（1）、慢SQL語句過多（2）、從庫的硬件比主庫差（3）、同一個主庫下有過多的從庫（4）、網(wǎng)絡(luò)延遲（5）、表分區(qū)過多（還有一些原因，歡迎補(bǔ)充）
4、MySQL常見存儲引擎及各自特點。
（1）、InnoDB支持事務(wù)、行級鎖、支持外鍵約束，主要面向OLTP的應(yīng)用，使用next-key locking 的策略來避免幻讀現(xiàn)象的產(chǎn)生.（2）、MyISAM不支持事務(wù)、表鎖設(shè)計、支持全文索引、讀寫互相阻塞、不支持外鍵約束；主要面向OLAP應(yīng)用場景；緩存池只緩存索引文件，不緩存數(shù)據(jù)文件（3）、Memory將所有數(shù)據(jù)保存在RAM中，在需要快速查找引用和其他類似數(shù)據(jù)的環(huán)境下，可提供極快的訪問。如果數(shù)據(jù)庫重啟或者奔潰，數(shù)據(jù)都將丟失。（4）、TokuDB支持事務(wù)、高壓縮、告訴讀寫、基于稀疏樹索引設(shè)計；支持大多數(shù)在線修改索引、添加字段。（5）、Inforbright/infinidb列式存儲、高壓縮、單列查詢快
5、innodb_flush_log_at_trx_commit參數(shù)0、1和2分別代表什么？
innodb_flush_log_at_trx_commit參數(shù)可以控制將redo log buffer中的更新記錄寫入到日志文件以及日志文件刷新到磁盤的操作時機(jī)。0每秒一次觸發(fā)log buffer寫入log file中，并且log file刷新到磁盤。（由于進(jìn)程調(diào)度問題，不能保證每秒100%刷新；如果mysql進(jìn)程崩潰，可能會丟失1s的事務(wù)；效率最高，但最不安全）1每次事務(wù)提交觸發(fā)log buffer寫入log file中，并且log file刷新到磁盤。2每次事務(wù)提交，log buffer寫入log file中；每秒log file刷新到磁盤。（如果操作系統(tǒng)崩潰或者停電，可能會丟失1s的事務(wù)）
6、Mysql中varchar和char的區(qū)別
CHAR列的長度固定為創(chuàng)建表時聲明的長度，范圍（0-255）VARCHAR列的長度不固定，范圍（0-65535）
7、varchar(50)中的50代表的含義、int(20)中20的含義。
varchar(50)中的50代表最多能存放50個字符int(20)中20的含義表示顯示寬度，跟著zerofill一起才有意義
8、MySQL binlog的幾種日志錄入格式的涵義、適用場景和在復(fù)制中的優(yōu)劣。
（1）、statement level模式每一條會修改數(shù)據(jù)的sql都會記錄到master的binlog中，slave在復(fù)制時sql進(jìn)程會解析成和原來master端執(zhí)行過的相同的sql再次執(zhí)行。適用場景：對主從數(shù)據(jù)一致性要求不太高，并且很少用到函數(shù)、存儲過程、觸發(fā)器等場景優(yōu)點：bin-log日志量少缺點：部分新功能（函數(shù)、存儲過程、觸發(fā)器）同步會有障礙，比如now()（2）、row level模式日志中會記錄成每一行數(shù)據(jù)被修改的形式，然后再slave端再對相同的數(shù)據(jù)進(jìn)行修改適用場景：對主從數(shù)據(jù)一致性要求比較高的場景。優(yōu)點：記錄的詳細(xì)缺點：binlog日志量過大（3）、mixed模式MySQL默認(rèn)采用statement格式進(jìn)行二進(jìn)制日志文件的記錄，但是在一些情況下會使用row格式，可能的情況有：1）、表的存儲引擎為NDB，此時對表的DML操作都會以ROW格式記錄2）、使用了UUID(),USER(),CURRENT_USER(),FOUND_ROWS(),ROW_count()等不確定函數(shù)時3）、使用了insert delay語句4）、使用了用戶定義函數(shù)（UDF）5）、使用了臨時表適用場景：對主從數(shù)據(jù)一致性要求不太高，可能會用到函數(shù)、存儲過程、觸發(fā)器等場景優(yōu)缺點介于statement和row模式之間
9、重做日志和二進(jìn)制日志的區(qū)別（至少三點）
（1）涉及存儲引擎不一樣：binlog記錄的是所有存儲引擎的操作記錄redo log只記錄innodb存儲引擎的日志（2）記錄內(nèi)容不一樣：binlog記錄的是關(guān)于一個事務(wù)的具體操作內(nèi)容。為邏輯日志而redo log記錄的是每個頁更改的物理情況（3）寫的時間不一樣：binlog文件僅在事務(wù)提交前進(jìn)行提交，即只寫磁盤一次而在事務(wù)進(jìn)行過程中，卻不斷有重做日志條目被寫入到重做日志文件中。
10、Explain執(zhí)行計劃中要關(guān)注哪些要素？
（1）、type:本次查詢表聯(lián)接類型，從這里可以看到本次查詢大概的效率（2）、key:最終選擇的索引，如果沒有索引的話，本次查詢效率通常很差（3）、key_len:本次查詢用于結(jié)果過濾的索引實際長度（4）、rows:預(yù)計需要掃描的記錄數(shù)，預(yù)計需要掃描的記錄數(shù)越小越好（5）、extra:額外附加信息，主要確認(rèn)是否出現(xiàn) Using filesort、Using temporary 類似情況

1、MySQL主從復(fù)制的原理。
（1）、主庫必須開啟二進(jìn)制日志（2）、當(dāng)有增刪改的語句時，會記錄到主庫的binlog中（3）、主庫通過IO線程把binlog里面的內(nèi)容傳給從庫的relay binlog（中繼日志）（這是msyql復(fù)制是異步復(fù)制的原因）（4）、從庫的sql線程負(fù)責(zé)讀取它的relay log里的信息并應(yīng)用到數(shù)據(jù)庫中
2、Seconds_Behind_Master的原理。
表示sql線程和io線程之間的時間差具體的計算：從庫服務(wù)器當(dāng)前的時間戳與二進(jìn)制日志中的事件的時間戳相對比得到的，所以只有在執(zhí)行事件時才能報告延遲。不足：一些錯誤（例如主備的max_allowed_packet不匹配，或者網(wǎng)絡(luò)不穩(wěn)定）可能中斷復(fù)制，由于主從復(fù)制是異步操作，Seconds_Behind_Master可能顯示為0
3、主從延遲的主要原因有哪些？
（1）、慢SQL語句過多（2）、從庫的硬件比主庫差（3）、同一個主庫下有過多的從庫（4）、網(wǎng)絡(luò)延遲（5）、表分區(qū)過多（還有一些原因，歡迎補(bǔ)充）
4、MySQL常見存儲引擎及各自特點。
（1）、InnoDB支持事務(wù)、行級鎖、支持外鍵約束，主要面向OLTP的應(yīng)用，使用next-key locking 的策略來避免幻讀現(xiàn)象的產(chǎn)生.（2）、MyISAM不支持事務(wù)、表鎖設(shè)計、支持全文索引、讀寫互相阻塞、不支持外鍵約束；主要面向OLAP應(yīng)用場景；緩存池只緩存索引文件，不緩存數(shù)據(jù)文件（3）、Memory將所有數(shù)據(jù)保存在RAM中，在需要快速查找引用和其他類似數(shù)據(jù)的環(huán)境下，可提供極快的訪問。如果數(shù)據(jù)庫重啟或者奔潰，數(shù)據(jù)都將丟失。（4）、TokuDB支持事務(wù)、高壓縮、告訴讀寫、基于稀疏樹索引設(shè)計；支持大多數(shù)在線修改索引、添加字段。（5）、Inforbright/infinidb列式存儲、高壓縮、單列查詢快
5、innodb_flush_log_at_trx_commit參數(shù)0、1和2分別代表什么？
innodb_flush_log_at_trx_commit參數(shù)可以控制將redo log buffer中的更新記錄寫入到日志文件以及日志文件刷新到磁盤的操作時機(jī)。0每秒一次觸發(fā)log buffer寫入log file中，并且log file刷新到磁盤。（由于進(jìn)程調(diào)度問題，不能保證每秒100%刷新；如果mysql進(jìn)程崩潰，可能會丟失1s的事務(wù)；效率最高，但最不安全）1每次事務(wù)提交觸發(fā)log buffer寫入log file中，并且log file刷新到磁盤。2每次事務(wù)提交，log buffer寫入log file中；每秒log file刷新到磁盤。（如果操作系統(tǒng)崩潰或者停電，可能會丟失1s的事務(wù)）
6、Mysql中varchar和char的區(qū)別
CHAR列的長度固定為創(chuàng)建表時聲明的長度，范圍（0-255）VARCHAR列的長度不固定，范圍（0-65535）
7、varchar(50)中的50代表的含義、int(20)中20的含義。
varchar(50)中的50代表最多能存放50個字符int(20)中20的含義表示顯示寬度，跟著zerofill一起才有意義
8、MySQL binlog的幾種日志錄入格式的涵義、適用場景和在復(fù)制中的優(yōu)劣。
（1）、statement level模式每一條會修改數(shù)據(jù)的sql都會記錄到master的binlog中，slave在復(fù)制時sql進(jìn)程會解析成和原來master端執(zhí)行過的相同的sql再次執(zhí)行。適用場景：對主從數(shù)據(jù)一致性要求不太高，并且很少用到函數(shù)、存儲過程、觸發(fā)器等場景優(yōu)點：bin-log日志量少缺點：部分新功能（函數(shù)、存儲過程、觸發(fā)器）同步會有障礙，比如now()（2）、row level模式日志中會記錄成每一行數(shù)據(jù)被修改的形式，然后再slave端再對相同的數(shù)據(jù)進(jìn)行修改適用場景：對主從數(shù)據(jù)一致性要求比較高的場景。優(yōu)點：記錄的詳細(xì)缺點：binlog日志量過大（3）、mixed模式MySQL默認(rèn)采用statement格式進(jìn)行二進(jìn)制日志文件的記錄，但是在一些情況下會使用row格式，可能的情況有：1）、表的存儲引擎為NDB，此時對表的DML操作都會以ROW格式記錄2）、使用了UUID(),USER(),CURRENT_USER(),FOUND_ROWS(),ROW_count()等不確定函數(shù)時3）、使用了insert delay語句4）、使用了用戶定義函數(shù)（UDF）5）、使用了臨時表適用場景：對主從數(shù)據(jù)一致性要求不太高，可能會用到函數(shù)、存儲過程、觸發(fā)器等場景優(yōu)缺點介于statement和row模式之間
9、重做日志和二進(jìn)制日志的區(qū)別（至少三點）
（1）涉及存儲引擎不一樣：binlog記錄的是所有存儲引擎的操作記錄redo log只記錄innodb存儲引擎的日志（2）記錄內(nèi)容不一樣：binlog記錄的是關(guān)于一個事務(wù)的具體操作內(nèi)容。為邏輯日志而redo log記錄的是每個頁更改的物理情況（3）寫的時間不一樣：binlog文件僅在事務(wù)提交前進(jìn)行提交，即只寫磁盤一次而在事務(wù)進(jìn)行過程中，卻不斷有重做日志條目被寫入到重做日志文件中。
10、Explain執(zhí)行計劃中要關(guān)注哪些要素？
（1）、type:本次查詢表聯(lián)接類型，從這里可以看到本次查詢大概的效率（2）、key:最終選擇的索引，如果沒有索引的話，本次查詢效率通常很差（3）、key_len:本次查詢用于結(jié)果過濾的索引實際長度（4）、rows:預(yù)計需要掃描的記錄數(shù)，預(yù)計需要掃描的記錄數(shù)越小越好（5）、extra:額外附加信息，主要確認(rèn)是否出現(xiàn) Using filesort、Using temporary 類似情況

以上問題，都是面試中經(jīng)常會被問到的！其實要想把這些問題具體的原理講清楚，那每一個問題都可以啰嗦出一篇文章來！所以，在這里我沒有進(jìn)行深入的探討。只是把工作中自己的一些經(jīng)驗分享了出來，有可能你會覺得，就是這樣做的，不這么做可能就會掉坑里去。當(dāng)然，我給的回答可能并非標(biāo)準(zhǔn)答案，畢竟是自己的一些經(jīng)驗總結(jié)，希望能對大家的面試有一些幫助！