Qual è stata la migliore ottimizzazione SQL, su una query con prestazioni lente?

Question

Solo parlando con un mio collega. Stava camminando con un salto nel suo passo, sulla strada per la macchina del caffè.

Gli ho chiesto "che cos'ha la" brulicante "passeggiata?", Ha detto, "Ho ridotto una query lunga due ore a 40 secondi! È davvero bello".

Ha modificato una procedura memorizzata, che utilizzava i cursori e ha introdotto una tabella temporanea, che è stata rifattorizzata dal set di dati originale. Lo manderò presto via e-mail per ottenere maggiori informazioni sull'effettiva implementazione.

Ma alla fine, stava ronzando.

La domanda è, quale SQL, che ti rimane in testa e ti ha fatto vibrare ottimizzando le query a bassa esecuzione?

Answer 1

Scusate, non tendo a ottenere un ronzio da quel genere di cose, ma la maggior parte delle situazioni sono state piuttosto elementari, monitorando le prestazioni delle query e aggiungendo indici per velocizzarle.

Ora aumentando la velocità del codice "reale" che ho scritto modificando le strutture di dati e gli algoritmi all'interno della classe, è lì che ottengo il mio ronzio (e la reputazione di un uomo di riferimento per le correzioni delle prestazioni sul lavoro).

Answer 2

hey su iPhone che utilizza SQLite, ho subito ridotto del tempo di elaborazione del database da 40 secondi a 2 secondi con l'uso di operazioni di scrittura esclusivi ... ero super felice facendo questo

in quanto questo è stato il mio la prima esperienza di SQL su un dispositivo incorporato - molto diversa dalle solite cose relative al server (indici, normalizzazioni, ecc. ecc.)

--- per quanto riguarda i server, gli indici sono una vera benedizione. Inoltre, se si prende un po 'di dolore e si eliminano più null possibile nel proprio tavolo, si sarebbe sorpresi con i guadagni in termini di prestazioni - non molti sviluppatori si concentrano sui valori null, di solito utilizzano indici e altre cose documentate

pochi altri modi meno sfruttati - utilizzando xml per elaborare più inserimenti/aggiornamenti/eliminazioni batch a 1 go invece di fare 1 inserto alla volta - in sql 2005 questo può essere super cool

Answer 3

Devo dire quando ho imparato come per creare e utilizzare indici coperti. Ora, CHE era un aumento di prestazioni.

Answer 4

È sempre piacevole prendere una query mal scritta, carica di cursore ed eliminare i cursori, tagliare il codice della metà e migliorare le prestazioni in molti modi.

Alcuni dei migliori miglioramenti sono in chiarezza (e spesso danno buoni risultati anche in termini di prestazioni).

Answer 5

ho risposto questo su una domanda precedente ("Biggest performance improvement you’ve had with the smallest change?"), tuttavia, si tratta di un semplice miglioramento tale, ma uno che è e può essere così spesso trascurato, che vale la pena ripeterlo:

Indexes!

Answer 6

utilizzando SQL di BULKIMPORT per ridurre diverse ore di codice INSERT ereditato a meno di un minuto.

Answer 7

Si tratta di indici. Ed evitando cose stupide che li rendono inutili.

Answer 8

Bene, abbiamo avuto una cosa simile in cui avevamo una query lenta su un sito di Open Freeway.La risposta non era tanto ottimizzare la query, ma ottimizzare il server su cui si trovava. Abbiamo aumentato il limite della cache e la dimensione della cache in modo che il server non eseguisse la query così spesso.

Questo ha aumentato enormemente la velocità del sistema e alla fine ha reso il cliente felice! :)

Non proprio il calibro delle competenze di ottimizzazione dei post originali, ma sicuramente ci ha fatto divertire!

Answer 9

Suddivisione di una procedura memorizzata incredibilmente lunga, che ha comportato una grande quantità di "se è dopo le 17:00, restituisce questo bit di SQL" e che ha impiegato più di 20 secondi per essere eseguito in un insieme di stored procedure chiamate da uno sp controllante, e ha ottenuto i tempi fino alle risposte sottocondensate.

Answer 10

Modifica dell'ordine delle condizioni all'interno della clausola WHERE in modo da filtrare prima la condizione più discriminante (mentre allo stesso tempo vengono rimossi gli indici da colonne non discriminanti come il genere).

Answer 11

One Word, Dynamic Query

Se serching con un gran numero di parametri è possibile sconto dalla stringa SQL. Questo ha velocizzato le mie domande in modo drammatico e con facilità risolutiva.

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

Nel corso della giornata, ho lavorato su un sistema CICS/DB2, scritto in COBOL. Molte delle nostre query eseguivano scansioni complete della tabella (e lente) anche se avevamo tutti gli indici appropriati e le clausole WHERE.

Si è scoperto (e forse ho questo al contrario, sono passati 15 anni) che il problema era che stavamo usando PIC S9(n) COMP in WORKING STORAGE per i parametri di query, ma DB2 voluto PIC S9(n) COMP-3. Usando il tipo di dati errato, DB2 ha dovuto eseguire una scansione completa della tabella per convertire i valori nel database al valore che stavamo passando. Abbiamo cambiato le nostre definizioni delle variabili e le query erano in grado di utilizzare gli indici ora, il che in modo drammatico migliorato le nostre prestazioni.

Answer 13

ho avuto una luce calda dopo essere stato in grado di utilizzare una query Tab Croce di rottamare una gran quantità (termine tecnico) di lavorazione e le ricerche ...

Di solito è le cose semplici come l'aggiunta di indici o solo ottenere i dati necessari , ma quando trovi un problema che si adatta a una risposta che hai visto prima ... bei tempi!

Answer 14

(A metà strada di argomento)

ho riscritto una stored procedure 3000 linea in LINQ2SQL/C#. La stored procedure ha destreggiato un sacco di dati tra una serie di tabelle temporanee non indicizzate. La versione LINQ2SQL leggeva i dati in un paio di dizionari e ILookups e quindi ho unito i dati manualmente con un semplice vecchio codice C#.

La stored procedure ha richiesto circa 20 secondi e la versione LINQ2SQL/C# ha impiegato 0,2 secondi.

Answer 15

ho avuto una query che è stato originariamente scritto per SQL Server 6.5, che non supportano il codice SQL 92 join sintassi, cioè

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

è stato invece scritto come

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

L'interrogazione era stata in giro per un po 'e i dati rilevanti si sono accumulati per rendere la query eseguita troppo lentamente, con una durata di 90 secondi.Nel momento in cui questo problema si è verificato, abbiamo eseguito l'aggiornamento a SQL Server 7.

Dopo aver parlato con gli indici e altri egg-egging, ho modificato la sintassi del join per essere conforme a SQL 92. Il tempo di interrogazione è sceso a 3 secondi.

Non credo che avrò mai più quella sensazione. Ero un f% $^di eroe.