Trucchi preferiti per l'ottimizzazione delle prestazioni

Ecco l'elenco pratico e dandy di cose che do sempre a qualcuno che mi chiede informazioni sull'ottimizzazione.
Utilizziamo principalmente Sybase, ma la maggior parte dei consigli si applica a tutta la linea.

SQL Server, ad esempio, viene fornito con una serie di bit di monitoraggio/ottimizzazione delle prestazioni, ma se non hai nulla del genere (e forse anche se lo fai), prenderei in considerazione quanto segue...

99% dei problemi Ho visto che sono causati dall'inserimento di troppe tabelle in un join . La soluzione per questo è eseguire metà del join (con alcune tabelle) e memorizzare nella cache i risultati in una tabella temporanea. Quindi esegui il resto della query unendo su quella tabella temporanea.

Elenco di controllo per l'ottimizzazione delle query

• Esegui UPDATE STATISTICS sulle tabelle sottostanti
  • Molti sistemi lo eseguono come un lavoro settimanale pianificato
• Elimina i record dalle tabelle sottostanti (possibilmente archivia i record eliminati)
  • Considera di farlo automaticamente una volta al giorno o una volta alla settimana.
• Ricostruisci indici
• Ricostruisci tabelle (dati bcp in uscita/ingresso)
• Esegui il dump / Ricarica il database (drastico, ma potrebbe correggere il danneggiamento)
• Crea un nuovo indice più appropriato
• Esegui DBCC per vedere se c'è un possibile danneggiamento nel database
• Blocchi/Blocchi
  • Assicurati che nessun altro processo sia in esecuzione nel database
    • Soprattutto DBCC
  • Stai utilizzando il blocco a livello di riga o pagina?
  • Blocca le tabelle esclusivamente prima di avviare la query
  • Verifica che tutti i processi accedano alle tabelle nello stesso ordine
• Gli indici vengono utilizzati in modo appropriato?
  • I join utilizzeranno index solo se entrambe le espressioni sono esattamente dello stesso tipo di dati
  • L'indice verrà utilizzato solo se i primi campi dell'indice corrispondono nella query
  • Gli indici raggruppati vengono utilizzati dove appropriato?
    • dati dell'intervallo
    • campo WHERE tra valore1 e valore2
• I join piccoli sono dei buoni join
  • Per impostazione predefinita, l'ottimizzatore considererà solo le tabelle 4 alla volta.
  • Ciò significa che nei join con più di 4 tabelle, ha buone possibilità di scegliere un piano di query non ottimale
• Interrompi il Join
  • Puoi interrompere l'unione?
  • Preseleziona le chiavi esterne in una tabella temporanea
  • Fai metà del join e inserisci i risultati in una tabella temporanea
• Stai usando il giusto tipo di tabella temporanea?
  • #temp le tabelle possono funzionare molto meglio di @table variabili con grandi volumi (migliaia di righe).
• Mantieni le tabelle di riepilogo
  • Crea con trigger sulle tabelle sottostanti
  • Costruisci giornalmente / ogni ora / ecc.
  • Crea ad hoc
  • Costruisci in modo incrementale o smonta/ricostruisci
• Guarda qual è il piano di query con SET SHOWPLAN ON
• Guarda cosa sta realmente accadendo con SET STATS IO ON
• Forza un indice usando il pragma:(index:myindex)
• Forza l'ordine della tabella utilizzando SET FORCEPLAN ON
• Sniffing dei parametri:
  • Dividi la procedura memorizzata in 2
  • chiama proc2 da proc1
  • consente all'ottimizzatore di scegliere index in proc2 se @parameter è stato modificato da proc1
• Puoi migliorare il tuo hardware?
• A che ora corri? C'è un momento più tranquillo?
• Il server di replica (o un altro processo non-stop) è in esecuzione? Puoi sospenderlo? Eseguilo ad es. ogni ora?