前言

數(shù)據(jù)庫相關的面試題早已成為了一線互聯(lián)網大廠面試的家常菜，如果你對數(shù)據(jù)庫不太熟悉，我勸你不要輕易面試大廠。那么，為什么數(shù)據(jù)庫成了大廠面試的家常菜呢？主要原因當然還是海量數(shù)據(jù)。

無論對于剛入行的小白還是有幾年Java開發(fā)經驗的從業(yè)而言，面試不僅是你必須要面對的事情，更是你升職加薪的一個途徑。許多朋友面試了幾家公司也沒拿到一個滿意的薪資，究其根還是在于自己的知識不夠系統(tǒng)化，太凌亂。針對性的溫故知新往往能達到事半功倍的效果。

在這里我總結一線互聯(lián)網大廠java面試中常問的“數(shù)據(jù)庫”問題，由于過多答案文字僅以圖片展示，所有內容已總結成文檔在文末有領取方式！

為什么要分庫分表？

首先回答一下為什么要分庫分表，答案很簡單：數(shù)據(jù)庫出現(xiàn)性能瓶頸。用大白話來說就是數(shù)據(jù)庫快扛不住了。

數(shù)據(jù)庫出現(xiàn)性能瓶頸，對外表現(xiàn)有幾個方面：

• 大量請求阻塞在高并發(fā)場景下，大量請求都需要操作數(shù)據(jù)庫，導致連接數(shù)不夠了，請求處于阻塞狀態(tài)。
• SQL 操作變慢如果數(shù)據(jù)庫中存在一張上億數(shù)據(jù)量的表，一條 SQL 沒有命中索引會全表掃描，這個查詢耗時會非常久。
• 存儲出現(xiàn)問題業(yè)務量劇增，單庫數(shù)據(jù)量越來越大，給存儲造成巨大壓力。

從機器的角度看，性能瓶頸無非就是CPU、內存、磁盤、網絡這些，要解決性能瓶頸最簡單粗暴的辦法就是提升機器性能，但是通過這種方法成本和收益投入比往往又太高了，不劃算，所以重點還是要從軟件角度入手。

數(shù)據(jù)庫相關優(yōu)化方案

數(shù)據(jù)庫優(yōu)化方案很多，主要分為兩大類：軟件層面、硬件層面。

軟件層面包括：SQL 調優(yōu)、表結構優(yōu)化、讀寫分離、數(shù)據(jù)庫集群、分庫分表等；

硬件層面主要是增加機器性能。

SQL 調優(yōu)

SQL 調優(yōu)往往是解決數(shù)據(jù)庫問題的第一步，往往投入少部分精力就能獲得較大的收益。

SQL 調優(yōu)主要目的是盡可能地讓那些慢 SQL 變快，手段其實也很簡單就是讓 SQL 執(zhí)行盡量命中索引。

開啟慢 SQL 記錄

如果你使用的是 Mysql，需要在 Mysql 配置文件中配置幾個參數(shù)即可。

slow_query_log=on long_query_time=1 slow_query_log_file=/path/to/log

調優(yōu)的工具

常常會用到 explain 這個命令來查看 SQL 語句的執(zhí)行計劃，通過觀察執(zhí)行結果很容易就知道該 SQL 語句是不是全表掃描、有沒有命中索引。

select id, age, gender from user where name = '愛笑的架構師';

返回有一列叫“type”，常見取值有：

ALL、index、range、 ref、eq_ref、const、system、NULL（從左到右，性能從差到好）

ALL 代表這條 SQL 語句全表掃描了，需要優(yōu)化。一般來說需要達到range 級別及以上。

表結構優(yōu)化

以一個場景舉例說明：

“user”表中有 user_id、nickname 等字段，“order”表中有order_id、user_id等字段，如果想拿到用戶昵稱怎么辦？一般情況是通過 join 關聯(lián)表操作，在查詢訂單表時關聯(lián)查詢用戶表，從而獲取到用戶昵稱。

但是隨著業(yè)務量增加，訂單表和用戶表肯定也是暴增，這時候通過兩個表關聯(lián)數(shù)據(jù)就比較費力了，為了取一個昵稱字段而不得不關聯(lián)查詢幾十上百萬的用戶表，其速度可想而知。

這個時候可以嘗試將 nickname 這個字段加到 order 表中（order_id、user_id、nickname），這種做法通常叫做數(shù)據(jù)庫表冗余字段。這樣做的好處展示訂單列表時不需要再關聯(lián)查詢用戶表了。

冗余字段的做法也有一個弊端，如果這個字段更新會同時涉及到多個表的更新，因此在選擇冗余字段時要盡量選擇不經常更新的字段。

架構優(yōu)化

當單臺數(shù)據(jù)庫實例扛不住，我們可以增加實例組成集群對外服務。

當發(fā)現(xiàn)讀請求明顯多于寫請求時，我們可以讓主實例負責寫，從實例對外提供讀的能力；

