常見的MySQL面試題有哪些

這篇文章主要介紹“常見的MySQL面試題有哪些”，在日常操作中，相信很多人在常見的MySQL面試題有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”常見的MySQL面試題有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

1：你們公司數據庫有備份的吧？

答：有的，因為單點故障的情況不可避免，所以我們公司有主從。面試官：那你知道主備、主從、主主有什么區別？

主備就是：主機和備機。

備機是不干活的，也就是不對外提供服務，只是默默地在同步主機的數據，然后等著某一天主機掛了之后，它取而代之！

至于切換的話主要有兩種方式：

人工切換，得知主機掛了之后手動把備機切成主機，缺點就是慢。

利用 keepalived 或者自己寫個腳本來作監控，然后自動切換。

主從就是主機和從機。

從機和備機的區別在于，它是對外提供服務的，一般而言主從就是讀寫分離，寫請求指派到主機，讀請求指派到從機。

主主就是兩個都是主機

一般情況下都不會有主主的架構。

當同時有兩個寫請求達到分別打到兩個主庫同一張表的時候，則會同時創建一條記錄，這條記錄的 ID 是一樣的，這樣數據同步之后其中有一條就會被覆蓋了，這會出問題的。

2：為什么要讀寫分離啊？

答：讀寫分離就是讀操作和寫操作從以前的一臺服務器上剝離開來，將主庫壓力分擔一些到從庫。

本質上是因為訪問量太大，主庫的壓力過大，單機數據庫無法支撐并發讀寫。

然后一般而言讀的次數遠高于寫，因此將讀操作分發到從庫上，這就是常見的讀寫分離。

讀寫分離還有個操作就是主庫不建查詢的索引，從庫建查詢的索引。

因為索引是需要維護的，比如你插入一條數據，不僅要在聚簇索引上面插入，對應的二級索引也得插入，修改也是一樣的。

所以將讀操作分到從庫了之后，可以在主庫把查詢要用的索引刪了，減少寫操作對主庫的影響。

3：你們讀寫分離是用中間件的還是代碼封裝的？

答：代碼封裝。

講白了就是代碼層面抽出一個中間層，由中間層來實現讀寫分離和數據庫連接。

就是搞了個代理類，對外暴露正常的讀寫接口，里面封裝了邏輯，將讀操作指向從庫的數據源，寫操作指向主庫的數據源。

優點：簡單，并且可以根據業務定制化變化，隨心所欲。

缺點：如果數據庫宕機了，發生主從切換了之后，就得修改配置重啟。如果系統是多語言的話，需要為每個語言都實現一個中間層代碼，重復開發。

中間件

一般而言是獨立部署的系統，客戶端與這個中間件的交互是通過 SQL 協議的。

所以在客戶端看來連接的就是一個數據庫，通過 SQL 協議交互也可以屏蔽多語言的差異。

缺點就是整體架構多了一個系統需要維護，并且可能成為性能瓶頸，畢竟交互都需要經過它中轉。

常見的開源數據庫中間件有：官方的MySQL-Proxy、360的Atlas、Mycat 等。

4：MySQL 主從同步機制你知道嗎？

答：主從同步主要依賴的就是 binlog，MySQL 默認是異步復制，具體流程如下：

主庫：

• 接受到提交事務請求

• 更新數據

• 將數據寫到binlog中

• 給客戶端響應

• 推送binlog到從庫中

從庫： 

• 由 I/O 線程將同步過來的 binlog 寫入到 relay log 中。

• 由 SQL 線程從 relay log 重放事件，更新數據

• 給主庫返回響應。

用一句話概括一下：主庫提交事務會寫binlog，會由一個 dump 線程推送給從庫，從庫接受之后會有一個I/O線程將其寫到 relay log 中，慢慢消化，由 SQL 線程來重放更新數據。

異步復制有數據丟失風險，例如數據還未同步到從庫，主庫就給客戶端響應，然后主庫掛了，此時從庫晉升為主庫的話數據是缺失的。

所以有同步復制，主庫需要將 binlog 復制到所有從庫，等所有從庫響應了之后才會給客戶端響應，這樣的話性能很差，一般不會選擇同步復制。

MySQL 5.7 之后搞了個半同步復制，有個參數可以選擇“成功同步幾個從庫就返回響應。”

比如一共有 3 個從庫，我參數配置 1，那么只要有一個從庫響應說復制成功了，主庫就直接返回響應給客戶端，不會等待其他兩個從庫。

這樣的話性能就比較好，并且數據可靠性也增強了，只有當那個從庫和主庫同時都掛了，才會缺失數據。

5：主從同步延遲怎么處理啊？

答：從上圖的流程就可以得知，延遲是必然存在的。

延遲過大的話就有可能出現一個用戶剛注冊，然后登陸報該用戶不存在的....

因為數據是寫到主庫中的，查詢走從庫有可能還未來同步完畢，導致查不到這個用戶。

這就非常不友好了。

常見解決方式有以下幾種：

• 二次查詢。如果從庫查不到數據，則再去主庫查一遍，由 API封裝即可，算是一個兜底策略，比較簡單。不過等于讀的壓力又轉移到主庫身上了，如果有不法分子估計搞一下必定查不到的查詢，這就難受了。

• 強制將寫之后立馬讀的操作轉移到主庫上。這種屬于代碼寫死了，比如一些寫入之后立馬查詢的操作，就綁定在一起，寫死都走主庫。不推薦，太僵硬了。

• 關鍵業務讀寫都走主庫，非關鍵還是讀寫分離。比如上面我舉例的用戶注冊這種，可以讀寫主庫，這樣就不會有登陸報該用戶不存在的問題，這種訪問量頻次應該也不會很多，所以看業務適當調整此類接口。

到此，關于“常見的MySQL面試題有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！