## 背景 之前的月報中我們比較了InnoDB linear read-ahead和Oracle的multiblock read，兩個的性能有所差別，具體可以參考[月報詳情](http://10.101.233.47:4000/monthly/2015/05/04/ "InnoDB 預讀 VS Oracle 多塊讀")。 這兩種方式之所以帶來了更高的吞吐量，都基于數據存儲的連續性的假設，比如MySQL使用自增字段作為pk的InnoDB索引表，或者是Oracle使用默認的堆表，但當這樣的假設條件不成立的時候，怎么辦？ ## 場景 考慮下面的一個場景，如下圖所示：  這是一個B-Tree結構，典型的InnoDB的索引聚簇表，這樣的結構很容易構造，比如使用一個非連續的字段作為索引字段，隨機對記錄進行插入，這樣leaf page鏈表上的page_no就會產生非連續性，如果進行一次全表掃描，比如?`checksum table t`，按照正常的升序掃描，leaf page掃描的page_no順序是3, 4, 5230等等，這樣其實是無法使用到InnoDB 的Linear read-ahead，更沒有辦法合并IO請求。 對于存在時間比較長，變更又比較多的大表，除非我們對于這個表進行重建，否則leaf page的離散性會隨著時間的推移，越來越嚴重。但對于在線應用來說，重建又會產生比較大的運維風險，這里就介紹一種平衡的方法，logical read-ahead。 ## logical read-ahead 邏輯預讀的概念是指，根據branch節點來預讀leaf節點。 邏輯預讀使用兩個掃描路徑: 1\. 一個cursor定位到leaf page，然后根據leaf page之間的雙鏈表，moves_up進行掃描數據； 2\. 另一個cursor定位到branch節點，因為InnoDB B-Tree結構的每一層都由雙向鏈表進行連接，然后這個cursor就沿著branch節點進行掃描，保存掃描到的page_no，然后使用異步IO，發起這些leaf page的預讀取。 ## 代碼實現 MySQL 5.6版本上的實現方式: 1\. 在`row_search_for_mysql`進行moves_up的過程中進行logical read-ahead； 2\. branch節點掃描的cursor保存到trx結構中，生命周期到一個sql語句結束； 3\. branch cursor掃描用戶可配置的page count，臨時保存到數組中，對page_no進行排序； 4\. 使用libaio發起異步IO讀取，完成logical read-ahead。 logical read-ahead很好的提升了離散存儲數據的吞吐能力，Facebook在他們的MySQL實例的邏輯備份過程中，對于大表的dump備份開啟了此特性，備份速度有非常大的提升。