1, se debe evitar en la cláusula where operador! = O <>, de lo contrario el motor para dejar de usar el índice y un escaneo completo de tabla.
2, la optimización de consultas, debe tratar de evitar el escaneo completo de tabla, primero debe considerar la indexación de la columna implicada en dónde y orden.
3, se debe evitar en un valor nulo es campos determinados en la cláusula WHERE, hará que el motor para dejar de usar el índice y un escaneo completo de tabla, tales como:
seleccione ID de t donde num es nulo
se puede disponer en un valor por defecto de 0 num, num columna de la tabla para asegurarse de que el valor no es nulo, esta consulta:
donde T de ID NUM SELECT = 0
. 4, para evitar el uso o en la cláusula WHERE a condición de unión, hará que el motor para dejar de usar el índice y un escaneo completo de tabla, tales como:
SELECT ID de t donde num = 10 o num = 20
puede hacer la consulta:
T donde Identificación de NUM SELECT = 10
Unión de todo
SELECT donde T de ID = 20 es NUM
. 5, la siguiente consulta no dará lugar a un escaneo completo de tabla :( por ciento frente)
seleccione ID de t donde nombre como ' % c%'
Para mejorar la eficiencia, se puede considerar la búsqueda de texto completo.
6, en debe utilizarse con precaución y no en, si no llevará a un escaneo completo de tabla, como por ejemplo:
seleccione ID de t donde num en ( 1,2,3)
para valores continuos, no se puede utilizar en el entre:
donde T de ID NUM SELECT ENTRE. 1 y. 3
. 7, si el parámetro que se utiliza en la cláusula WHERE, conducirá a un escaneo completo de tabla. Dado que SQL en tiempo de ejecución sólo se resolverá variables locales, pero el optimizador no puede aplazar la elección de plan de acceso para funcionar, sino que debe elegir en tiempo de compilación. Si, sin embargo, establecer el plan de acceso en tiempo de compilación, el valor de la variable es desconocida, y por lo tanto no se puede utilizar como entrada de índice seleccionada. A medida que la siguiente declaración se presentará escaneo completo de tabla:
Seleccione ID de t donde num = @ num
se puede cambiar para forzar la consulta utilizando el índice:
SELECT ID de t con (índice (nombre de índice)) donde NUM NUM = @
8, se debe evitar para los campos que operan en el que la expresión cláusula, lo que provocará que el motor se dan utilizando el índice y escaneo completo de tabla. Tales como:
SELECT ID de t donde num / 2 = 100
debe decir:
donde T de ID NUM SELECT = 100 * 2
. 9, se debe evitar para una operación de función en los campos donde cláusula que hará que el motor para dejar de usar el índice y escaneo completo de tabla. Tales como:
SELECT ID de t donde subcadena (nombre , 1,3) = 'abc'-nombre abc Identificación empezando a
SELECT ID de t donde datediff (día , CreateDate,' 2005-11-30 ') = 0-'2005-11 -30 'identificador generado
debe decir:
donde T de nombre de ID SELECT como 'ABC%'
SELECT ID CreateDate desde donde T> = '2005-11-30' y CreateDate < '01/12/2005'
10, no en la cláusula WHERE "=" izquierda funciones, operaciones aritméticas, u otras expresiones o el sistema no funcione correctamente indexada.
11, como una condición para utilizar el campo de índice, si el índice es un índice compuesto, debe utilizar el índice para el primer campo como las condiciones para garantizar los usos del sistema del índice, de lo contrario no va a utilizar el índice, y debe tanto como sea posible para que el orden de campo es consistente con el índice de orden.
12, no escribir la consulta no tiene sentido, como la necesidad de crear una estructura de tabla vacía:
seleccionar col1, col2 en #t de t en la que 1 = 0
Este código no devuelve ningún conjunto de resultados, pero consumen recursos del sistema, esto debe ser sustituida:
Tabla #t Crear (...)
13 es, en muchos casos existe reemplazado por una opción buena:
seleccionar num de un donde num en ( seleccione num de b)
se sustituyó por la siguiente declaración:
Un NUM desde donde existe SELECT (. SELECT 1 de B donde NUM = a.num)
14, un índice no es válido para todas las consultas, la optimización de consultas SQL se realiza en base a datos de la tabla, cuando las listas de índices duplican grandes cantidades de datos, consultas SQL no pueden ir a usar el índice, como una tabla tiene un campo de relaciones sexuales, masculina, femenina casi cada mitad, aunque el índice construido en el sexo no tienen ningún efecto sobre la eficiencia de la consulta.
15, el índice no es posible, el índice que corresponde sin duda puede mejorar la eficiencia de la selección, sino que también reduce la eficiencia de inserción y actualización, ya que es posible cuando la inserción o actualización será reconstruir el índice, el índice debe ser cuidadosamente considerada la forma de construir, como puede ser el caso. Una tabla de números índice no es mejor más de seis, si demasiada debe tener en cuenta algunos de los utilizados con menos frecuencia para construir la columna de índice si es necesario.
16. La actualización se debe evitar tanto como sea posible columna de datos de índice agrupado, la columna debido a que el orden de los datos de índice está agrupado para almacenamiento físico registrado en la tabla, una vez que la columna dará lugar a los cambios de valor de ajuste en el orden de grabación de toda la tabla, consumirá recursos considerables. Si las aplicaciones requieren actualizaciones frecuentes agrupadas columnas de datos de índice, es necesario considerar si debe ser construido para el índice de índice agrupado.
17, hacer uso de los campos numéricos, los campos numéricos que contiene la información aunque sólo sea para que no se diseñe para el personaje, lo que reducirá el rendimiento de las consultas y conexiones, y aumentará la sobrecarga de almacenamiento. Esto es porque el motor cuando el procesamiento de consultas y conexiones uno a comparar cada carácter de la cadena, y para fines de comparación numérica una sola vez es suficiente.
18, tanto como sea posible el uso de varchar / nvarchar en lugar de char / nchar, porque en primer lugar de longitud variable campos pequeño espacio de almacenamiento, puede ahorrar espacio de almacenamiento, seguido de la consulta, en un tiempo relativamente pequeño campo de la eficiencia de búsqueda es claramente superior.
19, en cualquier lugar No utilice SELECT * FROM t, con una lista específica de los campos en lugar de "*", no devolver cualquiera de los campos con menos.
20, en lugar de hacer uso de una tabla de variables tabla temporal. Si la variable de tabla contiene una gran cantidad de datos, tenga en cuenta que el índice es muy limitada (sólo el índice de clave primaria).
21, para evitar crear la frecuente y eliminar tablas temporales, las tablas del sistema para reducir el consumo de recursos.
22, la tabla temporal no es inutilizable, pueden hacer un uso adecuado de ciertas rutinas más eficaces, por ejemplo, cuando una referencia a un conjunto de datos que se repita una mesa grande o cuando la tabla utilizada. Sin embargo, para un evento de una sola vez, lo mejor es el uso de mesa de exportación es.
23, en la nueva tabla temporal, si se inserta una gran cantidad de datos, puede utilizar select into en lugar de crear la tabla, para evitar un gran número de registro, con el fin de aumentar la velocidad; si los pequeños recursos de datos para facilitar las tablas del sistema, usted debe crear la tabla, a continuación, insertar.
24, si se utiliza la tabla temporal, asegúrese de que toda la tabla temporal explícita eliminado al final del procedimiento almacenado, primera tabla truncado, a continuación, colocar la mesa, para evitar el bloqueo de las tablas del sistema desde hace mucho tiempo.
25, trata de evitar el uso de un cursor, ya que la baja eficiencia del cursor, si la operación del cursor más de 10.000 líneas, se debe considerar la reescritura.
26, con el cursor antes de que el método o métodos basados en tablas temporales, que debe buscar soluciones basadas en conjuntos para resolver el problema, el método basado en conjuntos suelen ser más eficientes.
27, al igual que la tabla temporal, un cursor no es inutilizable. Uso FAST_FORWARD cursor en pequeños conjuntos de datos son por lo general mejor que otros métodos de tratamiento progresivo, sobre todo en referencia a varias tablas debe ser el fin de obtener los datos requeridos. En el conjunto de resultados incluye "total" de las rutinas habituales realizadas mediante el uso de la velocidad del cursor rápido. Si el tiempo lo permite el desarrollo, métodos y basados en el cursor se pueden ajustar enfoque para tratar de ver qué método es mejor.
28, se proporciona al comienzo del SET NOCOUNT ON todos los procedimientos almacenados y disparadores, SET NOCOUNT OFF dispuesto en el extremo. DONE_IN_PROC no necesita enviar un mensaje al cliente después de que se ejecuta cada instrucción almacenados y disparadores procedimiento.
