Explain several situations of MySQL index failure in detail

MySQL index is an important means to improve query efficiency. Index failure will lead to a drop in query efficiency, or even a full table scan, affecting database performance. The following are situations that can cause MySQL indexes to fail:

1. Use the or operator

When the operator is used in the where orstatement and orthe conditions on both sides involve at least two fields, MySQL cannot use the index and will turn to a full table scan. Therefore, the or operator should be avoided as much as possible.

Reason: Because the index in MySQL is sorted and established according to a certain field. When using oran operator, it means that there are two conditions and one of the conditions is true. When we use an index, we can only judge whether the condition of the corresponding field is true. Even if it is not true, the record meets our requirements when the other condition is true. The result of the query. So using the index cannot make a judgment.

example:

-- id is the primary key index
EXPLAIN SELECT * FROM test WHERE id > 1 OR `name` = 'zs';

 

It can be seen that the type is ALL: full table scan

EXPLAIN SELECT * FROM test WHERE id > 3 OR id < 1;

 

It can be seen that the type is PRIMARY: the primary key index is used;

2. Composite index failure

If a composite index is used, but the first column of the index is not used in the query, the index will also fail.

Reason: For example, if we create a composite index based on the fields (t1, t2, t3), the sorting rule is to sort by the t1 field first, and then sort by the t2 field when the t1 field is the same, and then sort by the t3 field when the t1 and t2 fields are the same Sort. If the first column is not used in our query conditions, then the index cannot be used.

example:

-- t1, t2 columns have established a matching index
EXPLAIN SELECT * FROM test WHERE t1 = '1' AND t2 = '2';

  

It can be seen that the type is ref: the secondary index is used; (when using the secondary index to list constants for equivalent comparison, the access method is ref)

-- The first column t1 of the unused index
EXPLAIN SELECT * FROM test WHERE t2 = '1';

  

It can be seen that the type is ALL: full table scan

3. like query

If like is used and starts with %, the index will be invalid.

Reason: Fuzzy queries are generally used on string fields, and the sorting rules of strings are alphabetical sorting. If it starts with %, it means that the previous characters can be any, and the index cannot be used.

example:

EXPLAIN SELECT * FROM test WHERE t1 LIKE '1%';

 

It can be seen that the type is range: use the secondary index for range query.

EXPLAIN SELECT * FROM test WHERE t1 LIKE '%1';

 

It can be seen that the type is ALL: full table scan

4. Using functions on indexed columns

Reason: Because the index saves the original value of the index field, not the value calculated by the function, naturally there is no way to use the index.

explain select * from test where length(t1) = 2;

  

5. Implicit type conversion

Implicit type conversion rules:

  • If one or both arguments are NULL, the result of the comparison is NULL, except for the safe <=> equality comparison operator. The result is true for NULL <=> NULL. No conversion is required.

  • If both arguments in the comparison operation are strings, they are compared as strings.

  • If both arguments are integers, they are compared as integers.

  • Hexadecimal values ​​are treated as binary strings if they are not compared to numbers.

  • If one of the arguments is a decimal value, the comparison depends on the other argument. If the other argument is a decimal or integer value, the argument is compared with the decimal value, and if the other argument is a floating-point value, the argument is compared as a floating-point value (without converting the integer type to a floating-point type).

  • If one of the arguments is a TIMESTAMP or DATETIME column and the other is a constant, convert the constant to a timestamp before performing the comparison.

  • In all other cases the arguments are compared as floats (doubles).

Implicit type conversion will cause the index to fail. For example, when the field type is a string and an index is built, and the query condition type is a value, the string type will be implicitly converted to a floating point type, and the index will become invalid.

Reason: The cast function will be used to convert the string type to a floating point number. At this time, the function is used on the index column, causing the index to become invalid.

EXPLAIN SELECT * FROM test WHERE t1 = 1.1;

  

6. Computing expressions on indexes

Reason: Because the index saves the original value of the index field, not the value calculated by the id + 1 expression, the index cannot be used. It can only be performed by extracting the value of the index field and then calculating the expression Conditional judgment, so the method of full table scan is adopted.

-- The num field has a secondary index
EXPLAIN SELECT * FROM test WHERE num = 1 + 10;

 

EXPLAIN SELECT * FROM test WHERE num + 1 = 10;

 

Guess you like

Origin blog.csdn.net/m0_57614677/article/details/129269023