1) Database design:
A query optimization, should try to avoid full table scan, you should first consider indexing by the column involved in where and order..
. b fields should be avoided to a null value is determined 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, to ensure num table column value is not null, then this query: select id from t where num = 0
c. Not all indexes are valid query, SQL query optimization is performed according to data in the table, when the index lists a large number of duplicate data, the query may not be to take advantage of the index, such as a table has a field sex, male, female almost half each, even if the sex was built in the query efficiency index also no effect.
d. the index is not possible, the corresponding index can certainly improve the efficiency of select, but also reduces the efficiency of insert and update, as the insert or update when there is likely to 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.
E. as far as possible to avoid updating the index data columns, because the order of the index column is a physical data storage order recorded in the table, once the column will result in the adjustment value changes in the order of recording the entire table, it will consume considerable resources. If applications require frequent updates index data columns, you need to consider whether the index should be built for the index.
f. make use of numeric field, if only with numeric information field as much as possible 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.
g. Use as a 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.
H. Table variables instead make use of a temporary table. If the table variable contains a large amount of data, please note that the index is very limited (only the primary key index).
i. to avoid the frequent create and delete temporary tables, system tables to reduce the consumption of resources.
J. not a temporary table can not be used, they may be suitably used to make 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.
. K in the new temporary table, if one inserts a large amount of data, it may be used instead of select into create table, to avoid a large number of log, in order to increase speed; if small data, in order to ease the system resource table, should create table, then insert.
l. If you use a temporary table to be 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.
2) SQL statements aspects:
a. should be avoided in the where clause! = or <> operator, otherwise the engine to give up using the index and a full table scan.
. B should be avoided in the where clause to connect or 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
Queries can do:
select id from t where num=10 union all select id from t where num=20
. C 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, you can not use in the between:
select id from t where num between 1 and 3
. D following query will result in a full table scan:
select id from t where name like ‘%abc%’
e. 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
It can be changed to force the query using the index:
select id from t with(index(索引名)) where num=@num
f. Should be avoided fields operations expression in the where clause, which would 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
g. fields should be avoided for the function operated in the 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 begin with abc's id
select id from t where datediff(day,createdate,’2005-11-30′)=0
-'2005-11-30 'id generated
Should read:
select id from t where name like ‘abc%’ select id from t where createdate>=’2005-11-30′ and createdate<’2005-12-1′
h. Do not functions, arithmetic operations, or other expressions in the where clause "=" left, or the system may not work properly indexed.
. I do not make sense to write some queries, 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(…)
. J exists a lot of time instead of in use is 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)
k. 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.
l. 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.
m. returned to the client to avoid large amounts of data, if the data is too large, it should be considered corresponding demand is reasonable.
n. Try to avoid large transaction operations, improve system concurrency.