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

optimizar inner join sql server

Question

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

Answer 1

Hay un par de cosas que puede ver 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 la desnormalización de su base de datos para reducir las uniones

3. Evite los bucles (es decir, busca cursores), se adhieren a las operaciones de ajuste.

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

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

6. Use 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. Conceptos básicos de las estadísticas en SQL Server 2005

8. Asegúrese de que sus índices no estén fragmentados. Reducir la fragmentación del índice de SQL Server

9. Asegúrate de que tus tablas no estén fragmentadas. Cómo detectar fragmentación de tabla en SQL Server 2000 y 2005

Answer 2

Asegúrese de tener los índices correctos sobre 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 3

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

Answer 4

En Oracle puede ver el plan de explicación para comparar variaciones en su consulta

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.

Como agregar índices puede ralentizar las escrituras de datos, necesita monitorear el desempeño para asegurarse de no matar el rendimiento de escritura de la base de datos, pero es allí donde usar una buena herramienta de análisis de consultas puede ayudarlo a equilibrar las cosas en consecuencia.

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.

Por otro lado, cuando comencé a aprender a optimizar las consultas, ejecuté sql server query profiler contra un rastreo, 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ística
• en Microsoft Stack, Database Engine Tuning Advisor

Answer 8

• Use claves primarias
• Evitar seleccionar *
• Sea tan específico como pueda al construir sus declaraciones condicionales
• La des-normalización a menudo puede ser más eficiente
• Las variables de tabla y tablas temporales (donde estén disponibles) a menudo serán mejores que usar una tabla fuente grande
• Vistas particionadas
• Emplear índices y restricciones

Answer 9

Algunos otros puntos (los míos se basan en el servidor SQL, ya que cada db backend tiene sus propias implementaciones que pueden ser válidas o no para todas las bases de datos):

Evite las subconsultas correlacionadas en la parte de selección de una instrucció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 descubre que con frecuencia realiza uniones que tienen funciones en ellos, 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 utilizando una declaració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.

NOT EXISTS es generalmente más rápido que NOT IN o usa una combinación left con una cláusula WHERE de ID = null

En una consulta de ACTUALIZACIÓN, agregue una condición WHERE para asegurarse de que no está actualizando 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 los consultará con frecuencia o para informes grandes. 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 los UDF escalares, pueden ser más lentos que poner el código en línea.

La tabla de temperatura 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.

Esto parece obvio, pero no creerías con qué frecuencia 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 a 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 usan, así que piense en 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 el uso de SQL estándar (esa es una de las formas en que venden su producto), así que conozca las características de su 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).

Answer 10

Use una declaración para manejar el filtrado de consultas. 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

Las subconsultas dentro de una instrucción con pueden terminar siendo las mismas que las vistas en línea o las tablas temporales generadas automáticamente. 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

Conozca lo que sucede realmente bajo el capó: debería ser capaz de comprender los siguientes conceptos en detalle:

• Índices (no solo lo que son, sino cómo funcionan).
• Los índices agrupados frente a las tablas asignadas en el montón.
• Búsqueda de texto y binarios y cuándo pueden alinearse.
• Factor de relleno
• Cómo se graban los registros para actualizar / eliminar.
• Cuando se producen divisiones de página y por qué.
• Estadísticas, y cómo afectan varias velocidades de consulta.
• El planificador de consultas y la forma en que 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).