¿Qué técnicas genéricas se pueden aplicar para optimizar las consultas SQL?

Question

¿Qué técnicas se pueden aplicar eficazmente para mejorar el rendimiento de las consultas SQL? ¿Hay alguna regla general que se aplique?

Answer 1

• Use claves primarias
• Evitar seleccione *
• ser lo más específico posible en la construcción de formulación de las condiciones
• La desnormalización a menudo puede ser más eficiente
• Las variables de tabla y las tablas temporales (donde estén disponibles) a menudo serán mejores que usar una tabla fuente grande
• Las vistas con particiones
• índices emplear y limitaciones

Answer 2

Creo que usar el analizador de consultas SQL sería un buen comienzo.

Answer 3

En Oracle se puede ver en la explain plan para comparar las variaciones en su consulta

Answer 4

Asegúrese de que tiene los índices correctos en la mesa. Si utiliza con frecuencia una columna como forma de ordenar o limitar su conjunto de datos, un índice puede marcar una gran diferencia. Vi en un artículo reciente que seleccionar distintos realmente puede ralentizar una consulta, especialmente si no tiene índice.

Answer 5

La optimización obvia para las consultas SELECT es garantizar que tenga índices en las columnas utilizadas para las uniones o en las cláusulas WHERE.

Dado que agregar índices puede ralentizar las escrituras de datos, necesita monitorear el rendimiento para asegurarse de no matar el rendimiento de escritura de la BD, pero es allí donde usar una buena herramienta de análisis de consultas puede ayudarlo.

Answer 6

Lo más importante que puede hacer es buscar escaneos de tablas en el analizador de consultas del servidor sql (asegúrese de activar "mostrar plan de ejecución"). De lo contrario, hay una gran cantidad de artículos en MSDN y en otros lugares que darán buenos consejos.

Como nota aparte, cuando empecé a aprender a optimizar las consultas, ejecuté SQL Server query profiler contra un seguimiento, miré el SQL generado y traté de descubrir por qué era una mejora. El generador de consultas dista mucho de ser óptimo, pero es un comienzo decente.

Answer 7

• índices
• Estadísticas
• en la pila Microsoft, DTA

Answer 8

Aprender lo que realmente está pasando bajo el capó - usted debe ser capaz de entender los siguientes conceptos en detalle:

• Índices (no solo qué son sino cómo funcionan).
• Índices agrupados frente a tablas asignadas en el montón.
• Búsqueda de texto y binario y cuándo pueden alinearse.
• Fill factor.
• Cómo se graban los registros para actualizar/eliminar.
• Cuando se producen divisiones de páginas y por qué.
• Estadísticas, y cómo afectan varias velocidades de consulta.
• El planificador de consultas, y cómo funciona para su base de datos específica (por ejemplo, en algunos sistemas "select *" es lento, en los DB MS-SQL modernos el planificador puede manejarlo).

Answer 9

Hay un par de cosas que puede observar para optimizar el rendimiento de su consulta.

1. Asegúrese de tener el mínimo de datos. Asegúrese de seleccionar solo las columnas que necesita. Reduzca los tamaños de campo a un mínimo.

2. Considere de-la normalización de su base de datos para reducir une

3. evitar bucles (es decir, ir a buscar los cursores), se adhieren a las operaciones de conjuntos.

4. Implemente la consulta como un procedimiento almacenado, ya que está precompilado y se ejecutará más rápido.

5. Asegúrese de tener los índices correctos configurados. Si su base de datos se usa principalmente para buscar, entonces considere más índices.

6. Utilice el plan de ejecución para ver cómo se realiza el procesamiento. Lo que desea evitar es un escaneo de tabla ya que es costoso.

7. Asegúrese de que la Estadística automática esté activada. SQL necesita esto para ayudar a decidir la ejecución óptima. Vea la gran publicación de Mike Gunderloy para más información. Basics of Statistics in SQL Server 2005

8. Asegúrate de que tus índices no estén fragmentados. Reducing SQL Server Index Fragmentation

9. Asegúrate de que tus tablas no estén fragmentadas. How to Detect Table Fragmentation in SQL Server 2000 and 2005

Answer 10

Utilice un con DECLARACIÓN para manejar el filtrado de consulta. Limite cada subconsulta al número mínimo de filas posibles. luego únete a las subconsultas.

