字節(jié)面試官：你用過哪些數(shù)據(jù)庫？我自信回答：MySQL！他：回去等通知吧

你是小阿巴，正在公司敲代碼。

老板走過來說：小阿巴，給咱們網(wǎng)站加個商品搜索功能吧。

你拍拍胸脯：沒問題，我直接用 MySQL 數(shù)據(jù)庫的 LIKE 模糊查詢實現(xiàn)搜索，1 小時上線~

結(jié)果上線后，用戶點擊搜索，卡了半天沒反應(yīng)，老板氣得臉都綠了。

你急的汗流浹背，只能找到號稱『后端之狗』的魚皮求助：阿巴阿巴，俺用 MySQL 搞不定，咋辦啊……

魚皮：不是哥們，又不是只有 MySQL 這一個數(shù)據(jù)庫。

下面我來帶你認識 10 種不同類型的數(shù)據(jù)庫，讓你知道什么場景該用什么數(shù)據(jù)庫。

點個收藏，我們開始~

?? 推薦觀看視頻版，有動畫更好理解：https://www.bilibili.com/video/BV1ChkjBsEzq

關(guān)系型數(shù)據(jù)庫

首先是我們接觸最多的、也是后端入門必學的 關(guān)系型數(shù)據(jù)庫。

在關(guān)系型數(shù)據(jù)庫中，數(shù)據(jù)以 表 的形式進行組織和存儲，每個表就像一個 Excel 表格，包含多個 行 和多個 列。

比如你要做個學生管理系統(tǒng)，把學生信息存儲到關(guān)系型數(shù)據(jù)庫中，結(jié)構(gòu)大概是這樣的：

學號

學生姓名

所屬班級號

1

小李

1

2

小魚

2

3

小皮

3

上述學生表格中，每一行代表一個學生的信息，每一列代表學生的一個屬性。

我們可以使用結(jié)構(gòu)化查詢語言 SQL 來對關(guān)系型數(shù)據(jù)庫表的數(shù)據(jù)進行靈活地查詢、選擇、過濾等。

而關(guān)系型數(shù)據(jù)庫最大的特點，就是表和表之間可以 存在關(guān)系。比如學生管理系統(tǒng)中還可以有班級表，結(jié)構(gòu)如下：

班號

班級名稱

1

快樂班

2

泰酷班

3

躺平班

如果我想知道某個學生所屬的班級信息，只需要在查詢時將學生表的 所屬班級號 和班級表的 班號 進行關(guān)聯(lián)，而不用把所有表格的列存儲在一起，非常靈活。

通過 SQL 可以連接查詢多張表：

得到下面的查詢結(jié)果：

學號

學生姓名

所屬班級號

班級名稱

1

小李

1

快樂班

2

小魚

2

泰酷班

3

小皮

3

躺平班

此外，關(guān)系型數(shù)據(jù)庫遵循 ACID 原則（原子性、一致性、隔離性和持久性），通過 事務(wù) 機制可以保證多個操作同時進行時，數(shù)據(jù)的狀態(tài)保持一致。

舉個例子，A 給 B 轉(zhuǎn)賬，A 扣錢的同時 B 也會加錢，不會出現(xiàn) A 扣了錢 B 卻沒收到錢的情況。

正因為關(guān)系型數(shù)據(jù)庫既能靈活查詢、又能準確寫入，所以它幾乎可以被應(yīng)用在任何項目中。比如各類管理系統(tǒng)、數(shù)據(jù)分析系統(tǒng)、金融銀行系統(tǒng)等。

比較主流的關(guān)系型數(shù)據(jù)庫產(chǎn)品有：

• MySQL：開源易學，后端開發(fā)必學的數(shù)據(jù)庫

• Oracle：人稱 “甲方的數(shù)據(jù)庫”，主要是大型企業(yè)和政府機構(gòu)在用，功能強大但授權(quán)費用昂貴

