[MRR] turn -MySQL optimization of MRR

MRR，全称「Multi-Range Read Optimization」。

Simply put: MRR by the "random disk reads," into a "sequential disk reads", thereby improving the performance of the index query.

As for:

• Why do we read into a random sequence read?

• How transformation?

• Why sequential read will be able to enhance read performance?

Let's get started.

Disk: hard to force the bottom of the working people

Perform a range query:

mysql > explain select * from stu where age between 10 and 20;
+----+-------------+-------+-------+------+---------+------+------+-----------------------+
| id | select_type | table | type  | key  | key_len | ref  | rows | Extra                 |
+----+-------------+-------+-------+----------------+------+------+-----------------------+
|  1 | SIMPLE      |  stu  | range | age  | 5       | NULL |  960 | Using index condition |
+----+-------------+-------+-------+----------------+------+------+-----------------------+

When this is performed sql, MySQL will, to read the data disk (assuming the data is not the data buffer pool) according to the embodiment of FIG:

 

 

The red line is the whole process of the inquiry, the blue line is the motion path of the disk.

This figure is according to the index structure Myisam paintings, but also applies to Innodb.

For the secondary index Myisam, left field is the age, the right is a complete line of data storage place.

First the left side of the secondary index to find records meet the conditions of the first find ( in fact, each node is a page, a page can have a lot of records, where we assume that each page has only one ), then to the right to read take a complete record of this data.

After reading, back to the left, next to continue to find a record of compliance with the conditions, after finding, to the right to read, then I found this piece of data to keep data in physical memory location, away from the thief!

Zaban, no way, can only make do with the head and the disk mechanical movement, to give you read this data.

Articles III, IV, are the same, each read data, the disk head and had to run a good long way away.

Simplify the structure of the disk can be seen as this:

 

 

 

Imagine, in order to execute this sql statement to you, to keep the disk rotation, head to keep moving, these mechanical movement, they are very time-consuming.

10,000 RPM (Revolutions Per Minute, ie rpm) mechanical hard disk, you can perform about 167 times per second disk reads, so in extreme cases, MySQL per second can only give you 167 return data, which does not count CPU queuing time.

For Innodb, it is the same.  Innodb are clustered index (cluster index), so B + tree just need the right had been replaced by a leaf node with complete data on it.

 

Sequential read: a storm like revolution

Here you know how much disk random access extravagant things, so, obviously, should be converted into sequential access random access:

mysql > set optimizer_switch='mrr=on';
Query OK, 0 rows affected (0.06 sec)

mysql > explain select * from stu where age between 10 and 20;
+----+-------------+-------+-------+------+---------+------+------+----------------+
| id | select_type | table | type  | key  | key_len | ref  | rows | Extra          |
+----+-------------+-------+-------+------+---------+------+------+----------------+
|  1 | SIMPLE      | tbl   | range | age  |    5    | NULL |  960 | ...; Using MRR |
+----+-------------+-------+-------+------+---------+------+------+----------------+

We opened the MRR, re-execute the sql statement and found one more Extra "Using MRR."

This time the MySQL query process will become so:

 

For Myisam, before going for a complete disk data will be sorted first according to rowid, go to the order of reading the disk.

For Innodb, according to the clustering index will be sorted key values, and then sequentially reading the clustered index.

Sequential read brings several benefits:

1, disk and magnetic head. No need to do the mechanical movement;

2, can take advantage of disk read-ahead

For example, when the data page is requested by a client, you can put the data back pages also returns together into the data buffer pool, so if the next data just need the next page, you no longer need to read the disk. To do so is based on the theory of computer science in the famous locality principle:

 When a data is used, the data in the vicinity thereof is also typically used immediately.

3, in a query, the data of each page is read only once from disk

MySQL data from the disk read pages, put data into the data buffer pool, if it is used in the next page, you do not need to read the disk, read directly from the memory.

But if you do not sort, you may read the data after the first page, go read the first page data 2,3,4, then you have to go read the data of the first page, then you find 1 data page, has been excluded from the cache, so they have to go to disk to read the data on page 1.

Converted into sequential reading, you will continuously use the data of the first page, this time in accordance with the caching mechanisms eliminate MySQL, the cache of the page will not fail until you're done with the data on this page, as is sequential read, in the course of the rest of the query, you sure will not use the data to this page, and the pages can be said to say good-bye.

Sequential read is through these three areas, the largest optimize the reading of the index.

Do not forget, the index itself is to reduce disk IO, speed up queries, and MRR, the index is to reduce the role of disk IO, further amplification.

 

Some configuration on the revolution

MRR and related configuration has two:

• mrr: on/off

• mrr_cost_based: on/off

The first is used when the above presentation, a switch for opening MRR:

mysql > set optimizer_switch='mrr=on';

If you do not open, the MRR is certainly not used.

Another, is used to tell the optimizer, or not based on the cost of using the MRR, consider using MRR whether it is worth (cost-based choice), to determine the specific sql statement in whether or not to use the MRR.

Clearly, for a query returns only one row of data, MRR is not necessary, but if you put mrr_cost_based set off, that the optimizer will use all MRR, which in some cases is very stupid, so this configuration is recommended set on, after all, in most cases, the optimizer is correct.

There is also a configuration read_rnd_buffer_size, is used to set the memory size to rowid for sorting.

Apparently, MRR is a space for time algorithm in nature. rowid row MySQL can not give you unlimited memory to be sorted, if read_rnd_buffer full, the first full of good order to read the disk, then empty, then fill it continues to put rowid, until they reached read_rnd_buffe configuration read_rnd_buffer the upper limit, and so on.

end

You could not see out, MRR have a great relationship with the index.

The index is made of a MySQL query optimization, data originally chaotic, with orderly structure to organize themselves so that a full table scan become rules-based queries.

And we are talking about MRR, is a MySQL optimization of index-based queries to do, it can be said to optimize optimized.

To optimize MySQL queries, we have to first know the MySQL query process; and to optimize query the index, the index will have to know the principles of MySQL.

Like before "in how to learn MySQL ," Lane said, to optimize a technology, learn to tune, first of all have to understand how it works, both of which are different Level.

 

Transfer from -https: //mp.weixin.qq.com/s/1duffrGhNq_DzMSYrbCdhw