杭州某大廠：MySQL 連環問
本文轉載自微信公眾號「yes的練級攻略」，作者是Yes呀 。轉載本文請聯系yes的練級攻略公眾號。
大家好，我是yes。
MySQL 面試題又更新啦!
請繼續接招。
說說分庫分表?
隨著用戶量的激增和時間的堆砌，存在數據庫里面的數據越來越多，此時的數據庫就會產生瓶頸，出現資源報警、查詢慢等場景。
首先單機數據庫所能承載的連接數、I/O及網絡的吞吐等都是有限的，所以當并發量上來了之后，數據庫就漸漸頂不住了。
再則，如果單表的數據量過大，查詢的性能也會下降。因為數據越多 B+ 樹就越高，樹越高則查詢 I/O 的次數就越多，那么性能也就越差。
因為上述的原因，不得已就得上分庫分表了。
把以前存在一個數據庫實例里的數據拆分成多個數據庫實例，部署在不同的服務器中，這是分庫。
把以前存在一張表里面的數據拆分成多張表，這是分表。
一般而言：
- 分表：是為了解決由于單張表數據量多大，而導致查詢慢的問題。大致三、四千萬行數據就得拆分，不過具體還是得看每一行的數據量大小，有些字段都很小的可能支持更多行數，有些字段大的可能一千萬就頂不住了。
- 分庫：是為了解決服務器資源受單機限制，頂不住高并發訪問的問題，把請求分配到多臺服務器上，降低服務器壓力。
你們一般怎么分庫的?
一般分庫都是按照業務劃分的，比如訂單庫、用戶庫等等。
有時候會針對一些特殊的庫再作切分，比如一些活動相關的庫都做了拆分。
因為做活動的時候并發可能會比較高，怕影響現有的核心業務，所以即使有關聯，也會單獨做拆分。
那你覺得分庫會帶來什么問題呢?
首先是事務的問題。
我們使用關系型數據庫，有很大一點在于它保證事務完整性。
而分庫之后單機事務就用不上了，必須使用分布式事務來解決，而分布式事務基本的都是殘缺的(我之前文章把分布式事務匯總了一波，后臺搜索分布式事務就有了)。
這是很重要的一點需要考慮。
- 連表 JOIN 問題
在一個庫中的時候我們還可以利用 JOIN 來連表查詢，而跨庫了之后就無法使用 JOIN 了。
此時的解決方案就是在業務代碼中進行關聯，也就是先把一個表的數據查出來，然后通過得到的結果再去查另一張表，然后利用代碼來關聯得到最終的結果。
這種方式實現起來稍微比較復雜，不過也是可以接受的。
還有可以適當的冗余一些字段。比如以前的表就存儲一個關聯 ID，但是業務時常要求返回對應的 Name 或者其他字段。這時候就可以把這些字段冗余到當前表中，來去除需要關聯的操作。
那你們怎么分表的?
分表其實有兩種：
- 垂直分表
- 水平分表
垂直分表，來看個圖，很直觀：
垂直分表就是把一些不常用的大字段剝離出去。
像上面的例子：用戶名是很常見的搜索結果，性別和年齡占用的空間又不大，而地址和個人簡介占用的空間相對而言就較大，我們都知道一個數據頁的空間是有限的，把一些無用的數據拆分出去，一頁就能存放更多行的數據。
內存存放更多有用的數據，就減少了磁盤的訪問次數，性能就得到提升。
水平分表，則是因為一張表內的數據太多了，上文也提到了數據越多 B+ 樹就越高，訪問的性能就差，所以進行水平拆分。
其實不管這些，淺顯的理解下，在一百個數據里面找一個數據快，還是在一萬個數據里面找一個數據快?
即使有索引，那厚的書目錄多，翻目錄也慢~
那分表會有什么問題?
垂直分表還好，就是需要關聯一下，而水平分表就有點麻煩了。
- 排序、count、分頁問題
如果一個用戶的數據被拆分到多個表中，那查詢結果分頁就不像以前單張表那樣直接就能查出來了，像 count 操作也是一樣的。
只能由業務代碼來實現或者用中間件將各表中的數據匯總、排序、分頁然后返回。
像 count 操作的結果其實可以緩存下來，然后每次數據增刪都更新計數。
- 路由問題
分表的路由可以分：
- Hash 路由
- 范圍路由
- 路由表
Hash 路由，其實就是選擇表中的某一列，然后進行 Hash 運算，將 Hash 運算得到的結果再對子表數進行取模，這樣就能均勻的將數據分到不同的子表上。
這跟 HashMap 選哪個桶是一樣的原理。
優點就是數據分布均勻。
缺點就是增加子表的時候麻煩，想想 HashMap的擴容，是不是得搬遷數據?這個分表也是一樣的，我們可都知道，數據遷移一件麻煩事!
范圍路由，其實很簡單，可以是時間，也可以是地址，表示一定的范圍的即可。
比如本來一張 User 表，我可以分 User_HZ、User_BJ、User_SH，按照地名來劃分 User。
再比如 log 表，我可以將表分為 log_202103、 log_202104，把日志按照年月來劃分。
優點就是相對而言比較容易擴展，比如現在來個 GZ，那就加個 User_GZ。如果到了 5 月，那就建個 log_202105。
缺點就是數據可能分布不均勻，例如 BJ 的用戶特別多或者某個月搞了促銷，日志量特別大，等等。
路由表，就是專門搞個表來記錄路由信息，來看個圖就很清楚了。
從圖中我們就能得知，UserID 為 2 的用戶數據在要去 User_3 這個用戶表查詢。
優點就是靈活咯，如果要遷移數據，直接遷移然后路由表一改就完事兒了~
缺點就是得多查一次，每次查詢都需要訪問路由表，不過這個一般會做緩存的。
- 全局主鍵問題
以前單表的時候很簡單，就是主鍵自增，現在分表了之后就有點尷尬了。
所以需要一些手段來保證全局主鍵唯一。
還是自增，只不過自增步長設置一下。比如現在有三張表，步長設置為3，三張表 ID 初始值分別是1、2、3。這樣第一張表的 ID 增長是 1、4、7。第二張表是2、5、8。第三張表是3、6、9，這樣就不會重復了。
UUID，這種最簡單，但是不連續的主鍵插入會導致嚴重的頁分裂，性能比較差。
分布式 ID，比較出名的就是 Twitter 開源的 sonwflake 雪花算法，具體就不展開了，不然就又是一篇文章了，簡單點利用 redis 來遞增也行。
那上面說的路由問題的 Sharding-Key 如何設計呢?
我們分表是按照某個列來拆分的，那個列就是 Sharding-Key，查詢的時候必須帶上這個列才行。
例如上面提到的 log_202103，那表明查詢條件一定得帶上日期，這樣才能找到正確的表。
所以設計上得考慮查詢的條件來作為 Sharding-Key。
舉個常常會被問的訂單表 Sharding-Key 例子。
你想著查找訂單的時候會通過訂單號去找，所以應該利用訂單 ID 來作為 Sharding-Key。
但是你想想，你打開外賣軟件想查找你的歷史訂單的時候，你是沒有訂單 ID 的，你只有你的 UserID，那此時只能把所有子表都通過 UserID 遍歷一遍，這樣效率就很低了!
所以你想著那用 UserID 來作為 Sharding-Key 吧!
但是，商家呢?商家肯定關心自己今天賣了多少單，所以他也要查找訂單，但他只有自己的商家 ID，所以如果要查詢訂單，只能把所有子表都通過商家 ID 遍歷一遍，這樣效率就很低了!
所以 Sharding-Key 是滿足不了所有查詢需求的，只能曲線救國。
一般做法就是冗余數據。
將訂單同步到另一張表中給商家使用，這個表按商家 ID 來作為 Sharding-Key，也可以將數據同步到 ES 中。一般而言這里的數據同步都是異步處理，不會影響正常流程。
最后
今天的面試題主要是分庫分表相關的，基本上常問的都涵蓋了。
MySQL 面試題未完，持續更新~