• PostgreSQL：開源界的天花板，功能最全面

• SQL Server：微軟出品，和 Windows 系統(tǒng)、.NET 生態(tài)集成度高

• SQLite：整個數(shù)據(jù)庫就是一個文件，不需要服務(wù)器，非常輕量。被廣泛應(yīng)用在手機 APP、瀏覽器中，你的手機里可能有幾十個 SQLite。

對于大多數(shù)項目，用 MySQL 等關(guān)系型數(shù)據(jù)庫來存儲數(shù)據(jù)就足夠了。但如果要存儲的數(shù)據(jù)間沒有復雜關(guān)系、或者需要極致的性能時，它并不是最佳選擇。

你點點頭：俺知道，就好比俺要寫一篇文章，沒必要非得把內(nèi)容塞進 Excel 表格里，直接放到 Word 文檔里會更方便編輯和閱讀。

魚皮：沒錯，這時就需要與關(guān)系型數(shù)據(jù)庫互補的 非關(guān)系型數(shù)據(jù)庫。

非關(guān)系型數(shù)據(jù)庫

非關(guān)系型數(shù)據(jù)庫又叫 NoSQL（Not Only SQL），適合存儲關(guān)系不強的、結(jié)構(gòu)靈活的、需要快速訪問的數(shù)據(jù)。

打個比方，關(guān)系型數(shù)據(jù)庫像圖書館，書籍分類明確、擺放有序、借閱有規(guī)矩；非關(guān)系型數(shù)據(jù)庫像你的書桌，怎么順手怎么放，拿取方便最重要。

在實際項目開發(fā)中，最常用的非關(guān)系型數(shù)據(jù)庫是 KV 數(shù)據(jù)庫和文檔數(shù)據(jù)庫。

KV 鍵值數(shù)據(jù)庫

KV 即 Key-Value，數(shù)據(jù)是以 鍵值對 的方式存儲在數(shù)據(jù)庫中的，可以理解為一個超大的 HashMap，數(shù)據(jù)庫中存儲的每個鍵都 唯一對應(yīng) 一個值。

比如存儲用戶信息和熱門商品信息，結(jié)構(gòu)是這樣的：

Key 鍵

Value 值

user:1001

{"name":"魚皮", "age":25}

product:hot

["商品1", "商品2", "商品3"]

鍵和值都可以是任意類型的數(shù)據(jù)，包括字符串、數(shù)字、數(shù)組、JSON 對象等，非常靈活。

由于 KV 存儲的結(jié)構(gòu)簡單清晰，我們能夠很輕松地根據(jù)某個鍵查找出對應(yīng)的值，就像查字典一樣，讀寫數(shù)據(jù)的性能都非常高。

此外，KV 數(shù)據(jù)庫的可擴展性很強。因為數(shù)據(jù)間不存在直接關(guān)聯(lián)，我們可以把鍵值對分散到多臺機器上存儲，通過數(shù)據(jù)分片、負載均衡等策略來支持海量數(shù)據(jù)的高并發(fā)訪問。

由于高性能和高可擴展性，KV 數(shù)據(jù)庫被廣泛應(yīng)用于緩存、分布式會話、分布式鎖、實時統(tǒng)計等場景。

最經(jīng)典的 KV 數(shù)據(jù)庫肯定是 Redis，它是開源的、基于內(nèi)存的數(shù)據(jù)庫，不僅支持豐富的數(shù)據(jù)類型和功能，還有持久化等重要特性，也是后端必學的技術(shù)。其他的常用 KV 數(shù)據(jù)庫有 Memcached、Etcd、LevelDB、RocksDB 等。

文檔數(shù)據(jù)庫

文檔數(shù)據(jù)庫也屬于非關(guān)系型數(shù)據(jù)庫。顧名思義，它適用于存儲和管理 半結(jié)構(gòu)化的 文檔數(shù)據(jù)，數(shù)據(jù)一般以 JSON（BSON）格式存儲。

