1. Para optimizar la consulta, deberías intentar evitar el escaneo completo de tablas y primero considerar crear un índice en las columnas involucradas en dónde y ordenar.
2. Intentar evitar el juicio de valor nulo en los campos de la cláusula where, de lo contrario el motor abandonará el uso de índices y realizará un escaneo completo de tablas, como:
Selecciona id desde t donde num es nulo
Puedes establecer el valor predeterminado de 0 en el num, asegurarte de que no hay ningún valor nulo en la columna número de la tabla, y luego consultar así:
Seleccione id de t donde num=0
3. Intenta evitar usar operadores != o <> en la cláusula where, de lo contrario el motor abandonará el uso de índices y realizará un escaneo de tabla completa.
4. Debes intentar evitar usar OR en la cláusula where para unir la condición, de lo contrario hará que el motor abandone el uso de índices y realice un escaneo completo de la tabla, como:
Selecciona ID desde T, donde num=10 o num=20
Puedes consultar así:
Selecciona ID de T, donde num=10
Sindicato todos
Selecciona ID de T, donde num=20
5.in y no en también deben usarse con precaución, de lo contrario conducirá a un escaneo completo de la mesa, como por ejemplo:
Selecciona ID desde t donde num en(1,2,3)
Para valores continuos, no uses en si puedes usar entre:
Selecciona ID desde t donde num está entre 1 y 3
6. La siguiente consulta también resultará en un escaneo completo de la tabla:
Selecciona ID desde t donde el nombre es '%abc%'
Para mejorar la eficiencia, considera la búsqueda en texto completo.
7. Si usas un parámetro en una cláusula where, también provocará un escaneo completo de la tabla. Porque SQL solo resuelve variables locales en tiempo de ejecución, pero el optimizador no puede posponer la selección de planes de acceso a tiempo de ejecución; Debe seleccionarse en tiempo de compilación. Sin embargo, si se establece un plan de acceso en tiempo de compilación, el valor de la variable sigue siendo desconocido y, por tanto, no puede usarse como elemento de entrada para la selección de índices. Las siguientes declaraciones serán escaneadas en su totalidad:
Selecciona ID desde t donde num=@num
Puedes forzar que la consulta use un índice en su lugar:
Selecciona ID desde t con(index(index(index name)) donde num=@num
8. Intenta evitar expresar campos en la cláusula where, lo que hará que el motor abandone el uso de índices en favor del escaneo completo de tablas. Por ejemplo:
Selecciona ID de t donde numero/2=100
Debería cambiarse a:
Selecciona ID de T, donde num=100*2
9. Intentar evitar realizar operaciones de función sobre los campos de la cláusula where, lo que hará que el motor abandone el uso de índices en favor del escaneo completo de la tabla. Por ejemplo:
Selecciona ID desde t donde substring(name,1,3)='abc' --id de nombre que empieza por abc
Selecciona ID desde t donde DateDiff(Day,Createdate,'2005-11-30')=0--'2005-11-30' generado ID
Debería cambiarse a:
Selecciona ID desde T donde el nombre es 'ABC%'
selecciona ID desde t donde se crea>='2005-11-30' y se crea<'2005-12-1'
10. No realices funciones, operaciones aritméticas u otras operaciones de expresión a la izquierda del "=" en la cláusula where, de lo contrario el sistema puede no ser capaz de usar correctamente el índice.
11. Al usar un campo índice como condición, si el índice es un índice compuesto, entonces el primer campo del índice debe usarse como condición para asegurar que el sistema use el índice, de lo contrario no se utilizará el índice, y el orden de los campos debe ser coherente con el orden del índice tanto como sea posible.
12. No escribas algunas consultas sin sentido, como generar una estructura de tabla vacía:
Selecciona Col1,col2 en #t desde T, donde 1=0
Este tipo de código no devuelve ningún conjunto de resultados, pero consume recursos del sistema, así que debería cambiarse a algo así:
crear tabla #t(...)
13. Muchas veces es una buena opción reemplazar en por exists:
Seleccione Num de A donde Num In(Seleccione Num de B)
Sustituye por la siguiente afirmación:
Seleccione num de A donde existe (seleccione 1 de B donde num=A.num)
14. No todos los índices son válidos para consultas, SQL se basa en los datos de la tabla para optimizar la consulta; cuando la columna índice tiene una gran cantidad de duplicación de datos, las consultas SQL pueden no usar el índice, por ejemplo una tabla tiene un campo sexo, macho y femenino casi la mitad cada uno, y aunque el índice se construya sobre sexo, no influirá en la eficiencia de las consultas.
15. Cuantos más índices no existan, mejor; el índice ciertamente puede mejorar la eficiencia de la selección correspondiente, pero también reduce la eficiencia de insertar y actualizar, porque el índice puede reconstruirse al insertar o actualizar, por lo que la forma de construir un índice debe considerarse cuidadosamente, dependiendo de la situación específica. Es mejor no tener más de 6 índices en una tabla y, si hay demasiados, considerar si es necesario construir índices en algunas columnas poco usadas.
16. Evitar actualizar las columnas de datos indexados agrupados tanto como sea posible, porque el orden de las columnas de datos indexados agrupados es el orden físico de almacenamiento de los registros de tabla, y una vez que cambia el valor de la columna, esto llevará al ajuste del orden de los registros completos de la tabla, lo que consumirá recursos considerables. Si tu aplicación necesita actualizar frecuentemente las columnas de índice agrupadas, debes considerar si deberías construir el índice como un índice agrupado.
17. Intenta usar campos numéricos y trata de no diseñar campos que contengan solo información numérica como caracteres, lo que reducirá el rendimiento de consultas y conexiones, y aumentará la sobrecarga de almacenamiento. Esto se debe a que el motor compara cada carácter de la cadena uno por uno al procesar consultas y uniones, mientras que para los tipos numéricos solo es necesario compararlo una vez.
18. Utiliza varchar/nvarchar en lugar de char/nchar tanto como sea posible, porque primero, el espacio de almacenamiento en campo más largo puede ahorrar espacio, y segundo, para consultas, la eficiencia de búsqueda en un campo relativamente pequeño es obviamente mayor.
19. No uses select * de t en ningún sitio, sustituye "*" por una lista específica de campos y no devuelvas ningún campo que no se haya usado.
20. Intenta usar variables de tabla en lugar de tablas temporales. Si la variable de la tabla contiene una gran cantidad de datos, hay que tener en cuenta que el índice es muy limitado (solo el índice de clave primaria).
21. Evitar crear y eliminar frecuentemente tablas temporales para reducir el consumo de recursos de tablas del sistema.
22. Las tablas temporales no son inutilizables, y usarlas adecuadamente puede hacer que algunas rutinas sean más efectivas, por ejemplo, cuando necesitas referenciar repetidamente un conjunto de datos en una tabla grande o en una tabla de uso común. Sin embargo, para eventos puntuales, lo mejor es usar una tabla de exportación.
23. Al crear una tabla temporal, si la cantidad de datos insertados en un momento es grande, entonces puedes usar select into en lugar de create table para evitar causar un gran número de registros y mejorar la velocidad; Si la cantidad de datos no es grande, para facilitar los recursos de la tabla del sistema, deberías crear primero la tabla y luego insertarla.
24. Si se utiliza una tabla temporal, asegúrese de eliminar explícitamente todas las tablas temporales al final del procedimiento almacenado, trunque primero la tabla y luego elimine la tabla, para evitar que la tabla del sistema quede bloqueada durante mucho tiempo.
25. Intenta evitar usar el cursor, porque la eficiencia del cursor es pobre; si los datos operados por el cursor superan las 10.000 líneas, deberías considerar reescribir.
26. Se deben buscar soluciones basadas en conjuntos para resolver problemas antes de utilizar métodos basados en cursor o en tablas temporales, que suelen ser más efectivos.
27. Al igual que las tablas temporales, los cursores no son inutilizables. Usar FAST_FORWARD cursores para conjuntos de datos pequeños suele ser mejor que otros métodos de procesamiento fila por fila, especialmente si tienes que consultar varias tablas para obtener los datos que necesitas. Las rutinas que incluyen "total" en el conjunto de resultados suelen ser más rápidas que las que se ejecutan con el cursor. Si el tiempo de desarrollo lo permite, se pueden probar tanto métodos basados en cursor como en conjuntos para ver cuál funciona mejor.
28. Establecer SET NOCOUNT ON al principio de todos los procedimientos y triggers almacenados, y SET NOCOUNT OFF al final. No es necesario enviar mensajes DONE_IN_PROC al cliente después de ejecutar cada sentencia del procedimiento almacenado y el disparo.
29. Intentar evitar grandes operaciones de transacción y mejorar la capacidad de concurrencia del sistema.
30. Intenta evitar devolver grandes cantidades de datos al cliente; si el volumen de datos es demasiado grande, deberías considerar si la demanda correspondiente es razonable. |
Publicado en 27/1/2015 20:09:54
|
|
|
