The following is a 30 SQL query optimization methods are widely used:
1, should be avoided in the whereuse clause !=or <>operator, otherwise the engine to give up using the index and a full table scan .
2, query optimization, should first consider whereand order byestablish an index on the columns involved, avoid full table scan .
3, should be avoided in wherethe fields using clause nullvalue determination, will cause the engine to give up using the index, and the full table scan , such as:
select id from t where num is null
You can set the default value in num 0, num ensure that no column in the table nullvalue, then this query:
select id from t where num=0
4, try to avoid the whereclause orto the join condition will cause the engine to give up using the index, while the full table scan , such as:
select id from t where num=10 or num=20
It can be used unionto query:
select id from t where num=10 union all select id from t where num=20
5, pre-percent sign inquiry will lead to a full table scan :
select id from t where name like '%abc%'
To improve efficiency, can be considered full-text search.
6, inand not inshould be used with caution, otherwise it will lead to a full table scan , such as:
select id from t where num in(1,2,3)
For continuous values, you can betweennot use inthe :
select id from t where num between 1 and 3
7, if the whereclause parameters will result in a full table scan .
Because SQL at runtime will only resolve local variables, but the optimizer can not defer the choice of access plan until runtime.
It must choose at compile time.
If, however, establish access plan at compile time, the value of the variable is unknown, and therefore can not be used as an index entry selected.
As the following statement will perform full table scan:
select id from t where num=@num
It can be changed to force the query using the index:
select id from t with(index(索引名)) where num=@num
8, should be avoided in wherethe fields using clause expression operations .
This will cause the engine to give up using the index and full table scan . Such as:
select id from t where num/2=100
Should read:
select id from t where num=100*2
9, should be avoided in wherethe fields using clause function operation .
This will cause the engine to give up using the index and full table scan . Such as:
select id from t where substring(name,1,3)='abc'–name -- 以abc开头的id select id from t where datediff(day, createdate, '2005-11-30')=0–'2005-11-30' -- 生成的id
Should read:
select id from t where name like 'abc%' select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10. Do not wherejudge equation clause =left a function, arithmetic operations, or other expressions , or the system may not use the correct index .
11, in the composite index, as the index field in use conditions,
You must use the index to the first field as the conditions to ensure the system uses the index, otherwise the index will not be used,
And should as far as possible so that field order is consistent with the index order .
12, do not write the query does not make sense, such as the need to create an empty table structure:
select col1,col2 into #t from t where 1=0
This code does not return any result sets, but consumes system resources and should be replaced by this:
create table #t(…)
13, often used existsin place inis a good choice:
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)
14, not all indexes are valid query.
SQL query optimization is performed according to data in the table, as when there is a lot of duplication of data index column, SQL queries may not go to use the index .
If a table has a field sex, male, femalealmost each half, then even in sexthe construction of the index also no effect on the query efficiency.
15, the index is not better.
Although the index can increase the corresponding selectefficiency, but also reduces insertand updateefficiency.
Because insertor updatewhen there is likely to be rebuilding the index,
So how to build an index requires careful consideration, as the case may be.
A table index number should not exceed 6one.
If too much, you should consider some of the less frequently used to build the index column if necessary.
16, should be avoided as much as possible to update clusteredthe index data columns.
Because clusteredthe physical order of the index data stored in the column is recorded in the table.
Once the column value changes, the adjustment will result in a sequence of recording the entire table, will consume considerable resources.
If applications require frequent updates clusteredindex data columns, you need to consider whether the index should be built for the clusteredindex.
17, make use of numeric fields.
If only the fields containing numerical information, try not to design for the character.
Otherwise it will reduce query performance and connections, and will increase the storage overhead.
This is because the engine when processing queries and connections, one by one each character string comparisons.
For numeric comparison purposes only once is enough.
For example, PHP can be used ip2long()and the long2ip()function to transfer IP address into an integer, and then stored into the database.
18, as far as possible using the varchar/ nvarcharplace char/nchar .
First, the variable-length fields small storage space, you can save storage space.
Secondly, by the query, in a relatively small field of search efficiency is clearly higher.
19, do not use anywhere select * from t, with a specific list of fields instead of "*", do not return any of the fields with less than.
20, to make use of the table instead of a temporary variable table.
If the table variable contains a large amount of data, please note that the index is very limited (only the primary key index).
21, to avoid the frequent create and delete temporary tables , system tables to reduce the consumption of resources.
22, the temporary table is not unusable, they can make appropriate use of certain routines more effective.
For example, when a reference to a data set to be repeated a large table or when the table used.
However, for a one-time event, it is best to use export table.
23, in the new temporary table, if one inserts a large amount of data, it may be used select intoin place create table.
This avoids causing a large number of log, increase speed.
If the amount of data, in order to ease the system table of resources, should be create table, then insert.
24, if you use the temporary table, at the end of the stored procedure, ensure that all the temporary table explicit deleted .
First truncate table, then drop table.
This avoids a longer time to lock system tables.
25, try to avoid using a cursor.
Because of the poor efficiency of the cursor, if the cursor operation more than 10,000 lines, you should consider rewriting.
26, set-based method is generally more efficient.
Before using the cursor method or methods based on temporary tables, you should look for set-based solutions to solve the problem.
27, like the temporary table, a cursor is not unusable.
For small data sets using FAST_FORWARDthe cursor, line by line generally better than other treatment methods.
Especially when several tables must refer to in order to obtain the required data.
In the result set, including "Total" routine, usually better than using a cursor speed to perform faster.
If the development time permits, cursor-based methods and can be set based approach to try to see which method is better.
28, at the beginning of settings for all stored procedures and triggers SET NOCOUNT ON, set up at the end SET NOCOUNT OFF.
Without sending to the client after each statement is executed and the stored procedure trigger DONE_IN_PROCmessage.
29, try to avoid to the client to return large amounts of data.
If the data is too large, you should consider the corresponding demand is reasonable.
30, try to avoid large transaction operations , improve system concurrency.