相比于關(guān)系型數(shù)據(jù)庫中嚴格定義的表格行列，文檔數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)更像是一份份獨立的文檔，每個文檔都可以包含不同類型和格式的數(shù)據(jù)，結(jié)構(gòu)非常靈活。

比如存儲博客文章，結(jié)構(gòu)是這樣的：

文檔 ID

文檔數(shù)據(jù)

1

{"_id": 1, "title": "文章標題1", "content": "這是文章1的內(nèi)容"}

2

{"_id": 2, "title": "文章標題2", "author": "程序員魚皮"}

你撓撓頭：誒，文檔 1 和文檔 2 的字段都不一樣啊，這也行？

魚皮：沒錯，這就是文檔數(shù)據(jù)庫的靈活性。當我們要給某個文檔新增一個字段時，不需要像關(guān)系型數(shù)據(jù)庫那樣先改表結(jié)構(gòu)，直接加就完事了。

而且支持水平擴展，可以分散到多臺服務(wù)器上存儲，適用于內(nèi)容管理系統(tǒng)、博客平臺、電商商品詳情頁等場景。

推薦學習的文檔數(shù)據(jù)庫是 MongoDB，因為它存儲的就是 JSON（BSON）格式數(shù)據(jù)，對前端同學很友好，入門難度也很低。

特定場景的數(shù)據(jù)庫

雖然關(guān)系型和非關(guān)系型數(shù)據(jù)庫已經(jīng)能夠滿足大部分場景，但在一些特殊場景下，使用專門設(shè)計的數(shù)據(jù)庫會更高效。就像你可以用菜刀砍樹，但用斧子會更快更省力。

搜索引擎數(shù)據(jù)庫

專門為搜索功能設(shè)計的數(shù)據(jù)庫。它能存儲和管理大量文本數(shù)據(jù)，提供快速、準確、靈活的全文檢索功能。

你撓撓頭：憑什么它能做到這些呢？

魚皮：秘密在于它使用了 倒排索引 的方式存儲數(shù)據(jù)。

以存儲博客文檔為例，關(guān)系型數(shù)據(jù)庫的存儲結(jié)構(gòu)是：

文檔 id

文檔內(nèi)容

1

感謝關(guān)注魚皮

2

魚皮是一名程序員

3

感謝關(guān)注編程導航

我們能夠根據(jù) id 來查找到對應(yīng)的單篇文檔，也可以通過搜索精確的關(guān)鍵詞，來查找到多篇文檔。

比如搜索 "魚皮"，能搜出文檔 1、2。

但是，如果你搜索 "魚皮程序員"，是無法得到搜索結(jié)果的，因為沒有任何一個文檔的內(nèi)容完全包含 "魚皮程序員" 這個詞。

而在搜索引擎數(shù)據(jù)庫中，首先會將文檔內(nèi)容按照單詞進行分割，也就是 分詞。然后 建立倒排索引，也就是構(gòu)建 單詞到文檔 id 的映射。

有了上述的倒排索引，當用戶搜索 "魚皮程序員" 時，搜索引擎數(shù)據(jù)庫會先對搜索詞進行分詞，得到 "魚皮" 和 "程序員"，然后根據(jù)這兩個詞匯就能找到文檔 id 1 和 2 了。不用再一行一行遍歷表內(nèi)所有的數(shù)據(jù)，實現(xiàn)了更靈活、快速的搜索。

此外，搜索引擎數(shù)據(jù)庫還支持 相關(guān)性排序，能夠根據(jù)用戶的搜索詞對所有搜索結(jié)果進行打分，把最相關(guān)的文檔排到最上面，就像谷哥度娘那樣。

主流的搜索引擎數(shù)據(jù)庫技術(shù)有 Elasticsearch、Apache Solr 等，建議只學習 Elasticsearch 就夠了，它的社區(qū)最活躍、學習資料最豐富。

