Preface
There are many reasons for index failure in daily work. This requires continuous accumulation and continuous learning in order to play the role of the index more correctly. Here is a brief summary of some reasons for index failure.
1. Implicit type conversion, index failure
select * from test where num=13911111111; # 失效，num字段是varchar类型，没有加引号
Assume that a mobile phone number column is created as num varchar(15).
If the above mobile phone number is not quoted, the query will be a comparison of strings and numbers. Their types do not match. MySQL will perform implicit type conversion to convert them. Compare again for floating point numbers. Implicit type conversion, the index will be invalid.
2. The query condition contains or, which may cause index failure.
select * from test where mul=1 or noidx=2; # 可能失效，当mul设为索引列而noidx不是索引列时
Index + or + non-indexed column: The index column will be scanned first, but the non-indexed column will be scanned in the whole table, so it is better to scan the whole table directly without using the index. If there are indexes before and after or, then the index may or may not be used.
If it performs a full table scan at the beginning, it will be done with one scan. For the sake of efficiency and cost, the Mysql optimizer will invalidate the index when encountering the or condition, which seems reasonable.
Use or to connect two null index fields without indexing. However, a single index contains null fields and is indexed.
Note: If the columns of the OR condition are all indexed, the index may or may not be used. When you use it, you should still pay attention to this OR and learn to use explain analysis. When encountering problems with indexing, consider splitting the two SQLs.
3. The like wildcard may cause index failure.
It is not that the index will be invalid if the like wildcard is used, but that the like query starts with %, which will cause the index to fail.
4. The query conditions do not satisfy the leftmost matching principle of the joint index.
When MySQl establishes a joint index, it will follow the leftmost prefix matching principle, that is, leftmost priority. If you create a joint index on (a, b, c), it is equivalent to creating three indexes (a), (a, b), and (a, b, c).
5. Use mysql’s built-in function on the index column login_time
select * from user where DATE_ADD(login_time,INTERVAL 1 DAY) = '2022-11-08 00:00:00'; # 失效
select * from user where login_time = DATE_ADD('2022-11-08 00:00:00',INTERVAL 1 DAY); # 有效
6. Perform column operations (such as +, -, *, /) on the index column age, and the index will not take effect.
select * from user where age-1 = 39; # 失效
7. If you use (!= or < >, not in) on the index field age, the index may become invalid.
select * from user where age != 18; # 有可能失效
In fact, this is also related to the mySQL optimizer. If the optimizer feels that even if the index is used, it still needs to scan many, many rows, it feels that it is not cost-effective, so it is better not to use the index directly. We usually use it! = or < >, be careful when not in.
8. If you use is null or is not null on the index field, the index may be invalid (the number of rows in the query result). In
many cases, the MySQL optimizer gives up indexing due to data volume issues. At the same time, when we usually use explain to analyze SQL, we should pay attention if type=range, because this may cause the index to be invalid due to data volume issues.
9. For left and right join connections, the associated field encoding formats are different.
For example, the name field encoding of the user table is utf8mb4, while the name field encoding of the user_job table is utf8.
10. The index itself fails.
Although the index has the ability to self-maintain, if the content of the data table is frequently modified and updated, the index may also fail. In this case, the index needs to be deleted and re-established.
Summary:
There are many reasons for index failure. The above is just a brief introduction. You have to analyze the specific reasons for the failure yourself. The specific method is the EXPLAIN keyword of the SQL execution plan.
Mysql provides this keyword to allow us to optimize the index, make the query faster, analyze the optimizer's table connection, and make it use the optimal order. Use the explain keyword to check whether the query statement has been indexed and which index it has been.
# 命令行执行以下语句即可查看查询语句是否走了索引，在查询语句最前面加上 explain 即可
mysql> explain select * from sampleInfo where agents = "XXX中心有限公司";
The key in the figure below indicates that the statement uses index agents. If the key in the figure below is NULL or the type is ALL, it means that the statement is not indexed and needs to be optimized.
