Several cases of index failure

This article is just personal notes , If there is any error, please remind me

The best left prefix rule

The right side of the range query is invalid

like Index invalidation principle

Index invalidation caused by implicit conversion

Look at this watch

CREATE TABLE `test1` (
    `id` int(11) NOT NULL,
    `num1` int(11) NOT NULL DEFAULT '0',
    `num2` varchar(11) NOT NULL DEFAULT '',
    PRIMARY KEY (`id`),
    KEY `num1` (`num1`),
    KEY `num2` (`num2`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

SQL test
Take a look at this group first SQL, There are four , Our test data sheet num1 yes int type ,num2 yes varchar type , But the stored data is related to the primary key id The same sequence of numbers , Both fields are indexed .

1: SELECT * FROM `test1` WHERE num1 = 10000;
2: SELECT * FROM `test1` WHERE num1 = '10000';
3: SELECT * FROM `test1` WHERE num2 = 10000;
4: SELECT * FROM `test1` WHERE num2 = '10000';

among 124 Three SQL Basically, the results are instantaneous , In about 0.001 ~ 0.005 second , With tens of millions of data, such a result can determine these three SQL The performance is basically the same . But third SQL, Many tests are basically time-consuming 4.5~4.8 Between seconds .
Why? 34 Two article SQL The efficiency difference is so big , But the same comparison 12 Two article SQL But it doesn't make any difference ？ Take a look at the implementation plan , Bottom respectively 1234 strip SQL Execution plan data ：
You can see ,124 Three SQL Can use the index , The connection types are ref, The number of scanning lines is 1, So it's very efficient . Look at the third SQL, No index , So scan for the whole table ,rows Directly to 1000 All the , So the performance difference is so big .
Look up MySQL The discovery of related documents is caused by implicit transformation , Look at the official description ：

Official documents ： 12.2 Type Conversion in Expression Evaluation
When operators are used with different types of operands , Type conversion occurs to make operands compatible . Some transformations occur implicitly . for example ,MySQL It will automatically convert strings into numbers as needed , vice versa . The following rules describe how the comparison operation is converted ：

1. At least one of the two parameters is NULL when , The result of the comparison is NULL, The special case is to use <=> The two one. NULL When making a comparison, it will return 1, There is no need for type conversion in either case
2. Both parameters are strings , Compare by string , No type conversion
3. Both arguments are integers , Compare... By integers , No type conversion
4. When comparing hexadecimal values with non numeric values , It will be treated as a binary string
5. One parameter is TIMESTAMP or DATETIME, And the other parameter is constant , Constants are converted to timestamp
6. One parameter is decimal type , If the other parameter is decimal Or an integer , Will convert integers to decimal Then compare , If the other parameter is a floating-point number , It will put decimal Convert to floating point for comparison
7. In all other cases , Both parameters are converted to floating-point numbers for comparison
   According to official documents , Our first 23 Two article SQL Implicit conversion has taken place , The first 2 strip SQL Query criteria for num1 = ‘10000’, On the left is int To the right of the type is the string , The first 3 strip SQL contrary , Then according to the official conversion rule No 7 strip , Both left and right sides will be converted to floating-point numbers for comparison .

First look at the 2 strip SQL：SELECT * FROMtest1WHERE num1 = ‘10000’; On the left for int type 10000, Convert to floating point number or 10000, Right string type ’10000’, Converting to floating point numbers is also 10000. The conversion results of both sides are unique , So it does not affect the use of indexes .

The first 3 strip SQL：SELECT * FROMtest1WHERE num2 = 10000; On the left is the string type ’10000’, Convert floating point number to 10000 Is the only one. , On the right int type 10000 The conversion result is also unique . however , Because on the left is the search condition ,‘10000’ go to 10000 Although it is the only , But other strings can also be converted to 10000, such as ’10000a’,‘010000’,'10000’ And so on can be converted to floating point numbers 10000, In this case , You can't use indexes .
The rules found by consulting relevant materials are as follows ：

1. Strings that do not begin with a number will be converted to 0. Such as ’abc’、‘a123bc’、'abc123’ Will be transformed into 0;
2. String conversion starting with a number will be intercepted , Intercept from the first character to the first non numeric content . such as ’123abc’ Will be converted to 123,'012abc’ Will be converted to 012 That is to say 12,'5.3a66b78c’ Will be converted to 5.3, Others in the same way .

Analyze and summarize

Through the above test, we found that MySQL Use some features of operators ：

1. When the data types on the left and right sides of the operator are inconsistent , There will be implicit conversions .
2. When where Implicit conversion occurs when the left side of the query operator is a numeric type , Then it has little effect on efficiency , But it is still not recommended .
3. When where Implicit conversion occurs when the left side of the query operator is a character type , Then the index will be invalidated , The scanning efficiency of the whole meter is extremely low .
4. When a string is converted to a numeric type , Strings that do not begin with numbers are converted to 0, A string beginning with a number will intercept the value from the first character to the first non numeric content as the conversion result .

therefore , We're writing SQL We must form good habits when we are young , What type of fields are queried , The condition to the right of the equal sign is written as the corresponding type . Especially when the query field is a string , The condition to the right of the equal sign must be caused by quotation marks to indicate that this is a string , Otherwise, it will cause index failure and trigger full table scan .

Different character sets and sorting rules lead to index invalidation

Other ：

1. It's best to match all values
2. Don't do anything on the index （ Calculation 、 function 、 Automatically / Manual type conversion ）, Otherwise, it will lead to index invalidation and turn to full table scan

explain select * from ti where b+1=5;  --  The field operation cannot be indexed 

3. Try to use overlay index （ Query only indexed columns （ The index column is consistent with the query column ））, Reduce select *
4. Use... On index fields （！= perhaps < >） When judging , It will cause index invalidation and turn to full table scan
5. Use... On index fields is null / is not null When judging , It will cause index invalidation and turn to full table scan
6. Index fields use or when , It will cause index invalidation and turn to full table scan