Using IN in MySQL will not go through index analysis and solutions

One: Analyze why all MySQL In queries do not take effect

Conclusion: IN will definitely follow the index, but when the value range of IN is large, it will lead to Invalid index, go full table scan

navicatThe visualization tool uses the explain function to view sql execution information

1.1 Scenario 1: When the value in IN has only one primary key

We only need to pay attention to one of the most important types of information. It is obvious whether the withdrawal uses the index:

The type result value in order from good to bad is:

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

all:full table scan

index: Another form of full table scan, but his scan method is in the order of the index

range: Index scan with a range. Compared with the full table scan of index, it has a range limit, so it is better than index

ref: The search condition column uses an index and is not the primary key and unique.In fact, it means that although the index is used, the value of the index column is not unique and there are repetitions.In this way, even if the index is used to quickly find the first piece of data, it still cannot be stopped, and a small range scan near the target value must be performed.But its advantage is that it does not need to scan the entire table, because the index is ordered, and even if there are duplicate values, it is scanned in a very small range.

const: Normally, if a primary key is placed behind where as a conditional query, the mysql optimizer can convert this query optimization into aconstant.How and when to convert depends on the optimizer

Generally speaking, it is necessary to ensure that the query reaches at least the range level, preferably ref. When index and all appear in the type, it means that the full table scan is performed without the index, which is inefficient. At this time, the SQL needs to be tuned..

When the Using filesor or Using temproary appears in the extra, it means that the index cannot be used and must be optimized as soon as possible.

possible_keys: the index used by sql

key: Displays the key (index) that MySQL actually decided to use.If no index is selected, the key is NULL

rows: Displays the number of rows that MySQL thinks it must examine when executing the query.

1.2 Scenario 2: Expand the value range in IN

At this time, the index is still gone, but the efficiency is reduced

1.3 Scenario 3: Continue to expand the value range of IN

Looking at the above figure, I found that there is no index at this time, but a full table scan.

I'm talking about the conclusion

Conclusion: IN will definitely go through the index, but when the value range of IN is large, the index will be invalid, and a full table scan will be performed.

By the way: If not in is used, the index is not taken.

Second: What should I do if MySQL needs IN query but it is very slow?

From the above, we know that our IN query index does not take effect and why it does not take effect.

2.1 This is a common IN query

SELECT id, order_index, data_order_start, update_time, create_time, gov_frame_idFROM gov_price_category_detailWHEREgov_frame_id IN (SELECT id FROM gov_price_frame WHERE deleted=1 AND is_spider=0 AND city IN ( 'Changsha City' ) GROUP BY id)AND deleted=1AND data_order_start < 51 

2.2 We transform IN query into inner query

SELECT gcd.id, gcd.order_index, gcd.data_order_start, gcd.update_time, gcd.create_time, gcd.gov_frame_idFROM gov_price_category_detail gcd , ( SELECT gp.id FROM gov_price_frame gp WHERE gp.deleted=1 AND gp.is_spider=0 AND gp.city IN ( 'Changsha City' ) GROUP BY gp.id ) gpfWHEREgpf.id = gcd.gov_frame_idAND gcd.deleted=1AND gcd.data_order_start < 51 

3.3 optimized speed comparison

Raw SQL speed information:

Optimized SQL speed information: