來源：概覽資料庫索引

資料庫表是一組行/記錄。然而，這些行並不是以表的形式物理儲存的，它們儲存在塊上的資料頁中。要在這些資料頁中找到特定記錄需要掃描多個檔案。為了改進這一點，我們建立索引。索引是小型的引用表，用於根據索引值儲存對行的引用。

索引是一種使資料檢索更快的資料庫物件。 但是，索引的建立也需要時間，並且會佔用額外的空間。因此，在選擇正確的索引建立策略時，我們必須審慎選擇。

RUM猜想

類似於CAP定理，RUM猜想指出 —— 我們無法設計一個儲存系統的訪問方法，使其在以下三個方面都最優：

讀、更新和記憶體。

讀取、更新、記憶體 — 以兩者最佳化為代價的第三者。

讀取開銷： 定義為總讀取資料量（主要 + 輔助）與預期讀取的主要資料量之間的比率。透過讀取放大來衡量。

更新開銷： 定義為總寫入資料量（主要 + 輔助）與預期更新的主要資料量之間的比率。透過寫入放大來衡量。

根據上圖中的讀取和寫入模式，資料庫將分為以下5類：

•平衡 — 讀取和寫入均勻分佈。很少發生。•讀取最佳化 — 寫入較少，讀取較多（分析工作負載）•寫入最佳化 — 寫入較多，讀取較少（事務工作負載）•熱分割槽讀取 — 來自某些資料部分的讀取較多•熱分割槽寫入 — 向某些部分的寫入較多

索引型別

無索引

實現：Kafka（可以看作純粹是WAL）、資料倉儲

主鍵索引

主鍵 = 分割槽鍵 + （可選）排序鍵

•分割槽鍵 = “什麼節點”•排序鍵 = 滿足唯一性約束的剩餘內容

有各種分割槽策略，其中一些如下：

•雜湊分割槽（也稱為“一致性雜湊”）•範圍分割槽•隨機數

聚簇索引 — 物理資料組織

非聚簇索引 — 邏輯組織

KV儲存（雜湊表）

•雜湊分割槽在這裡非常有意義•只能在RAM中進行，這就是為什麼我們在PostgreSQL等資料庫中看不到它•實現：Memcache、Redis

B樹 — 讀取最佳化

•實現：DynamoDB、PostgreSQL•變體：Bw-tree 等（檢視 Alex Petrov 的《Database Internals》）•它是許多資料庫中的預設索引。

點陣圖索引

用於OLAP的讀取和記憶體最佳化。

LSM樹 — 寫入最佳化

•實現：Cassandra、Spanner

二級索引 — 更多讀取最佳化

•本地二級索引 — 這是“預設”/“正常”的二級索引•全域性二級索引 - 可能對於讀取重型的鍵範圍查詢和無法避免的雜湊收集最有意義•實現：DynamoDB，可能是Spanner

多維索引

•連線索引•R樹（實現：PostgreSQL）•四叉樹（實現：Elasticsearch）•地理雜湊（實現：Redis）

倒排索引

•實現：ElasticSearch、PostgreSQL、Redis•示例場景：Twitter 等社交媒體站點的文字搜尋，google.com，GitHub

跳躍表

•實現：Redis（僅）•示例場景：遊戲排行榜

向量索引

•實現：Pinecone、Facebook 的 Faiss、PlanetScale 的 MySQL 分支、Redis•示例場景：機器學習問題

資料立方體和物化檢視

•實現：資料倉儲，支援OLAP的資料庫

Count-min sketch

•就RUM而言，以極端OLAP讀取延遲為代價換取精度•實現：Flink、AWS Firehose、Druid、Spark streams、Redis

對於分散式系統，還有其他有趣的權衡。其中之一是PACELC，它說：如果是分割槽，選擇可用性和一致性之間的折衷，否則選擇延遲和一致性之間的折衷。有許多級別的一致性可供折衷選擇（以及隔離級別）。

一致性級別

•強一致性•最終一致性•一致字首•單調讀取