MYSQL tuning index-index analysis

One, single table index

Found the problem: The query typeis ALLthat there is a full table scan problem, the index is not used, and there Using filesortis a sorting problem within the file that needs to be optimized.

Start optimization:

1. Create a compound index

ALERT TABLE ' article' ADD INDEX index_article_ccv ('category_id','comments','views')
或者
create index  index_article_ccv on article('category_id','comments','views')

Analysis: the actual use of the composite index, typeis range, but there are still exists Using filesort, the paper scheduling. comments>1Here is the range. After the range index will lead to invalidation-will be dealt with in detail later.
It indicates that the currently created index is not suitable, because there is a comments>1range query, which causes sorting within the file.

Specific execution analysis:

• It is acceptable that the type is range, but it exists in extra Using filesort, and the sorting problem within the file is still unacceptable, but why is the index we created useless?
• Because we follow the Btree working principle, sort first category_id, if they encounter the same, category_idthen sort comments, if they encounter the commentssame, then sort the views
• When the commentsfield is in the middle position in the joint index, because the comments>1condition is a range value, mysql cannot use the index to retrieve the subsequent views part, that is, the index behind the range type query field is invalid.

solve

Bypass the comments index to re-index, delete the previously created index, create a new index,

create index  index_article_ccv on article('category_id','views')

Two, two tables

1. Left connection

Full table scan if no index is used

Start optimization:

• Add index to the right table The
  
  left table is index retrieval, the right table is full table scan
• Delete the right table index, add the left table index
  

After analysis

Obviously the left join the right table to add index effect is better (ref> index). This is because the LEF JOINcondition determined by the characteristics of the left connection is used to determine how to search for rows from the right table, there must be left. Therefore, the left connection plus the right table.

2. Right connection

Because the RIGHT JOINcondition is used to determine how to search for rows from the left table, there must be both on the right, so the left is the key point must be indexed.

to sum up:

Left join, index builds right table; right join index plus left table.

Three, three table connection

1. Left connection of three tables

Full table scan

• Index
  
• Execution results The
  
  last two typeare both refand the rows optimization is very good, the effect is good. Therefore, the index is best set in the field that needs to be frequently queried

to sum up:

• Reduce the number of NestedLoop cycles in the join statement as much as possible: "Always small result sets drive large result sets"-small tables drive large tables
• Optimize inner loop of NestedLoop (nested loop)
• Ensure that the join condition field on the driven table in the join statement has been indexed
• When the join condition field of the driven table cannot be guaranteed to be indexed and the memory resources are sufficient, do not skimp on the setting of joinbuffer.