天天看點

8.2.1.13 Multi-Range Read Optimization 多個範圍讀優化

8.2.1.13 Multi-Range Read Optimization 多個範圍讀優化

使用range scan 來讀取資料庫在一個 secondary index 可以導緻需要的随機磁盤讀寫

當表是大的和不是存儲的在存儲引擎的cache裡的時候。

Disk-Sweep Multi-Range Read (MRR)優化,MySQL 嘗試降低随機磁盤通路對于range scan的次數

通過首先掃描隻有索引和采集相關記錄的keys,

然後keys 被存儲,最後記錄從基表使用primary key order檢索。Disk-sweep MRR 的動機是降低

随機磁盤通路的次數,實作一個更連續掃描基表的方法。

Multi-Range Read 優化提供了這些好處:

MRR 使資料被通路時順序的而不是随機的,基于index tuples.

server 得到一組index tuples滿足查詢條件,根據資料ROW ID 排序它們,

使用排序的tuples來按順序檢索資料。這樣使資料通路更加有效,

MRR可以讓請求key 通路的批量作業,需要通路資料通過index tuples,比如range index scans

和等價的關聯使用index用于關聯屬性。

MRR 周遊一個順序的index range 來得到需要的index tuples,由于這些結果積累,

它們被用來通路響應的資料記錄。沒有必須要在開始讀取資料前獲得所有的index tuples.

下面的假設說明什麼時候MRR優化可以是有好處的:

場景A: MRR 可以用于InnoDB 和MyISAM 表用用于index range scan和等值關聯操作

index tuples的部分是積累在一個Buffer裡

在Buffer中的tuples 是按它們的data row ID 排序

3.根據排序索引tuples順序來通路資料

方案B: MRR 可以用于NDB 表用于 multiple-range index scans 或者當執行一個等價關聯

1.ranges的一部分,可能是 single-key ranges,是累計在一個buffer 在中央節點

2.ranges 被發送到執行節點,通路資料

3.通路的行是被打包到一個packages,并發揮給中心節點

4.接收到的包的資料被放置到一個Buffer

5.從Buffer中讀取資料

當MRR被讀取, 額外的列在EXPLAIN 輸出顯示使用MRR:

InnoDB和MyISAM 不使用MRR 如果全表記錄需要被通路來産生查詢結果。 這是因為如果結果能産生完全的資訊基于

Index tuples(通過覆寫索引),MRR 變的沒好處。

查詢用于MRR 可以被使用,假設這裡有一個index 在on (key_part1, key_part2):

SELECT * FROM t

WHERE key_part1 >= 1000 AND key_part1 < 2000

AND key_part2 = 10000;

index 包含tupes (key_part1, key_part2) values, 首先按key_part1然後按key_part2排序

沒有MRR, 一個Index scan 覆寫所有index tuples 對于key_part1 從1000到2000,

無論對 key_part2值在那些tuples裡, scan做額外的工作來擴充tuples 在範圍包含ey_part2 values other than 10000.

MRR, scan可以分成多個ranges, 每個單一值key_part1(1000, 1001, … , 1999).

這些掃描隻需要查詢 tuples 中的key_part2=1000. 如果index 包含很多的tuples 但是key_part2不是等于10000,

MRR 産生很少的index tuples 被讀取。