Summary of several situations of MySQL index failure (reproduced)
1. Indexes do not store null values
More precisely, single-column indexes do not store null values, and compound indexes do not store all null values. The index cannot store Null, so when the is null condition is used for this column, because the index
If there is no Null value, the index cannot be used, and only a full table scan can be used.
Why can't index columns store Null values?
Building an index column value must involve many comparison operations. The particularity of the Null value is that most of the operations involved take the value of null.
In this case, the null value actually cannot participate in the indexing process. That is, null values do not appear on the leaf nodes of the index tree like other values.
2. Not suitable for columns with fewer key values (columns with more duplicate data)
If the index column TYPE has 5 key values, if there are 10,000 pieces of data, then WHERE TYPE = 1 will access 2,000 data blocks in the table.
In addition to accessing index blocks, a total of more than 200 data blocks must be accessed.
If a full table scan, assuming 10 pieces of data are one data block, then only 1000 data blocks need to be accessed, since the data blocks accessed by the full table scan
Anything less, and certainly not using indexes.
3. The leading fuzzy query cannot use the index (like '%XX' or like '%XX%')
If there is such a column of code values 'AAA', 'AAB', 'BAA', 'BAB', if the where code like '%AB' condition, because the preceding is
Fuzzy, so you can't use the order of the index, you must find them one by one to see if the conditions are met. This will result in a full index scan or a full table scan
trace. If it is such a condition where code like 'A % ', you can find the position of the CODE starting with A in the CODE, and when you encounter the CODE starting with B
When the data is found, you can stop the search, because the following data must not meet the requirements. This will make use of the index.
4. Several cases of index failure
1. If there is or in the condition, it will not be used even if there is a conditional index (this is also the reason why or should be used as little as possible)
If you want to use or and want the index to take effect, you can only add an index to each column in the or condition
2. For multi-column indexes, not the first part of use, the index will not be used
3. Like queries start with %
4. If the column type is a string, be sure to quote the data in the condition, otherwise do not use the index
5. If mysql estimates that using a full table scan is faster than using an index, do not use an index
5. MySQL mainly provides two kinds of indexes: B-Tree index, Hash index
The B-tree index has the capability of range search and prefix search. For a B-tree with N nodes, the complexity of retrieving a record is O(LogN). Equivalent to binary search.
The hash index can only do equal search, but no matter how big the hash table is, the search complexity is O(1).
Obviously, if the difference of values is large, and the equal value search (=, <, >, in) is the main method, the Hash index is a more efficient choice, and it has O(1) search complexity.
If the values are relatively indistinguishable and range lookups are dominant, a B-tree is a better choice, which supports range lookups.
1) There is no query condition, or the query condition is not indexed
2) No bootstrap column is used in the query condition
3) The number of queries is most of the big table, it should be more than 30%.
4) The index itself is invalid
5) Query conditions use functions on index columns, or perform operations on index columns, operations include (+, -, *, /, !, etc.) Wrong example: select * from test where id-1=9; Correct example : select * from test where id=10;
6) Querying small tables
7) Prompt not to use index
8) Statistics are not true
9) The case where CBO calculates the cost of walking the index is too high. In fact, it also includes the above situation, which means that the block occupied by the table is smaller than the index.
10) Implicit conversion causes the index to fail. This point should be paid attention to. It is also a mistake that is often made in development. Because the field tu_mdn of the table is defined as varchar2(20), but the field is passed as a number type in a where condition. For Oracle, this will cause the index to fail. Incorrect example: select * from test where tu_mdn=13333333333; Correct example: select * from test where tu_mdn='13333333333';
12) 1,<> 2, separate >,<, (sometimes used, sometimes not)
13,like "%_" percent sign first.
4, the table is not analyzed.
15. Separately refer to the index column that is not the first position in the composite index.
16. When the character field is a number, do not add quotation marks in the where condition.
17. Operate on the index column. You need to create a functional index.
18,not in ,not exist.
19. When the variable uses the times variable and the table field uses the date variable. Or the opposite.
20, B-tree index is null will not go, is not null will go, bitmap index is null, is not null will go
21. The joint index is not null will go as long as the established index column (in no particular order), when in null must be used with the first column of the index, when the first position condition of the index is is null, the other indexes will be established. The column can be is null (but must be null when all columns are satisfied), or = a value; when the first position of the index is = a value, other indexed columns can be any situation (including is null = a value), the index will go in both cases. Other cases will not go.
Analysis of several situations in which Mysql index will fail
Indexes do not always take effect. For example, the following situations will cause the index to fail:
1. If there is or in the condition, it will not be used even if there is a conditional index (this is also the reason why or should be used as little as possible)
Note: If you want to use or and want the index to take effect, you can only add an index to each column in the or condition
2. For multi-column indexes, not the first part of use, the index will not be used
3. Like queries start with %
4. If the column type is a string, be sure to quote the data in the condition, otherwise do not use the index
5. If mysql estimates that using a full table scan is faster than using an index, do not use an index
In addition, check the usage of the index
show status like 'Handler_read%';
you can pay attention to:
handler_read_key: the higher the value, the better, the higher the number of times the index is queried
handler_read_rnd_next: the higher the value, the less efficient the query