如果讀實例壓力依然很大，可以在數(shù)據(jù)庫前面加入緩存如 redis，讓請求優(yōu)先從緩存取數(shù)據(jù)減少數(shù)據(jù)庫訪問。

緩存分擔了部分壓力后，數(shù)據(jù)庫依然是瓶頸，這個時候就可以考慮分庫分表的方案了，后面會詳細介紹。

硬件優(yōu)化

硬件成本非常高，一般來說不可能遇到數(shù)據(jù)庫性能瓶頸就去升級硬件。

在前期業(yè)務量比較小的時候，升級硬件數(shù)據(jù)庫性能可以得到較大提升；但是在后期，升級硬件得到的收益就不那么明顯了。

分庫分表詳解

下面我們以一個商城系統(tǒng)為例逐步講解數(shù)據(jù)庫是如何一步步演進。

單應用單數(shù)據(jù)庫

在早期創(chuàng)業(yè)階段想做一個商城系統(tǒng)，基本就是一個系統(tǒng)包含多個基礎功能模塊，最后打包成一個 war 包部署，這就是典型的單體架構應用。

如上圖，商城系統(tǒng)包括主頁 Portal 模板、用戶模塊、訂單模塊、庫存模塊等，所有的模塊都共有一個數(shù)據(jù)庫，通常數(shù)據(jù)庫中有非常多的表。

因為用戶量不大，這樣的架構在早期完全適用，開發(fā)者可以拿著 demo到處找（騙）投資人。

一旦拿到投資人的錢，業(yè)務就要開始大規(guī)模推廣，同時系統(tǒng)架構也要匹配業(yè)務的快速發(fā)展。

多應用單數(shù)據(jù)庫

在前期為了搶占市場，這一套系統(tǒng)不停地迭代更新，代碼量越來越大，架構也變得越來越臃腫，現(xiàn)在隨著系統(tǒng)訪問壓力逐漸增加，系統(tǒng)拆分就勢在必行了。

為了保證業(yè)務平滑，系統(tǒng)架構重構也是分了幾個階段進行。

第一個階段將商城系統(tǒng)單體架構按照功能模塊拆分為子服務，比如：Portal 服務、用戶服務、訂單服務、庫存服務等。

如上圖，多個服務共享一個數(shù)據(jù)庫，這樣做的目的是底層數(shù)據(jù)庫訪問邏輯可以不用動，將影響降到最低。

多應用多數(shù)據(jù)庫

隨著業(yè)務推廣力度加大，數(shù)據(jù)庫終于成為了瓶頸，這個時候多個服務共享一個數(shù)據(jù)庫基本不可行了。我們需要將每個服務相關的表拆出來單獨建立一個數(shù)據(jù)庫，這其實就是“分庫”了。

單數(shù)據(jù)庫的能夠支撐的并發(fā)量是有限的，拆成多個庫可以使服務間不用競爭，提升服務的性能。

如上圖，從一個大的數(shù)據(jù)中分出多個小的數(shù)據(jù)庫，每個服務都對應一個數(shù)據(jù)庫，這就是系統(tǒng)發(fā)展到一定階段必要要做的“分庫”操作。

現(xiàn)在非?；鸬奈⒎占軜嬕彩且粯拥?#xff0c;如果只拆分應用不拆分數(shù)據(jù)庫，不能解決根本問題，整個系統(tǒng)也很容易達到瓶頸。

分表

說完了分庫，那什么時候分表呢？

如果系統(tǒng)處于高速發(fā)展階段，拿商城系統(tǒng)來說，一天下單量可能幾十萬，那數(shù)據(jù)庫中的訂單表增長就特別快，增長到一定階段數(shù)據(jù)庫查詢效率就會出現(xiàn)明顯下降。

因此，當單表數(shù)據(jù)增量過快，業(yè)界流傳是超過500萬的數(shù)據(jù)量就要考慮分表了。當然500萬只是一個經驗值，大家可以根據(jù)實際情況做出決策。

那如何分表呢？

分表有幾個維度，一是水平切分和垂直切分，二是單庫內分表和多庫內分表。

水平拆分和垂直拆分

就拿用戶表（user）來說，表中有7個字段：id,name,age,sex,nickname,description，如果 nickname 和 description 不常用，我們可以將其拆分為另外一張表：用戶詳細信息表，這樣就由一張用戶表拆分為了用戶基本信息表+用戶詳細信息表，兩張表結構不一樣相互獨立。但是從這個角度來看垂直拆分并沒有從根本上解決單表數(shù)據(jù)量過大的問題，因此我們還是需要做一次水平拆分。

還有一種拆分方法，比如表中有一萬條數(shù)據(jù)，我們拆分為兩張表，id 為奇數(shù)的：1，3，5，7……放在 user1， id 為偶數(shù)的：2，4，6，8……放在 user2中，這樣的拆分辦法就是水平拆分了。

水平拆分的方式也很多，除了上面說的按照 id 拆表，還可以按照時間維度去拆分，比如訂單表，可以按每日、每月等進行拆分。

