SQL statement performance optimization strategy
1. Create indexes on the columns involved in WHERE and ORDER BY
To optimize the query, try to avoid full table scan, first consider building indexes on the columns involved in WHERE and ORDER BY
2. Where use the default value instead of null
Try to avoid judging the NULL value of the field in the WHERE clause. NULL is the default value when creating a table, but most of the time you should use NOT NULL, or use a special value, such as 0, -1 as the default value.
There are four reasons why it is recommended to use default values instead of null in where:
- It does not mean that if you use is null or is not null, you will not use the index. This is related to the mysql version and the query cost;
- If the mysql optimizer finds that the cost of using the index is higher than that of not using the index, it will give up the index. These conditions! =, <>, is null, and is not null are often considered to invalidate the index;
- In fact, it is because under normal circumstances, the query cost is high, and the optimizer automatically abandons the index;
- If you replace the null value with the default value, it is often possible to go to the index, and at the same time, the expression is relatively clear;
3. Use != or <> operators with caution.
MySQL only uses indexes for the following operators: <, <=, =, >, >=, BETWEEN, IN, and sometimes LIKE. So: try to avoid using the != or <> operator in the WHERE clause, which will cause a full table scan.
4. Use OR with caution to connect conditions
Using or may invalidate the index, thus full table scan; try to avoid using OR in the WHERE clause to connect conditions, otherwise it will cause the engine to give up using the index and perform a full table scan.
5. Use IN and NOT IN with caution
IN and NOT IN should also be used with caution, otherwise it will cause a full table scan. For continuous values, use BETWEEN instead of IN: select id from t where num between 1 and 3.
6. Use left blurring like '%…' with caution
For fuzzy query, the favorite of programmers is to use like, which is likely to invalidate the index. for example:
select id from t where name like‘%abc%’
select id from t where name like‘%abc’
The select id from t where name like'abc%' only uses the index.
so:
- First of all, try to avoid fuzzy query. If you must use it, instead of using full fuzzy query, you should try to use right fuzzy query, that is, like '...%', which will use the index;
- Left fuzzy like '%...' cannot directly use the index, but can use the form of reverse + function index to change into like '...%';
- Fully fuzzy queries cannot be optimized. If you must use them, it is recommended to use search engines, such as ElasticSearch.
7. The use of parameters in the WHERE condition will cause a full table scan.
The following statement will perform a full table scan:
select id from t where num=@num
Because SQL will only resolve local variables at runtime, but the optimizer cannot defer the selection of access plans until runtime;
It must be selected at compile time. However, if the access plan is established at compile time, the value of the variable is still unknown and thus cannot be used as an input for index selection.
So, you can instead force the query to use the index:
select id from t with(index(索引名)) where num=@num
8. Avoid WHERE expression operations/function operations on fields
Any operation on the column will result in a table scan, which includes database functions, calculation expressions, etc. You
should try to avoid performing expression operations on fields in the WHERE clause, and try to avoid performing function operations on fields in the WHERE clause .like:
select id from t where num/5=100
应改为:
select id from t where num=100*5
You should try to avoid performing function operations on fields in the where clause, which will cause the engine to give up using indexes and perform full table scans. like:
select id from t where substring(name,1,3)=‘abc’
select id from t where datediff(day,createdate,‘2022-11-30’)=0
应改为:
select id from t where name like ‘abc%’
select id from t where createdate>=‘2022-11-30’ and createdate<‘2022-12-1’
9. It is a good choice to use EXISTS instead of IN
Many times it is a good choice to use exists instead of in
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
10. Try not to use select * to query SQL, but specific fields
It is best not to use return all: select * from t, replace "*" with a specific list of fields, and do not return any fields that are not used. Disadvantages of select *:
(1) Add a lot of unnecessary consumption, such as CPU, IO, memory, network bandwidth;
(2) Added possibility to use covering index;
(3) The possibility of returning to the form is increased;
(4) When the table structure changes, the front end also needs to be changed;
(5) Low query efficiency;