Sql query in order to improve search efficiency, we often take a number of measures were sql query optimization methods summarized below, there is a need can refer to reference.
1. query optimization, should try to avoid full table scan, should first consider indexing by the column involved in where and order. 2. 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 where NUM IS null T may be provided on a default value of 0 num, to ensure table num column value is not null, then this query: SELECT ID from T = 0 where num ! 3. should be avoided in the where clause = or <> operator, otherwise the engine to give up using the index and a full table scan . 4 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 = NUM = 10 or 20 is could this query: SELECT ID from the WHERE NUM = 10 t of Union All the SELECT t the WHERE NUM from the above mentioned id = 20 5.In should be used with caution and not in, otherwise it will lead to a full table scan, such as: the SELECT NUM in the above mentioned id from the WHERE t (, 2, 3) for continuous values, can not use in the BETWEEN: SELECT from T WHERE ID BETWEEN NUM. 3. 1 and 6. the following query will also lead to a full table scan: SELECT ID from T WHERE name like '%% ABC' 7. The fields should be avoided to operate in the where clause expressions, which will cause the engine to give up using the index and a full table scan. Such as: SELECT NUM ID from where T / 2 = 100 should read: SELECT ID from where NUM = 100 * T 2 8. The fields should be avoided for the function operated in the where clause that will cause the engine to give up using the index a full table scan. Such as: SELECT from T ID where the substring (name, l, 3) = 'ABC' - to name id abc beginning should read: SELECT ID from T where name like 'ABC%' 9. The where clause do not the "=" left the function performed, arithmetic operations, or other expressions, or the system may not work properly indexed. 10. As a condition of using the index field, if the index is a composite index, you must use the index to the first field to ensure the system uses the index as a condition, otherwise the index will not be used, and should as much as possible so that field order is consistent with the order index. 11. Do not write the query does not make sense, such as the need to create an empty table structure: the SELECT col1, col2 INTO #t from the WHERE t 1 = 0 This code does not return any result sets, but consumes system resources, should be changed like this: Create Table #t (...) 12. often used in place exists is a good choice: SELECT NUM NUM from A in WHERE (SELECT NUM from B) was replaced with the following statement: SELECT NUM exists from A WHERE (SELECT. 1 from B WHERE NUM = a.num ) 13. 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, 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. 14. 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 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. 15 make use of numeric fields, if only the fields containing numerical information is not possible for the character design, which reduces the performance of the connections and queries, and increases storage costs. 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. 16. The possible use varchar instead of char, 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. 17. 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. 18. Avoid frequent create and delete temporary tables, system tables to reduce the consumption of resources.
19. A temporary table is not unusable, they can make appropriate use of certain routines more efficient, for example, when it is necessary a large table or tables commonly duplicate references a data set. However, for a one-time event, it is best to use export table. 20. When 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.
21. 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. 22. 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. 23. Use 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.
24. temporary tables, cursors are 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.
25. Try to avoid large transaction operations, improve system concurrency. 26. Avoid returned to the client a large amount of data, if the data is too large, you should consider the corresponding demand is reasonable.