DB 資料的讀取和儲存方式

rdbms是我們常見的一些儲存資料的倉庫，無論是做前端還是後端，都會接觸到。

我們常見的資料處理，都是通過sql來和資料庫做互動的，因此造成了許多人對資料庫認知比較模糊，底層的架構也不是很清晰，從本週開始，我們介紹些資料庫的基礎知識，來了解資料庫引擎是如何工作的，以及如何設計更好的索引的方**，歡迎一起**。

我們以mysql的架構為例，進行說明。

最上層用於連線、執行緒處理；第二層中包含了大多數的核心服務，包括了對 sql 的解析、分析、優化和快取等功能，儲存過程、觸發器和檢視都是在這裡實現的；而第三層就是真正負責資料的儲存和提取的儲存引擎，例如：innodb、myisam等，文中對儲存引擎的介紹都是對 innodb 實現的分析。

在整個資料庫體系結構中，我們可以使用不同的儲存引擎來儲存資料，而絕大多數儲存引擎都以二進位制的形式儲存資料。

在 innodb 儲存引擎中，所有的資料都被邏輯地存放在表空間中，表空間（tablespace）是儲存引擎中最高的儲存邏輯單位，在表空間的下面又包括段（segment）、區（extent）、頁（page）：

同乙個資料庫例項的所有表空間都有相同的頁大小；預設情況下，表空間中的頁大小都為 16kb，當然也可以通過改變 innodb_page_size 選項對預設大小進行修改，需要注意的是不同的頁大小最終也會導致區大小的不同：

從圖中可以看出，在 innodb 儲存引擎中，乙個區的大小最小為 1mb，頁的數量最少為 64 個。

在我們常用的sql理解中，資料是以行的形式讀取出來的，其實不然，通過上述的結構，我們可以了解到，單次從磁碟讀取單位是頁，而不是行，也就是說，你即便只讀取一行記錄，從磁碟中也是會讀取一頁的，當然了單頁讀取代價也是蠻高的，一般都會進行預讀，這些後續再說。

關係型資料庫管理系統最重要的乙個目標就是，確保表或者索引中的資料是隨時可以用的。那麼為了盡可能的實現這個目標，會使用記憶體中的緩衝池來最小化磁碟活動。

每乙個緩衝池都足夠大，大到可以存放許多頁，可能是成千上萬的頁。

緩衝池管理器將盡力確保經常使用的資料被儲存於池中，以避免一些不必要的磁碟讀。如果乙個索引或者表頁在緩衝池中被找到，那麼將會處理很快。

如果在緩衝池中，沒有找到資料，會從磁碟伺服器的緩衝區裡面去讀取。

磁碟伺服器的緩衝區，如同資料庫的緩衝池讀取一樣，磁碟伺服器試圖將頻繁使用的資料保留在記憶體中，以降低高昂的磁碟讀取成本。這個讀取成本大概會在1ms左右。

如果磁碟伺服器的緩衝池中依然沒有找到資料，此時就必須要從磁碟讀取了，此時讀取又分割槽隨機讀取和順序讀取。

我們必須記住乙個頁包含了多條記錄，我們可能需要該頁上的所有行，也可能是其中一部分，或者是一行，但所花費的成本都是相同的，讀取乙個頁，需要一次隨機i/o,大約需要10ms的時間。

時間組成：

我們可以看到，一次隨機io需要耗時的時間還是很久的，10ms對計算機來說是乙個很長的時間節點了。

如果我們需要將多個頁讀取到緩衝池中，並按順序處理它們，此時讀取的速度回變的很快，具體的原理，在b樹索引中也有過介紹，此時讀取每個頁面（4kb）所花費的時間大概為0.1ms左右，這個時間消耗對隨機io有很大的優勢。

以下幾種情況，會對資料進行順序讀取。

全表掃瞄

全索引掃瞄

索引片掃瞄

通過聚蔟索引掃瞄錶行

順序讀取有兩個重要的優勢：

同時讀取多個頁意味著平均讀取每個頁的時間將會減少。在當前磁碟伺服器條件下，對於4kb大小的頁而言，這一值可能會低於0.1ms（40mb/s）

由於資料庫引擎知道需要讀取哪些頁，所有可以在頁被真正請求之前就提前將其讀取進來，我們稱為預讀。

資料庫中的 b+ 樹索引可以分為聚集索引（clustered index）和輔助索引（secondary index），它們之間的最大區別就是，聚集索引中存放著一條行記錄的全部資訊，而輔助索引中只包含索引列和乙個用於查詢對應行記錄或者主鍵記錄的指標。

關於索引的b+樹結構，網上有很多文章進行分析了，我們就不在一一介紹。