> My workload has too much concurrency already so I am most interested
> in the change to make records_in_range do less IO.
>
I also noticed that if MySQL issues a read_multi_range_first() for say 20 ranges, it will
have done 20 separate records_in_range() calls just beforehand which kind of negates the
whole point of having multi_range_*() ..
Maybe some optimizer person can point me towards some FORCE INDEX or other construct that
can make the optimizer skip this step ? If we're forcing an index anyway, are there still
choices to make for the optimizer ? (I'm guessing it can still choose between a range
scan, multirange scan and a full index scan ?)
