有哪些常見的MySQL面試題

本篇內(nèi)容主要講解“有哪些常見的MySQL面試題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“有哪些常見的MySQL面試題”吧!

說說分庫分表?

隨著用戶量的激增和時間的堆砌，存在數(shù)據(jù)庫里面的數(shù)據(jù)越來越多，此時的數(shù)據(jù)庫就會產(chǎn)生瓶頸，出現(xiàn)資源報警、查詢慢等場景。

首先單機數(shù)據(jù)庫所能承載的連接數(shù)、I/O及網(wǎng)絡(luò)的吞吐等都是有限的，所以當(dāng)并發(fā)量上來了之后，數(shù)據(jù)庫就漸漸頂不住了。

再則，如果單表的數(shù)據(jù)量過大，查詢的性能也會下降。因為數(shù)據(jù)越多 B+ 樹就越高，樹越高則查詢 I/O 的次數(shù)就越多，那么性能也就越差。

因為上述的原因，不得已就得上分庫分表了。

把以前存在一個數(shù)據(jù)庫實例里的數(shù)據(jù)拆分成多個數(shù)據(jù)庫實例，部署在不同的服務(wù)器中，這是分庫。

把以前存在一張表里面的數(shù)據(jù)拆分成多張表，這是分表。

一般而言：

• 分表：是為了解決由于單張表數(shù)據(jù)量多大，而導(dǎo)致查詢慢的問題。大致三、四千萬行數(shù)據(jù)就得拆分，不過具體還是得看每一行的數(shù)據(jù)量大小，有些字段都很小的可能支持更多行數(shù)，有些字段大的可能一千萬就頂不住了。

• 分庫：是為了解決服務(wù)器資源受單機限制，頂不住高并發(fā)訪問的問題，把請求分配到多臺服務(wù)器上，降低服務(wù)器壓力。

你們一般怎么分庫的?

一般分庫都是按照業(yè)務(wù)劃分的，比如訂單庫、用戶庫等等。

有時候會針對一些特殊的庫再作切分，比如一些活動相關(guān)的庫都做了拆分。

因為做活動的時候并發(fā)可能會比較高，怕影響現(xiàn)有的核心業(yè)務(wù)，所以即使有關(guān)聯(lián)，也會單獨做拆分。

那你覺得分庫會帶來什么問題呢?

首先是事務(wù)的問題。

我們使用關(guān)系型數(shù)據(jù)庫，有很大一點在于它保證事務(wù)完整性。

而分庫之后單機事務(wù)就用不上了，必須使用分布式事務(wù)來解決，而分布式事務(wù)基本的都是殘缺的(我之前文章把分布式事務(wù)匯總了一波，后臺搜索分布式事務(wù)就有了)。

這是很重要的一點需要考慮。

• 連表 JOIN 問題

在一個庫中的時候我們還可以利用 JOIN 來連表查詢，而跨庫了之后就無法使用 JOIN 了。

此時的解決方案就是在業(yè)務(wù)代碼中進(jìn)行關(guān)聯(lián)，也就是先把一個表的數(shù)據(jù)查出來，然后通過得到的結(jié)果再去查另一張表，然后利用代碼來關(guān)聯(lián)得到最終的結(jié)果。

這種方式實現(xiàn)起來稍微比較復(fù)雜，不過也是可以接受的。

還有可以適當(dāng)?shù)娜哂嘁恍┳侄?。比如以前的表就存儲一個關(guān)聯(lián) ID，但是業(yè)務(wù)時常要求返回對應(yīng)的 Name  或者其他字段。這時候就可以把這些字段冗余到當(dāng)前表中，來去除需要關(guān)聯(lián)的操作。

那你們怎么分表的?

分表其實有兩種：

• 垂直分表

• 水平分表

垂直分表，來看個圖，很直觀：

垂直分表就是把一些不常用的大字段剝離出去。

像上面的例子：用戶名是很常見的搜索結(jié)果，性別和年齡占用的空間又不大，而地址和個人簡介占用的空間相對而言就較大，我們都知道一個數(shù)據(jù)頁的空間是有限的，把一些無用的數(shù)據(jù)拆分出去，一頁就能存放更多行的數(shù)據(jù)。

內(nèi)存存放更多有用的數(shù)據(jù)，就減少了磁盤的訪問次數(shù)，性能就得到提升。

水平分表，則是因為一張表內(nèi)的數(shù)據(jù)太多了，上文也提到了數(shù)據(jù)越多 B+ 樹就越高，訪問的性能就差，所以進(jìn)行水平拆分。

其實不管這些，淺顯的理解下，在一百個數(shù)據(jù)里面找一個數(shù)據(jù)快，還是在一萬個數(shù)據(jù)里面找一個數(shù)據(jù)快?

即使有索引，那厚的書目錄多，翻目錄也慢~

那分表會有什么問題?

