1, should be avoided in the where clause! = Or <> operator, otherwise the engine to give up using the index and a full table scan.
2, query optimization, should try to avoid full table scan, you should first consider indexing by the column involved in where and order.
3, should be avoided to a null value is determined fields in the where clause, will cause the engine to give up using the index and a full table scan, such as:
select id from t where num is null
may be provided on a default value of 0 num, num column of the table to ensure that the value is not null, then this query:
where T from ID NUM SELECT = 0
. 4, to avoid the use or in the where clause to join condition, will cause the engine to give up using the index and a full table scan, such as:
select id from t where num = 10 or num = 20
can do the query:
T WHERE ID from NUM SELECT = 10
Union All
SELECT WHERE T from ID = 20 is NUM
. 5, the following query will not result in a full table scan :( front Percent)
select id from t where name like ' % c%'
To improve efficiency, can be considered full-text search.
6, in should be used with caution and not in, otherwise it will lead to a full table scan, such as:
select id from t where num in ( 1,2,3)
for continuous values, can not use in the between:
where T from ID NUM SELECT BETWEEN. 1 and. 3
. 7, if the parameter used in the where clause, will lead to a full table scan. Because SQL at runtime will only resolve local variables, but the optimizer can not defer the choice of access plan to run; 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
can be changed to force the query using the index:
select id from t with (index (index name)) where NUM NUM = @
8, should be avoided for operating fields in the where clause expression, which 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:
where T from ID NUM SELECT = 100 * 2
. 9, should be avoided for a function operation in the fields where clause that 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 id abc beginning to
select id from t where datediff (day , createdate,' 2005-11-30 ') = 0-'2005-11 -30 'id generated
should read:
where T from ID name SELECT like 'ABC%'
SELECT ID CreateDate from where T> = '2005-11-30' and CreateDate < '2005-12-1'
10, not in the where clause "=" left functions, arithmetic operations, or other expressions, or the system may not work properly indexed.
11, as a condition of using the index field, if the index is a composite index, 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 much as possible so that field order is consistent with the order index.
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 they consume system resources, this should be replaced:
Table #t Create (...)
13 is, in many cases replaced by a good choice exists:
select num from a where num in ( select num from b)
was replaced with the following statement:
A NUM from WHERE EXISTS SELECT (SELECT. 1 from B WHERE NUM = a.num)
14, an index is not valid for all queries, the SQL query optimization is performed based on data in the table, when the index lists duplicate large amounts of data, SQL queries may not go to use the index, such as a table has a field sex, male, female almost each half, even if the index built on sex have no effect on the query efficiency.
15, the index is not possible, the corresponding index can certainly improve the efficiency of select, but also reduces the efficiency of insert and update, because it is possible when the insert or update will rebuild the index, the index needs to be carefully considered how to build, As the case may be. An index number table is best not more than six, if too much you should consider some of the less frequently used to build the index column if necessary.
16. The update should be avoided as much as possible clustered index data column, the column because the order of the index data is clustered physical storage order recorded in the table, once the column will result in the adjustment value changes in the order of recording the entire table, will consume considerable resources. If applications require frequent updates clustered index data columns, you need to consider whether it should be built for the clustered index index.
17, make use of numeric fields, numeric fields containing information if only so as not to design for the character, which will reduce the performance of queries and connections, and will increase the storage overhead. This is because the engine when processing queries and connections one by comparing each character in the string, and for numeric comparison purposes only once is enough.
18, as much as possible the use of varchar / nvarchar instead of char / nchar, because first of all variable-length fields small storage space, you can save storage space, followed by the query, in a relatively small field of search efficiency is clearly higher.
19, anywhere Do not use select * from t, with a specific list of fields instead of "*", do not return any of the fields with less than.
20, instead make use of a temporary table 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, e.g., 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, you can use select into instead of create table, to avoid a large number of log, in order to increase speed; if small data resources to ease the system tables, you should create table, then insert.
24, if you use the temporary table, make sure all the temporary table explicit deleted at the end of the stored procedure, first truncate table, then drop table, to avoid locking the system tables a long time.
25, try to avoid using a cursor, because the poor efficiency of the cursor, if the cursor operation more than 10,000 lines, you should consider rewriting.
26, using the cursor before the method or methods based on temporary tables, you should look for set-based solutions to solve the problem, usually more efficient set-based method.
27, like the temporary table, a cursor is not unusable. Use FAST_FORWARD cursor on small data sets are usually better than other progressive treatment methods, particularly in reference to several tables must be in order to obtain the required data. In the result set includes "total" than usual routines performed by using the cursor speed fast. If the development time permits, cursor-based methods and can be set based approach to try to see which method is better.
28, is provided at the beginning of SET NOCOUNT ON all the stored procedures and triggers, SET NOCOUNT OFF disposed at the end. DONE_IN_PROC not need to send a message to the client after each statement is executed and triggers stored procedure.
