MYSQL5.6 5.7deals with the problem of uneven distribution of data
This article mainly talks about "MYSQL5.6 5.7dealing with the problem of uneven distribution of data". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "MYSQL5.6 5.7 deals with the problem analysis of uneven data distribution".
To deal with the uneven distribution of data, the orace database uses additional statistical histograms, while MYSQL
If there is only one statistical data such as the different values of the index, then we produce the following data:
Mysql > select * from test.testf
+-+ +
| | id | name |
+-+ +
| | 1 | gaopeng |
| | 2 | gaopeng1 |
| | 3 | gaopeng1 |
| | 4 | gaopeng1 |
| | 5 | gaopeng1 |
| | 6 | gaopeng1 |
| | 7 | gaopeng1 |
| | 8 | gaopeng1 |
| | 9 | gaopeng1 |
| | 10 | gaopeng1 |
+-+ +
10 rows in set (0.00 sec)
There is a normal secondary index on name
Mysql > analyze table test.testf
+-+
| | Table | Op | Msg_type | Msg_text | |
+-+
| | test.testf | analyze | status | OK | |
+-+
1 row in set (0.21 sec)
The following implementation plans are made respectively:
Mysql > explain select * from test.testf where name='gaopeng'
+-- +
| | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+-- +
| | 1 | SIMPLE | testf | NULL | ref | name | name | 63 | const | 1 | 100.00 | NULL |
+-- +
1 row in set, 1 warning (0.00 sec)
Mysql > explain select * from test.testf where name='gaopeng1'
+-- +
| | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+-- +
| | 1 | SIMPLE | testf | NULL | ALL | name | NULL | NULL | NULL | 10 | 90.00 | Using where |
+-- +
1 row in set, 1 warning (0.00 sec)
You can see that the execution plan is correct, only one row of name='gaopeng' selects the index, and 9 of name='gaopeng1' walks the entire table.
In theory, if you only record different statements, then the choice of these two statements is 1 / 2, which should result in an error in the execution plan, while in MYSQL 5.65.7
They all made the right choice, so why?
Actually, the reason lies in the parameter eq_range_index_dive_limit. Let's take a look at trace.
Opt 2: | opt: (null): "gaopeng1
