Catch all kinds of locks of MySQL in one go
series of articles
2. Lifelong friends redo log, binlog "Deadly Kick MySQL Series II"
3. It is difficult for MySQL strongman to "lock" "Deadly Kick MySQL Series III"
4. The love-hate relationship between S lock and X lock "Deadly Kick MySQL Series 4"
5. How to choose ordinary index and unique index "Deadly Kick MySQL Series V"
If you are not clear about the knowledge points of the index, you can directly view the index knowledge points summarized by Kaka through the portal.
The index is to speed up the query speed, and the created index also conforms to all the rules, but MySQL just does not use the ideal index, resulting in slower query speed and a large number of slow query records.
Today, I will talk about what MySQL does when selecting indexes from this question.
1. How to choose an index
Several factors that affect the optimizer
A query SQL execution needs to go through connectors, analyzers, optimizers, and executors, and the task of selecting indexes is left to them 优化器.
The optimizer chooses among multiple indexes in order to find the solution with the lowest execution cost.
There are only a few factors that affect the optimizer selection, such as the number of rows scanned, whether temporary tables are used, and whether file sorting is used.
The two points of temporary table and file sorting will be slowly introduced to you in the later article. Today we only talk about the number of scanned rows.
The fewer the scan lines, the fewer times the disk data is accessed, and the less CPU resources are consumed.
So where is this scan line number taken from?
Where does the scan line count come from?
Creating an index has always advocated that you build an index on a column with a high degree of discrimination. The number of different values in an index is called cardinality.
Use show index from table_name to see what the cardinality of each index is.
How to calculate the index cardinality
MySQL uses the method of sampling statistics to select N data pages, each of which is 16kb in size, and then counts the different values on the selected data pages to obtain an average value, which is multiplied by the number of pages in the index. The result obtained is the cardinality of this index.
Table data is continuously added or deleted, and the statistical data does not change from time to time. When the changed data exceeds 1/M, recalculation is automatically triggered.
This M is selected according to the value of the parameter innodb_stats_persistent, which is set to 10 for on and 16 for off.
The index cardinality is calculated this way is not exact but not by much
Why did the optimizer choose the index with the most rows to scan?
first case
Table additions and deletions are very frequent, resulting in an inaccurate number of scanned rows
second case
Suppose your primary key index scans 10W rows, while a normal index needs to scan 5W rows. In this case, the optimizer will choose a larger number of scan rows.
In the article on the index, it is known that the primary key index does not need to be returned to the table, and the corresponding data is returned directly when the value is found.
The ordinary index needs to obtain the primary key value first, and then obtain the corresponding data according to the primary key value. In this process, the optimizer needs to calculate a cost when selecting the index.
How to fix this situation
When the number of scanned rows is inaccurate, you can execute the analyze table table_namecommand to re-statistics the index information to achieve the desired index selected by the optimizer.
2. How to handle index selection exceptions
Option One
Provided in MySQL force indexto force the optimizer to use this index.
How to use: select * from table_name force index (idx_a) where a = 100;
But don't misunderstand the use of force index. I saw such a case in the code before. The function operation was used for the query column, so that the index could not be used. Then this buddy will directly use the force index, which definitely won't work!
This solution can be used when the optimizer does not choose the index correctly.
shortcoming
The disadvantage of using force index is that everyone knows that it is too rigid. Once the index name is changed, it will become invalid.
Option II
Deleting the wrongly selected index is simple and rude. Many index establishments are actually a misleading thing for the optimizer, so just delete them directly.
third solution
Modify the SQL statement to actively guide MySQL to use the desired index. In general, this practice is rarely used unless you are very familiar with the system, otherwise try to operate as little as possible.
3. Summary
The optimizer chooses an index first based on the number of rows scanned and then by the execution cost.
Use analyze table to resolve when index statistics are inaccurate.
The optimizer selects the wrong index, and only uses the force index to quickly correct it, and then guides the optimizer to select the correct index by optimizing the SQL statement. The most violent method is to directly delete the wrongly selected index.
Persistence in learning, perseverance in writing, perseverance in sharing are the beliefs that Kaka has upheld since her career. I hope the article can bring you a little help on the huge Internet, I am Kaka, see you in the next issue.