Método para procesar datos por encima de diez millones de niveles para aumentar la velocidad de consulta

1. Intente evitar usar el operador! = O <> en la cláusula where; de ​​lo contrario, el motor abandonará el uso de índices y realizará un escaneo completo de la tabla.
2. Para optimizar la consulta, se debe evitar la exploración completa de la tabla tanto como sea posible. Primero, debe considerar establecer índices en las columnas involucradas en dónde y ordenar por.
3. Intente evitar juzgar el valor nulo del campo en la cláusula where; de ​​lo contrario, el motor dejará de usar el índice y realizará un análisis completo de la tabla, como:
     select id from t donde num es nulo
     puede establecer el valor predeterminado de 0 en num para asegurarse de que No hay un valor nulo en la columna num de la tabla, y luego consulta de esta manera:
     selecciona id de t donde num = 0
4. Intenta evitar usar o en la cláusula where para unir la condición, de lo contrario hará que el motor abandone el índice y realice un escaneo completo de la tabla, como :
     Seleccione id de t donde num = 10 o num = 20
     se puede consultar de esta manera:
     seleccione id de t donde num = 10
     union todos
     seleccione id de t donde num = 20
5. La siguiente consulta también dará como resultado un escaneo completo de la tabla: (no se puede Establecer signo de porcentaje)
     seleccione la identificación de t donde el nombre como '% abc%'
    Para mejorar la eficiencia, puede considerar la búsqueda de texto completo.
6. In y not in también se deben usar con precaución, de lo contrario, se generará un escaneo completo de la tabla, como:
     seleccionar id desde t donde num in (1,2,3)
     Para valores continuos, puede usar between en lugar de in:
     seleccione id from t where num entre 1 y 3
7. Si usa parámetros en la cláusula where, también causará un escaneo completo de la tabla. Debido a que SQL solo analiza las variables locales en tiempo de ejecución, el optimizador no puede diferir la elección del plan de acceso en tiempo de ejecución; debe elegir en tiempo de compilación. Sin embargo, si el plan de acceso se establece en tiempo de compilación, el valor de la variable aún se desconoce, por lo que no se puede utilizar como entrada para la selección del índice. La siguiente instrucción realizará un escaneo completo de la tabla:
     seleccione la identificación de t donde [email = num = @ num] num = @ num [/ email]
     puede usarse para forzar a la consulta a usar el índice:
     seleccione la identificación de t con (índice (nombre del índice)) where [email = num = @ num] num = @ num [/ email]
8. Debe intentar evitar realizar operaciones de expresión en los campos de la cláusula where, lo que hará que el motor abandone el uso de índices y realice una exploración completa de la tabla. Por ejemplo:
     seleccione id de t donde num / 2 = 100
     debe cambiarse a:
     seleccione id de t donde num = 100 * 2
9. Debe intentar evitar las operaciones de función en el campo en la cláusula where, lo que hará que el motor deje de usar el índice. Realizar un escaneo completo de la tabla. Por ejemplo:
     seleccione id de t donde substring (name, 1,3) = 'abc'-id cuyo nombre comienza con abc
     seleccione la identificación de t donde fechado (día, fecha de creación, '2005-11-30') = 0 – '2005-11-30 'la identificación generada
     debe cambiarse a:
     seleccione la identificación de t donde el nombre como' abc% '
     seleccione la identificación de t where createdate> = '2005-11-30' y createdate <'2005-12-1'
10. No realice funciones, operaciones aritméticas u otras operaciones de expresión en el lado izquierdo de "=" en la cláusula where, de lo contrario el sistema será posible El índice no se puede usar correctamente.
11. Cuando se usa un campo de índice como condición, si el índice es un índice compuesto, el primer campo del índice debe usarse como condición para garantizar que el sistema use el índice; de ​​lo contrario, el índice no se usará y debería En la medida de lo posible, haga que el orden de los campos sea coherente con el orden del índice.
12. No escriba algunas consultas sin sentido, como la necesidad de generar una estructura de tabla vacía:
     seleccione col1, col2 en #t desde t donde 1 = 0
     dicho código no devolverá ningún conjunto de resultados, pero consumirá recursos del sistema, debe cambiarse. De esta manera:
     cree la tabla #t (...)
13.



