¿Cuál fue la mejor optimización de SQL en una consulta de rendimiento lento?

Question

Hablando con un colega mío. Estaba caminando con un salto en su paso, en el camino a la máquina de café.

Le pregunté "¿Qué pasa con la caminata 'enjambre'?", Dijo, "¡Acabo de reducir una consulta de dos horas de duración a 40 segundos! Se siente tan bien".

Alteró un procedimiento almacenado, que utilizaba cursores e introdujo una tabla temporal, que se refactivó a partir del conjunto de datos original; le enviaré un correo electrónico pronto para obtener más información sobre la implementación real.

Pero al final, él estaba zumbando.

La pregunta es, ¿qué SQL, que se te queda grabado y te hace vibrar, mientras optimizas las consultas de bajo rendimiento?

Answer 1

Disculpe, no suelo entusiasmarme con ese tipo de cosas, pero la mayoría de las situaciones han sido bastante básicas, supervisando el rendimiento de las consultas y agregando índices para acelerarlas.

Aumentando la velocidad del código "real" que he escrito al cambiar las estructuras de datos y los algoritmos dentro de la clase, es donde obtengo mi rumor (y la reputación como el mejor recurso para las soluciones de rendimiento en el trabajo).

Answer 2

oye en el iPhone que utiliza SQLite, i enseguida redujo el tiempo de procesamiento de la base de datos de 40 segundos a 2 segundos con el uso de transacciones de escritura exclusivos ... Yo estaba muy feliz haciendo esto

ya que este era mi primera experiencia de sql en un dispositivo integrado: bastante diferente de las cosas habituales relacionadas con el servidor (índices, normalizaciones, etc.)

--- en lo que respecta a los servidores, los índices son una verdadera bendición. Además, si toma un poco de dolor y se deshace de tantos nulos como pueda en su tabla, se sorprenderá con las ganancias de rendimiento: no muchos desarrolladores se enfocan en nulos, generalmente van con índices y otras cosas documentadas

algunas otras formas menos explotadas: usar xml para procesar varias inserciones por lotes/actualizaciones/eliminaciones a 1 vez en lugar de hacer 1 inserción a la vez - en sql 2005 esto puede ser súper genial

Answer 3

Tengo que decir cuando aprendí cómo para crear y usar índices cubiertos. Ahora, ESO fue un refuerzo de rendimiento.

Answer 4

Siempre es bueno tomar una consulta mal escrita, cargada de cursor y eliminar cursores, cortar el código a la mitad, y mejorar el rendimiento de muchas maneras.

Algunas de las mejores mejoras son en claridad (y a menudo dan como resultado buenos aumentos de rendimiento también).

Answer 5

que respondieron a esta en una pregunta anterior ("Biggest performance improvement you’ve had with the smallest change?"), sin embargo, es una mejora tan simple, pero uno que es y puede ser tan a menudo se pasa por alto, que vale la pena repetirlo:

Indexes!

Answer 6

Uso de SQL BULKIMPORT para reducir varias horas de código INSERT heredado a menos de un minuto.

Answer 7

Todo se trata de índices. Y evitar cosas estúpidas que los hacen inútiles.

Answer 8

Bueno, tuvimos una situación similar en la que tuvimos una consulta lenta en un sitio de Open Freeway.La respuesta no fue tanto optimizar la consulta, sino optimizar el servidor en el que estaba. Aumentamos el límite de caché y el tamaño de caché para que el servidor no ejecutara la consulta tan a menudo.

Esto ha aumentado enormemente la velocidad del sistema y finalmente ha hecho feliz al cliente! :)

No es del todo el calibre de las habilidades originales de optimización de mensajes, ¡pero definitivamente nos hizo vibrar!

Answer 9

Dividir un procedimiento almacenado ridículamente largo, que hizo una gran cantidad de "si es después de las 5 pm, devuelve este bit de sql" y que tardó más de 20 segundos en ejecutarse, en un conjunto de procedimientos almacenados que se llamaron por un control de sp, y redujo los tiempos a respuestas de subsegundo.

Answer 10

Cambiando el orden de condiciones dentro de la cláusula WHERE para que filtre la condición más discriminativa primero (mientras que al mismo tiempo se eliminan los índices de columnas no discriminatorias como el género).

