介紹

在二級索引上使用範圍掃描讀取行可能會導致在表很大並且未儲存在儲存引擎的快取中時對基表進行許多隨機磁碟訪問。通過磁碟掃描多範圍讀取（MRR）優化，MySQL嘗試通過首先掃描索引並收集相關行的金鑰來減少範圍掃描的隨機磁碟訪問次數。然後對鍵進行排序，最後使用主鍵的順序從基表中檢索行。磁碟掃描MRR的動機是減少隨機磁碟訪問的次數，而是實現對基表資料的順序掃描。

多範圍讀取優化提供以下好處：

• MRR使資料行能夠按順序而不是按隨機順序訪問，具體取決於索引元組。伺服器獲取一組滿足查詢條件的索引元組，根據資料行ID順序對它們進行排序，並使用排序的元組按順序檢索資料行。這使資料訪問更有效，更便宜。
• MRR允許批量處理需要通過索引元組訪問資料行的操作的金鑰訪問請求，例如範圍索引掃描和使用連線屬性索引的等連線。MRR迭代一系列索引範圍以獲得合格的索引元組。隨著這些結果的累積，它們用於訪問相應的資料行。在開始讀取資料行之前不必獲取所有索引元組。

在虛擬生成列上建立的二級索引不支援MRR優化。 InnoDB支援虛擬生成列上的二級索引。

以下方案說明了MRR優化何時有利：

場景A：MRR可用於索引範圍掃描和等連線操作的表InnoDB和 MyISAM表。

1. 索引元組的一部分累積在緩衝區中。
2. 緩衝區中的元組按其資料行ID排序。
3. 根據排序的索引元組序列訪問資料行。

場景B：MRR可 NDB用於多範圍索引掃描的表或通過屬性執行等連線時。

1. 範圍的一部分（可能是單鍵範圍）被累積在​​提交查詢的中心節點上的緩衝區中。
2. 範圍被髮送到訪問資料行的執行節點。
3. 訪問的行被打包到包中併發送回中央節點。
4. 收到的包含資料行的包放在緩衝區中。
5. 從緩衝區讀取資料行。

當使用了MRR優化時，EXPLAIN查詢執行計劃時Extra會顯示MRR。

如果不需要訪問全錶行以生成查詢結果，則INNODB和MyISAM不使用MRR。如果完全基於索引元組中的資訊（通過覆蓋索引）生成結果，則會出現這種情況；MRR沒有提供任何好處。

兩個optimizer_switch引數設定了是否啟用MRR。mrr標記為控制MRR是否開啟。當開啟MRR時(mrr=on),mrr_cost_based根據成本判斷是否啟用MRR，當mrr_cost_based=off的時候，則會盡可能的使用MRR

show variables like 'optimizer_switch'