Admini1 ) Database design:
a. the query optimization, should try to avoid full table scans, you should first consider where and by order index on the columns involved.
. b should be avoided in where to clause fields null value is determined, it will cause the engine to give up using the index and a full table scan, such as: SELECT ID num from where T IS null may num set the default values 0 , to ensure table num column has no null value, then this query: SELECT ID WHERE num from T = 0
c. Not all indexes are valid query, SQL is used to query optimization based on 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 on the construction of the index also no effect on the query efficiency.
d. the index is not possible, of course, can improve the index corresponding select efficiency, but also reduces the insert and update efficiency, as 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. A table index number should not exceed 6 Ge, 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. Try using a 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).
i. to avoid the frequent create and delete temporary tables, system tables to reduce the consumption of resources.
J. 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.
. k in the new temporary table, if one inserts a large amount of data, you can use select into place 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 Table Create , 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, the first TRUNCATE the Table , and then drop the Table , to avoid locking the system tables a long time.
2) SQL statements aspects:
a. should be avoided in where the use clause ! = or <> operator, otherwise the engine to give up using the index and a full table scan.
. b should be avoided in where the use clause or connected 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 t where num = 10 union all select id from t where num = 20
. c in and not in should be used with caution, 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 be between not use in the: the SELECT the above mentioned 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 where parameters clause, will lead to a full table scan. Because SQL only at runtime will 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 scans: the SELECT from the above mentioned id = @ t the WHERE NUM NUM can be changed to force the query using the index: the SELECT with the above mentioned id from t (index ( index name )) where num = @ num
f. should be avoided at where the fields using an expression operation clause, which would cause the engine to give up using the index and full table scan. Such as: SELECT ID WHERE NUM from T / 2 = 100 should be changed to : select id from t where num = 100 * 2
g. should be avoided in where to operate fields function clause, which will cause the engine to give up using the index and a full table scan. Such as: SELECT ID WHERE T from the substring (name, l, 3) = ' abc ' - name to abc beginning ID SELECT ID from T WHERE DATEDIFF (Day, CreateDate, ' 2005-11-30 ' ) = 0 - ' 2005 -11-30 'generated id should read : SELECT id from T WHERE name like ' ABC% ' SELECT id from CreateDate WHERE T> = ' 2005-11-30 ' and CreateDate < ' 2005-12-1 '
h. Do not where clause " = a function, expression of arithmetic or other operations" on the 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: 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 ( ... )
. j often used exists in place in 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 )
k. everywhere Do not use the 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 data cursor operation more than 1 million rows, you should consider rewriting.
m. avoid returned to the client large amount of data, if the data is too large, should be considered corresponding demand is reasonable.
n. Try to avoid large transaction operations, improve system concurrency.
3) java aspects:
a. as little as possible made objects.
b. Reasonable put the location of system design. Much data, and a small amount of data manipulation must be separated. A large amount of data manipulation, certainly not ORM framework Walsh said. ,
C , using jDBC link database operations.
. d control the memory, so that data streams together, but not all memory read processing again, but the reading side margin processing;
e. the rational use of memory to cache some data