Answer 11

una palabra, consultas dinámicas

Si serching con un gran número de parámetros que puede descartarlos de la cadena SQL. Esto ha acelerado mis consultas dramáticamente y con facilidad.

Create PROCEDURE dbo.qryDynamic 
( 

@txtParameter1 nvarchar(255), 
@txtParameter2 nvarchar(255), 

AS 
SELECT  qry_DataFromAView.* 
FROM   qry_DataFromAView 
BEGIN 

    DECLARE @SQL nvarchar(2500) 
    DECLARE @txtJoin nvarchar(50) 

    Set @txtJoin = ' Where ' 

    SET @SQL = 'SELECT  qry_DataFromAView.* 
       FROM   qry_DataFromAView' 

    IF @txtParameter1 is not null 
    Begin 
     SET @SQL=@SQL + @txtJoin + ' Field1 LIKE N''%'' + @dynParameter1 + N''%'') ' 
     Set @txtJoin = ' And ' 
    end 


    IF @txtParameter2 is not null 
    Begin 
     SET @SQL=@SQL + @txtJoin + ' Field2 LIKE N''%'' + @dynParameter2 + N''%'') ' 
     Set @txtJoin = ' And ' 
    end 

    SET @SQL=@SQL + ' ORDER BY Field2' 


    Exec sp_executesql @SQL, N'@dynParameter1 nvarchar(255), @dynParameter2 nvarchar(255)', @dynParameter1 = @txtParameter1 ,@dynParameter2 = @txtParameter2 

END 
GO 

Answer 12

vuelta en el día, he trabajado en un sistema/CICS DB2, escrito en COBOL. Muchas de nuestras consultas realizaban escaneos completos de tablas (y lentos) aunque teníamos todos los índices adecuados y las cláusulas WHERE.

Resultó (y puede tener esto al revés, ha sido 15 años) que el problema era que estábamos usando PIC S9(n) COMP en WORKING STORAGE de los parámetros de consulta, pero DB2 querido PIC S9(n) COMP-3. Al utilizar el tipo de datos incorrecto, DB2 tuvo que realizar un escaneo completo de la tabla para convertir los valores en la base de datos al valor que estábamos transfiriendo. Cambiamos nuestras definiciones de variables y las consultas pudieron usar los índices ahora, lo que drásticamente mejoró nuestro rendimiento

Answer 13

que tenían un brillo cálido después de haber sido capaz de utilizar una consulta Cruz Tab para el desguace de montones (término técnico) de procesamiento y operaciones de búsqueda ...

por lo general es cosas simples como la adición de índices o sólo para conseguir los datos que necesita , pero cuando encuentras un problema que se ajusta a una respuesta que has visto antes ... ¡buenos momentos!

Answer 14

(A mitad de camino del tema)

Reescribí un procedimiento almacenado en la línea 3000 LINQ2SQL/C#. El procedimiento almacenado hizo malabares con muchos datos entre un grupo de tablas temporales no indexadas. La versión de LINQ2SQL leyó los datos en un par de Dictionaries y ILookups y luego me uní a los datos manualmente con el código simple de C#.

El procedimiento almacenado tomó aproximadamente 20 segundos y la versión LINQ2SQL/C# tomó 0.2 segundos.

Answer 15

que tenía una consulta que fue escrito originalmente para SQL Server 6.5, que no apoyó la SQL 92 sintaxis de combinación, es decir

select foo.baz 
from foo 
    left outer join bar 
    on foo.a = bar.a 

en cambio se escribe como

select foo.baz 
from foo, bar 
where foo.a *= bar.a 

La consulta había sido durante un tiempo, y los datos relevantes se han acumulado para hacer que la consulta se ejecute demasiado lento, cerca de 90 segundos para completar.En el momento en que surgió este problema, nos habíamos actualizado a SQL Server 7.

Después de rebuscar con índices y otros Easter-egging, cambié la sintaxis de unión para que sea compatible con SQL 92. El tiempo de consulta se redujo a 3 segundos.

No creo que vuelva a sentir eso nunca más. Yo era un héroe f% $^ing.