14. No todos los índices son efectivos para las consultas. SQL está optimizado en función de los datos de la tabla. Cuando la columna de índice tiene mucha duplicación de datos, la consulta SQL puede no usar el índice. Por ejemplo, una tabla tiene campos sexo, masculino, Las mujeres son casi la mitad, por lo que incluso si el índice se basa en el sexo, no ayudará a la eficiencia de la consulta.
15. El índice no es cuanto mejor, el índice ciertamente puede mejorar la eficiencia de la selección correspondiente, pero al mismo tiempo también reduce la eficiencia de insertar y actualizar, porque insertar o actualizar puede reconstruir el índice, por lo que la forma de construir el índice requiere una cuidadosa consideración, Depende de la situación específica. El número de índices de una tabla no debe exceder 6, si hay demasiados, debe considerarse si los índices construidos en algunas columnas que no se usan con frecuencia son necesarios.
16. Debe evitar la actualización de la columna de datos de índice agrupados tanto como sea posible, porque el orden de la columna de datos de índice agrupados es el orden de almacenamiento físico de los registros de la tabla, una vez que el valor de la columna cambia causará el ajuste del orden de los registros de la tabla completa, lo que consumirá recursos considerables. Si el sistema de la aplicación necesita actualizar con frecuencia la columna de datos del índice agrupado, debe considerar si el índice debe construirse como un índice agrupado.
17. Use los campos numéricos tanto como sea posible. Esto se debe a que el motor comparará cada carácter de la cadena uno por uno cuando procese la consulta y la conexión, y para el tipo numérico, solo debe compararse una vez.
18. Use varchar / nvarchar en lugar de char / nchar tanto como sea posible, porque primero el espacio de almacenamiento de los campos de longitud variable es pequeño, lo que puede ahorrar espacio de almacenamiento, y en segundo lugar para las consultas, la eficiencia de búsqueda en un campo relativamente pequeño es obviamente mayor.
19. No use select * from t en ninguna parte, reemplace "*" con una lista de campos específica y no devuelva ningún campo que no se use.
20. Intente utilizar variables de tabla en lugar de tablas temporales. Si la variable de la tabla contiene una gran cantidad de datos, tenga en cuenta que el índice es muy limitado (solo el índice de la clave principal).
21. Evite la creación y eliminación frecuente de tablas temporales para reducir el consumo de recursos de tablas del sistema.
22. Las tablas temporales no son inutilizables. El uso adecuado de ellas puede hacer que algunas rutinas sean más efectivas, por ejemplo, cuando necesita referirse repetidamente a un conjunto de datos en una tabla grande o una tabla de uso frecuente. Sin embargo, para eventos únicos, es mejor usar una tabla de exportación.
23. Al crear una tabla temporal, si inserta una gran cantidad de datos a la vez, puede usar select into en lugar de crear una tabla para evitar una gran cantidad de registros para mejorar la velocidad; si la cantidad de datos no es grande, para facilitar los recursos de la tabla del sistema, debe crear tabla, luego insertar.
24. Si se usa una tabla temporal, todas las tablas temporales deben eliminarse explícitamente al final del procedimiento almacenado, truncar primero la tabla y luego soltar la tabla, para evitar el bloqueo a largo plazo de las tablas del sistema.
25. Evite usar los cursores tanto como sea posible, porque la eficiencia de los cursores es pobre, si los datos de la operación del cursor exceden las 10,000 filas, entonces debería considerar reescribir.
26. Antes de utilizar el método basado en el cursor o el método de tabla temporal, primero debe buscar una solución basada en conjuntos para resolver el problema. El método basado en conjuntos suele ser más eficaz.
27. Al igual que las tablas temporales, los cursores no son inutilizables. El uso de los cursores FAST_FORWARD para conjuntos de datos pequeños suele ser superior a otros métodos de procesamiento fila por fila, especialmente cuando debe consultar varias tablas para obtener los datos requeridos. Las rutinas que incluyen "total" en el conjunto de resultados generalmente se ejecutan más rápido que usar cursores. Si el tiempo de desarrollo lo permite, se puede probar tanto el método basado en el cursor como el método basado en conjuntos para ver qué método es mejor.
28. Establezca SET NOCOUNT ON al comienzo de todos los procedimientos almacenados y disparadores, y configure SET NOCOUNT OFF al final. No es necesario enviar un mensaje DONE_IN_PROC al cliente después de ejecutar cada declaración de procedimientos almacenados y disparadores.
29. Intente evitar devolver grandes cantidades de datos al cliente. Si la cantidad de datos es demasiado grande, debe considerar si los requisitos correspondientes son razonables.
30. Intente evitar operaciones de grandes transacciones y mejore la concurrencia del sistema. 
发布了23 篇原创文章 · 获赞 47 · 访问量 14万+

Supongo que te gusta

Origin blog.csdn.net/wenjianzhiqin/article/details/81017468
Recomendado
Clasificación