向量數(shù)據(jù)庫

向量數(shù)據(jù)庫是專門用于存儲和處理 高維向量數(shù)據(jù) 的數(shù)據(jù)庫，也是 AI 時代最火的數(shù)據(jù)庫。

你好奇道：啥是向量？

魚皮：簡單來說，向量是一個數(shù)字數(shù)組，每個數(shù)字代表一個 特征 維度。

舉個例子，在人臉識別系統(tǒng)中，我們需要通過人臉的特征來判斷是否為同一個人。每張人臉圖像都可以通過 AI 模型轉(zhuǎn)換成一個向量，這個向量可能包含成百上千個數(shù)字，每個數(shù)字代表圖像的一個 抽象 特征維度。

實際上，很難說清楚每個數(shù)字代表什么，但便于理解，你可以 想象 下標 0 代表鼻子大小，下標 1 代表眼睛距離等等，以此類推。

之后通過余弦相似度等算法來計算兩個向量的相似度，就能判斷出兩張人臉是不是同一個人。

向量數(shù)據(jù)庫能夠高效存儲這些多維向量數(shù)據(jù)、快速計算向量的相似度、并實現(xiàn)各種不同算法的相似性搜索。適用于人臉識別、推薦系統(tǒng)、語義搜索等場景。

在 AI 時代，可以用向量數(shù)據(jù)庫給 AI 提供特定領(lǐng)域的知識庫，大大提升回答的準確性。

主流的向量數(shù)據(jù)庫技術(shù)有 Milvus、Pinecone 等，像 PostgreSQL 關(guān)系型數(shù)據(jù)庫也通過插件支持存儲向量類型的數(shù)據(jù)。

圖數(shù)據(jù)庫

圖數(shù)據(jù)庫是專門用于存儲和處理 圖結(jié)構(gòu)數(shù)據(jù) 的數(shù)據(jù)庫。

注意，這里的 “圖” 可不是照片或圖表，而是數(shù)學中的圖論概念，由節(jié)點（Node）和邊（Edge）構(gòu)成的圖形結(jié)構(gòu)。

比如我們要存儲一個社交網(wǎng)絡(luò)的朋友關(guān)系，對應(yīng)的圖可能是由多個用戶節(jié)點和好友關(guān)系邊組成的。

在圖數(shù)據(jù)庫中，需要 2 個表格來存儲。

1）節(jié)點信息表：

節(jié)點 id

節(jié)點名

1

魚皮

2

阿巴

3

編程導航

2）邊信息表：

邊 id

邊類型

起始節(jié)點

結(jié)束節(jié)點

1

好友

1

2

2

好友

2

3

通過存儲這些節(jié)點和邊的信息，圖數(shù)據(jù)庫就能快速查詢和分析復雜的關(guān)系網(wǎng)絡(luò)。比如查找 “朋友的朋友”、計算兩個用戶之間的最短路徑、發(fā)現(xiàn)社交圈子等等。

因此，圖數(shù)據(jù)庫非常適合構(gòu)建社交網(wǎng)絡(luò)、推薦系統(tǒng)、知識圖譜等。

比較主流的圖數(shù)據(jù)庫有 Neo4j、TigerGraph 等，都支持復雜的圖算法和分布式擴展，能夠通過并行計算加速圖形處理。

時序數(shù)據(jù)庫

時序數(shù)據(jù)庫是專門用于高效存儲和處理 時間序列 的數(shù)據(jù)庫。

時間序列是指以時間作為主要維度的數(shù)據(jù)序列，也就是每個數(shù)據(jù)單元都帶著 時間戳，按時間順序排列。

舉個例子，在服務(wù)器監(jiān)控系統(tǒng)中，我們需要每分鐘記錄服務(wù)器的 CPU 使用率、內(nèi)存使用率等指標，數(shù)據(jù)結(jié)構(gòu)如下：