WITH 
master AS 
(
    SELECT SSN, FIRST_NAME, LAST_NAME 
    FROM MASTER_SSN 
    WHERE STATE = 'PA' AND 
      GENDER = 'M' 
), 
taxReturns AS 
(
    SELECT SSN, RETURN_ID, GROSS_PAY 
    FROM MASTER_RETURNS 
    WHERE YEAR < 2003 AND 
      YEAR > 2000 
) 
SELECT * 
FROM master, 
    taxReturns 
WHERE master.ssn = taxReturns.ssn 

A subconsultas dentro de una sentencia with pueden terminar por ser el mismo que vistas en línea, o automáticamente tablas temporales generados. En el trabajo que realizo, datos minoristas, encuentro que alrededor del 70-80% del tiempo, hay un beneficio de rendimiento.

100% del tiempo, hay un beneficio de mantenimiento.

Answer 11

Algunos otros puntos (mina están basados ​​en el servidor SQL, ya que cada backend db tiene sus propias implementaciones que pueden o no ser cierto para todas las bases de datos): subconsultas correlacionadas

Evita en la parte de selección de una declaración, son esencialmente cursores.

Diseñe sus tablas para usar los tipos de datos correctos para evitar tener que aplicar funciones sobre ellos para obtener los datos. Es mucho más difícil hacer una fecha matemática cuando almacena sus datos como varchar, por ejemplo.

Si observa que con frecuencia realiza uniones que tienen funciones en ellas, entonces debe pensar en rediseñar sus tablas.

Si sus condiciones WHERE o JOIN incluyen instrucciones OR (que son más lentas), puede obtener una mejor velocidad con una instrucción UNION.

UNION ALL es más rápido que UNION si (y solo si) las dos declaraciones son mutuamente excluyentes y devuelven los mismos resultados de cualquier manera.

NO existe es generalmente más rápido que NO IN o usando una izquierda unirse con una cláusula WHERE de ID = null

En una consulta UPDATE añadir una condición WHERE para asegurarse de que no se actualizan los valores que ya son iguales. ¡La diferencia entre actualizar 10,000,000 de registros y 4 puede ser bastante significativa!

Considere calcular previamente algunos valores si va a consultarlos con frecuencia o para grandes informes. La suma de los valores en un pedido solo debe hacerse cuando se realiza o ajusta el pedido, en lugar de cuando se resumen los resultados de 10,000,000 de millones de pedidos en un informe. Los cálculos previos se deben realizar en desencadenantes para que estén siempre actualizados cuando se modifiquen los datos subyacentes. Y no tiene por qué ser simplemente números, tenemos un campo calculado que concatena los nombres que usamos en los informes.

Tenga cuidado con las UDF escalares, pueden ser más lentas que poner el código en línea.

La tabla de temperaturas tiende a ser más rápida para grandes conjuntos de datos y las variables de tabla son más rápidas para las pequeñas. Además, puede indexar tablas temporales.

El formateo suele ser más rápido en la interfaz de usuario que en SQL.

No devuelva más datos de los que realmente necesita.

Este parece obvio, pero no se puede creer la frecuencia con que termino arreglando esto. No se una a las tablas que no esté utilizando para filtrar los registros o llamar realmente a uno de los campos en la parte seleccionada de la declaración. Las uniones innecesarias pueden ser muy costosas.

Es una muy mala idea crear vistas que llamen a otras vistas que llaman otras vistas. Puede encontrar que se está uniendo a la misma tabla 6 veces cuando solo necesita una sola vez y que crea 100.000,00 registros en una vista subyacente para obtener los 6 que están en su resultado final.

Al diseñar una base de datos, piense en informar no solo la interfaz de usuario para ingresar datos. Los datos son inútiles si no se utilizan, así que piense cómo se usarán después de que estén en la base de datos y cómo se mantendrán o auditarán esos datos. Eso a menudo cambiará el diseño. (Esta es una razón por la cual es una mala idea dejar que un ORM diseñe sus tablas, solo está pensando en un caso de uso para los datos). Las consultas más complejas que afectan a la mayoría de los datos se encuentran en los informes, por lo que se diseñan cambios para ayudar a informar puede acelerar las consultas (y simplificarlas) considerablemente.

Las implementaciones de características específicas de la base de datos pueden ser más rápidas que con SQL estándar (esa es una de las maneras en que venden sus productos), así que conozca las características de la base de datos y descubra cuáles son más rápidas.

Y como no se puede decir con demasiada frecuencia, utilice los índices correctamente, no demasiados o muy pocos. Y haga sus cláusulas WHERE sargable (Capaz de usar índices).