SQL Optimization Scheme Reference

In order to improve query efficiency in sql query, some measures are often taken to optimize the query statement. The following are some methods for reference:

1. To optimize the query, full table scan should be avoided as much as possible. First, you should consider building indexes on the columns involved in where and order by.	
	
2. Try to avoid the null value judgment of the field in the where clause, otherwise the engine will give up the use of the index and perform a full table scan, such as:	
select id from t where num is null	
You can set a default value of 0 on num, make sure there are no null values ​​in the num column in the table, and then query like this:	
select id from t where num=0	
	
3. Try to avoid using the != or <> operator in the where clause, otherwise the engine will give up the use of the index and perform a full table scan.	
	
4. Try to avoid using or to join conditions in the where clause, otherwise it will cause the engine to give up using the index and perform a full table scan, such as:	
select id from t where num=10 or num=20	
You can query like this:	
select id from t where num=10	
union all	
select id from t where num=20	
	
5. In and not in should also be used with caution, otherwise it will result in a full table scan, such as:	
select id from t where num in(1,2,3)	
For consecutive values, use between instead of in:	
select id from t where num between 1 and 3	
	
6. The following query will also result in a full table scan:	
select id from t where name like '%abc%'	
	
7. The expression operation on the field in the where clause should be avoided as much as possible, which will cause the engine to give up the use of the index and perform a full table scan. Such as:	
select id from t where num/2=100	
Should be changed to:	
select id from t where num=100*2	
	
8. The function operation on the field in the where clause should be avoided as much as possible, which will cause the engine to give up the use of the index and perform a full table scan. Such as:	
select id from t where substring(name,1,3)='abc'--the id whose name starts with abc	
Should be changed to:	
select id from t where name like 'abc%'	
	
9. Do not perform functions, arithmetic operations or other expression operations on the left side of the "=" in the where clause, otherwise the system may not be able to use the index correctly.	
	
10. When using an index field as a condition, if the index is a composite index, the first field in the index must be used as a condition to ensure that the system can use the index.	
Otherwise the index will not be used, and the field order should be as consistent as possible with the index order.	
	
11. Don't write some meaningless queries, such as generating an empty table structure:	
select col1,col2 into #t from t where 1=0	
This kind of code will not return any result set, but will consume system resources, it should be changed to this:	
create table #t(...)	
	
12. Many times it is a good choice to use exists instead of in:	
select num from a where num in(select num from b)	
Replace with the following statement:	
select num from a where exists(select 1 from b where num=a.num)	
	
13. Not all indexes are valid for queries. SQL optimizes queries based on the data in the table. When a large amount of data in the index column is repeated, the SQL query may not use the index.	
If there are fields sex in a table, male and female are almost half and half, then even if an index is built on sex, it will not affect the query efficiency.	
	
14. The more indexes the better, the index can certainly improve the efficiency of the corresponding select, but it also reduces the efficiency of insert and update.	
Because the index may be rebuilt during insert or update, how to build the index needs careful consideration, depending on the specific situation.	
The number of indexes in a table should not exceed 6. If there are too many indexes, you should consider whether it is necessary to build indexes on some infrequently used columns.	
	
15. Try to use numeric fields. If the fields only contain numeric information, try not to design them as character fields, which will reduce the performance of query and connection and increase the storage overhead.	
This is because the engine compares each character of the string one by one when processing queries and joins, whereas only one comparison is required for numbers.	
	
16. Use varchar instead of char as much as possible, because the storage space of variable-length fields is small at first, which can save storage space,	
Secondly, for the query, the search efficiency in a relatively small field is obviously higher.	
	
17. Do not use select * from t anywhere, replace "*" with a list of specific fields, and do not return any fields that are not used.	
	
18. Avoid frequent creation and deletion of temporary tables to reduce the consumption of system table resources.

19. Temporary tables are not unusable, and their proper use can make certain routines more efficient, for example, when a large table or a dataset in a frequently used table needs to be repeatedly referenced. However, for one-time events, it is better to use an export table.	
	
20. When creating a new temporary table, if a large amount of data is inserted at one time, you can use select into instead of create table to avoid causing a large number of logs.	
In order to improve the speed; if the amount of data is not large, in order to ease the resources of the system table, you should first create the table, and then insert.

21. If temporary tables are used, all temporary tables must be explicitly deleted at the end of the stored procedure, first truncate table, and then drop table, which can avoid long-term locking of system tables.	
	
22. Try to avoid using the cursor, because the efficiency of the cursor is poor, if the data operated by the cursor exceeds 10,000 rows, then you should consider rewriting.	
	
23. Before using the cursor-based method or the temporary table method, you should look for a set-based solution to solve the problem, and the set-based method is usually more efficient.

24. Like temporary tables, cursors are not unusable. Using FAST_FORWARD cursors on small datasets is often preferable to other row-by-row processing methods, especially when several tables must be referenced to obtain the required data.
在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。

25.尽量避免大事务操作,提高系统并发能力。

26.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324440592&siteId=291194637