時間戳

設(shè)備ID

CPU使用率

內(nèi)存使用率

2026-01-08 10:00

Server001

45%

60%

2026-01-08 10:01

Server001

48%

62%

2026-01-08 10:02

Server001

52%

65%

有了這些數(shù)據(jù)，我們就能夠按照時間范圍進行高效查詢、做聚合分析（比如計算過去 1 小時的平均 CPU 使用率）、進行數(shù)據(jù)可視化展示。

因此，時序數(shù)據(jù)庫非常適用于物聯(lián)網(wǎng)設(shè)備監(jiān)控、服務(wù)器性能監(jiān)控、金融交易數(shù)據(jù)分析等場景。

主流的時序數(shù)據(jù)庫技術(shù)有 InfluxDB、TimescaleDB 等，一般會配合 Grafana 監(jiān)控看板一起使用，實現(xiàn)數(shù)據(jù)存儲 + 快速可視化。你在運維團隊看到的那些酷炫的實時監(jiān)控大屏，背后就是時序數(shù)據(jù)庫在支撐。

列存數(shù)據(jù)庫

區(qū)別于傳統(tǒng)的行式數(shù)據(jù)庫，列存數(shù)據(jù)庫 以列作為基本的存儲單位，把每一列的數(shù)據(jù)存儲在一起。

拿公司每天的收入來舉個例子，傳統(tǒng)的行式數(shù)據(jù)庫是這么存儲的：

日期

銷售額

成本

利潤

2026-01-01

500

600

-100

2026-01-02

280

450

-170

2026-01-03

290

480

-190

而在列存數(shù)據(jù)庫中，底層大概是這么存儲的，看起來像是對矩陣做了一次轉(zhuǎn)置：

日期

2026-01-01

2026-01-02

2026-01-03

銷售額

500

280

290

成本

600

450

480

利潤

-100

-170

-190

如果我們要統(tǒng)計這 3 天公司的總利潤，傳統(tǒng)的行式數(shù)據(jù)庫需要依次讀取每一行的數(shù)據(jù)，然后再提取出利潤這一列進行計算；而列存數(shù)據(jù)庫直接讀取利潤這一列就行了，不用管其他列，大大提高了數(shù)據(jù)分析和聚合操作的效率。

而且從計算機底層來分析，把相同類型的數(shù)據(jù)在同一列中連續(xù)存儲，可以實現(xiàn)更好的數(shù)據(jù)壓縮效果、節(jié)約存儲空間。

因此，列存數(shù)據(jù)庫適用于報表生成、數(shù)據(jù)倉庫、商業(yè)智能分析等場景。

主流的列存數(shù)據(jù)庫技術(shù)有 ClickHouse、Apache HBase、Druid 等，都是大數(shù)據(jù)開發(fā)的必修課。

融合型數(shù)據(jù)庫

前面我們講了關(guān)系型和非關(guān)系型數(shù)據(jù)庫，要么強調(diào)靈活查詢、要么強調(diào)性能和擴展，各有側(cè)重。

但有些數(shù)據(jù)庫偏偏 “既要又要”，要把兩者的優(yōu)點融合到一起，這就是接下來要講的融合型數(shù)據(jù)庫。

NewSQL 數(shù)據(jù)庫

NewSQL 是一類新興的數(shù)據(jù)庫，它融合了傳統(tǒng)關(guān)系型和非關(guān)系型數(shù)據(jù)庫的優(yōu)點。既有傳統(tǒng) SQL 數(shù)據(jù)庫的 ACID 特性和事務(wù)支持，又有 NoSQL 的水平擴展能力和高性能。支持標準 SQL 查詢、分布式架構(gòu)、自動容錯和故障恢復，可以替代傳統(tǒng)的分庫分表方案，特別適用于大廠的高并發(fā)系統(tǒng)。

