常見的MySQL面試題有哪些

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

1：你們公司數(shù)據(jù)庫有備份的吧？

答：有的，因?yàn)閱吸c(diǎn)故障的情況不可避免，所以我們公司有主從。面試官：那你知道主備、主從、主主有什么區(qū)別？

主備就是：主機(jī)和備機(jī)。

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

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

人工切換，得知主機(jī)掛了之后手動把備機(jī)切成主機(jī)，缺點(diǎn)就是慢。

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

主從就是主機(jī)和從機(jī)。

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

主主就是兩個都是主機(jī)

一般情況下都不會有主主的架構(gòu)。

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

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

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

本質(zhì)上是因?yàn)樵L問量太大，主庫的壓力過大，單機(jī)數(shù)據(jù)庫無法支撐并發(fā)讀寫。

然后一般而言讀的次數(shù)遠(yuǎn)高于寫，因此將讀操作分發(fā)到從庫上，這就是常見的讀寫分離。

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

因?yàn)樗饕切枰S護(hù)的，比如你插入一條數(shù)據(jù)，不僅要在聚簇索引上面插入，對應(yīng)的二級索引也得插入，修改也是一樣的。

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

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

答：代碼封裝。

講白了就是代碼層面抽出一個中間層，由中間層來實(shí)現(xiàn)讀寫分離和數(shù)據(jù)庫連接。

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

優(yōu)點(diǎn)：簡單，并且可以根據(jù)業(yè)務(wù)定制化變化，隨心所欲。

缺點(diǎn)：如果數(shù)據(jù)庫宕機(jī)了，發(fā)生主從切換了之后，就得修改配置重啟。如果系統(tǒng)是多語言的話，需要為每個語言都實(shí)現(xiàn)一個中間層代碼，重復(fù)開發(fā)。

中間件

一般而言是獨(dú)立部署的系統(tǒng)，客戶端與這個中間件的交互是通過 SQL 協(xié)議的。

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

缺點(diǎn)就是整體架構(gòu)多了一個系統(tǒng)需要維護(hù)，并且可能成為性能瓶頸，畢竟交互都需要經(jīng)過它中轉(zhuǎn)。

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

4：MySQL 主從同步機(jī)制你知道嗎？

答：主從同步主要依賴的就是 binlog，MySQL 默認(rèn)是異步復(fù)制，具體流程如下：

主庫：

• 接受到提交事務(wù)請求

• 更新數(shù)據(jù)

• 將數(shù)據(jù)寫到binlog中

• 給客戶端響應(yīng)

• 推送binlog到從庫中

從庫： 

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

• 由 SQL 線程從 relay log 重放事件，更新數(shù)據(jù)

• 給主庫返回響應(yīng)。

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

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

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

MySQL 5.7 之后搞了個半同步復(fù)制，有個參數(shù)可以選擇“成功同步幾個從庫就返回響應(yīng)?！?/p>

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

這樣的話性能就比較好，并且數(shù)據(jù)可靠性也增強(qiáng)了，只有當(dāng)那個從庫和主庫同時都掛了，才會缺失數(shù)據(jù)。

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

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

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

因?yàn)閿?shù)據(jù)是寫到主庫中的，查詢走從庫有可能還未來同步完畢，導(dǎo)致查不到這個用戶。

這就非常不友好了。

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

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

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

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

到此，關(guān)于“常見的MySQL面試題有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！