垂直分表還好，就是需要關(guān)聯(lián)一下，而水平分表就有點麻煩了。

• 排序、count、分頁問題

如果一個用戶的數(shù)據(jù)被拆分到多個表中，那查詢結(jié)果分頁就不像以前單張表那樣直接就能查出來了，像 count 操作也是一樣的。

只能由業(yè)務(wù)代碼來實現(xiàn)或者用中間件將各表中的數(shù)據(jù)匯總、排序、分頁然后返回。

像 count 操作的結(jié)果其實可以緩存下來，然后每次數(shù)據(jù)增刪都更新計數(shù)。

• 路由問題

分表的路由可以分：

• Hash 路由

• 范圍路由

• 路由表

Hash 路由，其實就是選擇表中的某一列，然后進(jìn)行 Hash 運算，將 Hash  運算得到的結(jié)果再對子表數(shù)進(jìn)行取模，這樣就能均勻的將數(shù)據(jù)分到不同的子表上。

這跟 HashMap 選哪個桶是一樣的原理。

優(yōu)點就是數(shù)據(jù)分布均勻。

缺點就是增加子表的時候麻煩，想想 HashMap的擴容，是不是得搬遷數(shù)據(jù)?這個分表也是一樣的，我們可都知道，數(shù)據(jù)遷移一件麻煩事!

范圍路由，其實很簡單，可以是時間，也可以是地址，表示一定的范圍的即可。

比如本來一張 User 表，我可以分 User_HZ、User_BJ、User_SH，按照地名來劃分 User。

再比如 log 表，我可以將表分為 log_202103、 log_202104，把日志按照年月來劃分。

優(yōu)點就是相對而言比較容易擴展，比如現(xiàn)在來個 GZ，那就加個 User_GZ。如果到了 5 月，那就建個 log_202105。

缺點就是數(shù)據(jù)可能分布不均勻，例如 BJ 的用戶特別多或者某個月搞了促銷，日志量特別大，等等。

路由表，就是專門搞個表來記錄路由信息，來看個圖就很清楚了。

從圖中我們就能得知，UserID 為 2 的用戶數(shù)據(jù)在要去 User_3 這個用戶表查詢。

優(yōu)點就是靈活咯，如果要遷移數(shù)據(jù)，直接遷移然后路由表一改就完事兒了~

缺點就是得多查一次，每次查詢都需要訪問路由表，不過這個一般會做緩存的。

• 全局主鍵問題

以前單表的時候很簡單，就是主鍵自增，現(xiàn)在分表了之后就有點尷尬了。

所以需要一些手段來保證全局主鍵唯一。

還是自增，只不過自增步長設(shè)置一下。比如現(xiàn)在有三張表，步長設(shè)置為3，三張表 ID 初始值分別是1、2、3。這樣第一張表的 ID 增長是  1、4、7。第二張表是2、5、8。第三張表是3、6、9，這樣就不會重復(fù)了。

UUID，這種最簡單，但是不連續(xù)的主鍵插入會導(dǎo)致嚴(yán)重的頁分裂，性能比較差。

分布式 ID，比較出名的就是 Twitter 開源的 sonwflake 雪花算法，具體就不展開了，不然就又是一篇文章了，簡單點利用 redis  來遞增也行。

那上面說的路由問題的 Sharding-Key 如何設(shè)計呢?

我們分表是按照某個列來拆分的，那個列就是 Sharding-Key，查詢的時候必須帶上這個列才行。

例如上面提到的 log_202103，那表明查詢條件一定得帶上日期，這樣才能找到正確的表。

所以設(shè)計上得考慮查詢的條件來作為 Sharding-Key。

舉個常常會被問的訂單表 Sharding-Key 例子。

你想著查找訂單的時候會通過訂單號去找，所以應(yīng)該利用訂單 ID 來作為 Sharding-Key。

但是你想想，你打開外賣軟件想查找你的歷史訂單的時候，你是沒有訂單 ID 的，你只有你的 UserID，那此時只能把所有子表都通過 UserID  遍歷一遍，這樣效率就很低了!

所以你想著那用 UserID 來作為 Sharding-Key 吧!

但是，商家呢?商家肯定關(guān)心自己今天賣了多少單，所以他也要查找訂單，但他只有自己的商家 ID，所以如果要查詢訂單，只能把所有子表都通過商家 ID  遍歷一遍，這樣效率就很低了!

所以 Sharding-Key 是滿足不了所有查詢需求的，只能曲線救國。

一般做法就是冗余數(shù)據(jù)。

將訂單同步到另一張表中給商家使用，這個表按商家 ID 來作為 Sharding-Key，也可以將數(shù)據(jù)同步到 ES  中。一般而言這里的數(shù)據(jù)同步都是異步處理，不會影響正常流程。

到此，相信大家對“有哪些常見的MySQL面試題”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！