MySQL中的Multi-Range Read优化

salary有一个辅助索引idx_s，因此除了通过辅助索引查找键值外，还需要通过书签来进行对整行数据的查询，当不启用MRR特性，执行计划如下

若启用MRR

在实际执行中，两者的执行时间差非常大

此外，MRR还可以将某些范围查询，拆分为键值对，以此来进行批量的数据查询，这样的好处是可以在拆分过程中，直接过滤一些不符合查询条件的数据，如

SELECT * FROM t WHERE key_part1>=1000 and key_part1<2000 AND key_part2=1000;

表t有(key_part1,key_part2)的联合索引因此索引根据key_part1,key_part2的位置关系进行排序。若没有MRR，此时查询类型为Range。SQL优化器会先将key_part1>1000 and key_part2<2000的数据线取出来，即使key_part2不等于1000。待取出的行数据后在根据key_part2的条件进行过滤，这会导致无用的数据被取出，如果有大量的数据且其key_part2不等于1000，则启用MRR优化会使性能有巨大的提升 

启用MRR优化，优化器会先将查询条件进行拆分，然后在进行数据查询。上述语句，优化器会将查询条件拆分为(1000,1000),(1001,1000),(1002,1000),...,(1999,1000)，然后在根据这些拆分出的条件进行数据查询

SELECT * FROM salaries 
WHERE(from_date between ‘‘1986-01-01‘ AND ‘1995-01-01‘)
AND(salary between 38000 and 40000);

若启用MRR优化，执行计划为

表salaries上对于salary的索引idx_s，在执行SQL中，启用了MRR优化，所以会对查询条件进行拆分，故此可以看到Using MRR

是否启用MRR优化可以通过optimizer_switch中的标记(flag)来控制，当mrr为ON时，启用.mrr_cost_based标记为是否通过cost based方式来选择是否启用mrr.若mrr设为on，mrr_cost_based设为off,则总是启用MRR优化。

set @@optimizer_switch=‘mrr=on,mrr_cost_based=off‘;

参数read_rnd_buffer_size用来控制键值的缓冲区大小,当大于该值，执行器对已经缓存的数据根据RowID进行排序，并通过RowID来取得行数据。该值默认为256K

MySQL中的Multi-Range Read优化

标签：