• 每日表：只存儲當天的數(shù)據(jù)。
• 每月表：可以起一個定時任務將前一天的數(shù)據(jù)全部遷移到當月表。
• 歷史表：同樣可以用定時任務把時間超過 30 天的數(shù)據(jù)遷移到 history表。

總結一下水平拆分和垂直拆分的特點：

• 垂直切分：基于表或字段劃分，表結構不同。
• 水平切分：基于數(shù)據(jù)劃分，表結構相同，數(shù)據(jù)不同。

單庫內拆分和多庫拆分

拿水平拆分為例，每張表都拆分為了多個子表，多個子表存在于同一數(shù)據(jù)庫中。比如下面用戶表拆分為用戶1表、用戶2表。

在一個數(shù)據(jù)庫中將一張表拆分為幾個子表在一定程度上可以解決單表查詢性能的問題，但是也會遇到一個問題：單數(shù)據(jù)庫存儲瓶頸。

所以在業(yè)界用的更多的還是將子表拆分到多個數(shù)據(jù)庫中。比如下圖中，用戶表拆分為兩個子表，兩個子表分別存在于不同的數(shù)據(jù)庫中。

多庫拆分

一句話總結：分表主要是為了減少單張表的大小，解決單表數(shù)據(jù)量帶來的性能問題。

分庫分表帶來的復雜性

既然分庫分表這么好，那我們是不是在項目初期就應該采用這種方案呢？不要激動，冷靜一下，分庫分表的確解決了很多問題，但是也給系統(tǒng)帶來了很多復雜性，下面簡要說一說。

（1）跨庫關聯(lián)查詢

在單庫未拆分表之前，我們可以很方便使用 join 操作關聯(lián)多張表查詢數(shù)據(jù)，但是經過分庫分表后兩張表可能都不在一個數(shù)據(jù)庫中，如何使用 join 呢？

有幾種方案可以解決：

• 字段冗余：把需要關聯(lián)的字段放入主表中，避免 join 操作；
• 數(shù)據(jù)抽象：通過ETL等將數(shù)據(jù)匯合聚集，生成新的表；
• 全局表：比如一些基礎表可以在每個數(shù)據(jù)庫中都放一份；
• 應用層組裝：將基礎數(shù)據(jù)查出來，通過應用程序計算組裝；

（2）分布式事務

單數(shù)據(jù)庫可以用本地事務搞定，使用多數(shù)據(jù)庫就只能通過分布式事務解決了。

常用解決方案有：基于可靠消息（MQ）的解決方案、兩階段事務提交、柔性事務等。

（3）排序、分頁、函數(shù)計算問題

在使用 SQL 時 order by， limit 等關鍵字需要特殊處理，一般來說采用分片的思路：

先在每個分片上執(zhí)行相應的函數(shù)，然后將各個分片的結果集進行匯總和再次計算，最終得到結果。

（4）分布式 ID

如果使用 Mysql 數(shù)據(jù)庫在單庫單表可以使用 id 自增作為主鍵，分庫分表了之后就不行了，會出現(xiàn)id 重復。

常用的分布式 ID 解決方案有：

• UUID
• 基于數(shù)據(jù)庫自增單獨維護一張 ID表
• 號段模式
• Redis 緩存
• 雪花算法（Snowflake）
• 百度uid-generator
• 美團Leaf
• 滴滴Tinyid

這些方案后面會寫文章專門介紹，這里不再展開。

（5）多數(shù)據(jù)源

分庫分表之后可能會面臨從多個數(shù)據(jù)庫或多個子表中獲取數(shù)據(jù)，一般的解決思路有：客戶端適配和代理層適配。

業(yè)界常用的中間件有：

• shardingsphere（前身 sharding-jdbc）
• Mycat

最后

分享一些系統(tǒng)的面試題，大家可以拿去刷一刷，準備面試漲薪。

請點贊后，戳這里，免費獲取！

這些面試題相對應的技術點：

• JVM
• MySQL
• Mybatis
• MongoDB
• Redis
• Spring
• Spring boot
• Spring cloud
• Kafka
• RabbitMQ
• Nginx
• …

大類就是：

• Java基礎
• 數(shù)據(jù)結構與算法
• 并發(fā)編程
• 數(shù)據(jù)庫
• 設計模式
• 微服務
• 消息中間件

624341366317)]

[外鏈圖片轉存中…(img-o3Z8GL1A-1624341366317)]

[外鏈圖片轉存中…(img-XyS8a3jl-1624341366318)]

[外鏈圖片轉存中…(img-UZ6D2Pjc-1624341366319)]

[外鏈圖片轉存中…(img-UTqsAA5v-1624341366320)]

[外鏈圖片轉存中…(img-684LZ4KI-1624341366320)]

[外鏈圖片轉存中…(img-RVZyPP4D-1624341366321)]

總結

以上是生活随笔為你收集整理的mysql数据库实用教程答案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。