Author: Dian ordinary world
Source: SQL database development
When it comes to SQL indexes, everyone knows that it was born to improve query efficiency. But in the query process, how can we make our query statement use the index? Everyone will encounter this problem more or less. Today we will answer this question.
1, clustered index and non-clustered index
Indexes are generally divided into clustered indexes and non-clustered indexes.
The clustered index is fast, but only one can be built, so try to build a clustered index for frequently used columns.
Although a non-clustered index is not as fast as a clustered index, it can be built multiple times, which is faster than a full table scan.
2. How to build an efficient index
A. Create an index on the associated conditions
E.g:
SELECT * FROM T1
JOIN T2 ON T1.ORDER_ID=T2.ORDER_ID;
The two columns after the association condition ON can be indexed separately, so that the data that meets the association condition will be queried quickly.
B. Create index on conditional query
E.g:
SELECT * FROM T1
WHERE T1.PRICE>20;
Indexes can be created on the WHERE condition PRICE column.
Note: Indexes will not be used in the following situations
- Operators are used on the index column, for example: T1.PRICE*0.5>20, this will not use the index
- If a function is used on the index column, for example: UPPER(T1.ADDRESS)='NEWYORK', the index will not be used
- When using the index, there is a NULL value, such as: T1.ADDRESS IS NULL, then the index will not be used when querying
- Character data does not include quotation marks and will not use indexes. For example: ORDER_ID is originally a character type, T1.ORDER_ID='112' will use the index, but if you remove the quotation marks, it becomes T1.ORDER_ID=112, and the query statement will not report an error. But the index will not be used.
- Or (OR), unequal (<>,!=) and NOT IN, etc. will not use indexes
- The frequently used LIKE, except for the pre-match, the other matches are not indexed. For example: T1.ADDRESS LIKE'NEW%', this is indexed, but like T1.ADDRESS LIKE'%NEW%' and T1.ADDRESS LIKE'%NEW 'Then do not take the index
- Finally, if the query optimizer judges that the full table scan is faster than the index, it will not use the index.
C. Principles of indexing
- Columns that are not frequently written and updated are suitable for indexing
- Frequently queried columns are suitable for indexing
- Indexes with less duplicate data can be established
D. The magical effect of the joint index
A joint index is a combination of several columns to form an index, which will have unexpected effects compared to a single-column index in the WHERE condition.
E.g:
SELECT * FROM T1 WHERE T1.CITY='Beijing' AND T1.DISTR='Haidian District';
At this time, the columns CITY and DISR are established as a joint index, the effect will be better.
Note: The joint index needs to go in order. If an index in the middle cannot be used, the columns after it will not use the index.
E.g:
SELECT * FROM T1
WHERE T1.CITY='Beijing'
AND LEFT(T1.DISTR,3)='Haidian District'
AND T1.ROAD='#10'
If we create CITY, DISR, and ROAD as a joint index, due to the pre-index rules, only CITY will be indexed, and the following DISR will fail because of the use of functions, and the final ROAD column will also become invalid due to the failure of DISR. Just remember it here.
3. What circumstances are not suitable for indexing
Since it takes time to create and maintain an index, the time increases in proportion to the increase in data; it needs to take up physical space; when the data in the table is maintained, the index should also be maintained, which reduces the maintenance of the data speed. Based on these shortcomings, the following situations are not suitable for indexing
- For columns that are rarely used or referenced in the query process, indexes should not be created.
- For columns with very few data values, you should not create indexes, such as gender.
- For columns defined as image, text, and bit data types, indexes should not be created.
- When the modification performance is much greater than the retrieval performance, indexes should not be built.
- Many duplicate values are not suitable for indexing.