主流的 NewSQL 數(shù)據(jù)庫有 TiDB、CockroachDB、Google Spanner 等。其中 TiDB 是國產(chǎn)之光，支持 HTAP（混合事務(wù)分析處理），而且完全兼容 MySQL 協(xié)議，遷移成本低；CockroachDB 人稱 “蟑螂數(shù)據(jù)庫”，因為它像蟑螂一樣頑強，集群中一個節(jié)點掛了，其他節(jié)點依然能正常服務(wù)，打不死。

多模數(shù)據(jù)庫

區(qū)別于前面所有存儲單一數(shù)據(jù)模型的數(shù)據(jù)庫，多模數(shù)據(jù)庫能夠直接在一個數(shù)據(jù)庫里同時存儲和處理 多種不同類型 的數(shù)據(jù)。比如關(guān)系型數(shù)據(jù)、文檔數(shù)據(jù)、圖形數(shù)據(jù)、鍵值對數(shù)據(jù)等等，非常靈活、省去了維護多個數(shù)據(jù)庫的麻煩。

而且多模數(shù)據(jù)庫還支持跨模型事務(wù)，能夠更輕松地實現(xiàn)數(shù)據(jù)的一致性和完整性，不需要手動實現(xiàn)跨庫事務(wù)、跨庫數(shù)據(jù)同步這些復雜操作。

雖然聽起來很厲害，但實際開發(fā)中很少用，因為樣樣通樣樣松，多模數(shù)據(jù)庫的性能往往不如專注單一場景的數(shù)據(jù)庫。

原生的多模數(shù)據(jù)庫技術(shù)有 ArangoDB、OrientDB 等，它們從設(shè)計之初就是為多模式設(shè)計的。前面也提到，雖然 PostgreSQL 這樣的老牌關(guān)系型數(shù)據(jù)庫可以通過豐富的插件支持多種數(shù)據(jù)類型（比如 JSON 文檔、向量、地理空間數(shù)據(jù)等），但它的核心始終是關(guān)系模型，多模支持算是錦上添花，不過這也體現(xiàn)了 PostgreSQL 的強大。

怎么選擇數(shù)據(jù)庫？

你一臉懵逼：阿巴阿巴，你講了這么多數(shù)據(jù)庫，俺頭都大了，到底該選哪個？

魚皮笑了笑：別慌，數(shù)據(jù)庫選型其實沒那么復雜。

優(yōu)先選用 MySQL / PostgreSQL + Redis，能覆蓋 90% 的項目需求。

有特定功能或優(yōu)化需求時，再選擇專業(yè)數(shù)據(jù)庫。比如需要搜索功能了，再加 Elasticsearch；要做 AI 知識庫了，再加向量數(shù)據(jù)庫。

畢竟每多一個數(shù)據(jù)庫，就多一份運維工作和故障風險。

你：學會了學廢了！對了魚皮，我還聽說過數(shù)據(jù)湖、數(shù)據(jù)倉庫，這些是啥啊？

魚皮：簡單來說，數(shù)據(jù)倉庫是用來存儲和分析大量結(jié)構(gòu)化數(shù)據(jù)的；數(shù)據(jù)湖更像個大水池，什么數(shù)據(jù)都能往里扔，包括日志、圖片、視頻這些非結(jié)構(gòu)化數(shù)據(jù)。它們更多是大數(shù)據(jù)架構(gòu)層面的概念。

感興趣的話，點個關(guān)注，后面專門出一期講講~

點擊下方關(guān)注魚皮，獲取免費編程學習路線、簡歷模板、面試題解、AI 知識庫、項目教程、交流群。

一些對大家有用的資源：
100+ 編程學習路線 / 實戰(zhàn)項目 / 求職指導
100+ 簡歷模板
300+ 企業(yè)面試題庫 mianshiya.com
500+ AI 資源大全
1 對 1 模擬面試
動畫學算法教程