Buone risorse per l'apprendimento della parte di ottimizzazione del database

Question

Sono bravo a parte di programmazione di database (sql) ma voglio andare avanti nella parte di ottimizzazione del database come: dove e quando agli indici, come decidere quale query è migliore rispetto ad altri, come ottimizzare il database. Puoi guidarmi qualche buona risorsa o libro che possa portarmi a questo?

Answer 1

Inside Microsoft SQL Server 2005: Query Tuning and Optimization,

Inside Microsoft SQL Server 2005: T-SQL Querying

Inside Microsoft SQL Server 2005: The Storage Engine

hanno spiegazione molto profonda e completa di ottimizzare l'esecuzione di query SQL server.

Answer 2

SQL Server Query Performance Tuning Distilled, Second Edition

Answer 3

Recentemente mi sono concentrato su questo per la mia azienda e ho imparato alcune cose interessanti sull'ottimizzazione delle query.

Ho eseguito SQL Profiler per mezz'ora alla volta e ho registrato query che richiedevano 1000 letture o più (quindi successive che richiedevano 50 o più CPU).

Inizialmente mi sono concentrato su singole query con le letture e CPU più elevate. Tuttavia, dopo aver scritto i log in un database, sono stato in grado di interrogare i risultati aggregati per vedere quali query richiedevano le letture e CPU più aggregate. Il targeting di questi ha aiutato molto di più del solo targeting delle query più costose.

La query più costosa può essere eseguita una volta al giorno, quindi è bene ottimizzarla. Tuttavia, se la 10a query più costosa viene eseguita 100 volte all'ora, è molto più utile ottimizzarla per prima.

Ecco un riassunto di quello che ho imparato finora, che può aiutare a iniziare a identificare le query per l'ottimizzazione:

A Beginner's Guide to Database Query Optimization

Highly Inefficient Linq Queries that Break Database Indexing

An Obscure Performance Pitfall for Test Accounts and Improperly Indexed Database Tables

Answer 4

Trova alcuni suggerimenti per l'ottimizzazione di database/query.

applicare funzioni ai parametri, non colonne

Uno degli errori più comuni riscontrati quando guardando le query di database, è l'uso improprio delle funzioni sulle tabelle del database. Ogni volta che è necessario applicare una funzione a una colonna e convalidare il risultato su un valore, è opportuno verificare se è disponibile la funzione inversa che è possibile applicare alla colonna specificata. In questo modo, il motore del database può utilizzare un indice su quella colonna e non è necessario definire un indice basato sul funzionamento.

una tabella 60 righe senza indici di sorta, la seguente query

SELECT ticker.SYMBOL, 
ticker.TSTAMP, 
ticker.PRICE 
FROM ticker 
WHERE TO_CHAR(ticker.TSTAMP, 'YYYY-MM-DD') = '2011-04-01' 

esegue in 0.006s, mentre il "reverse" ricerca

SELECT ticker.SYMBOL, 
ticker.TSTAMP, 
ticker.PRICE 
FROM ticker 
WHERE 
ticker.TSTAMP = TO_DATE('2011-04-01', 'YYYY-MM-DD') 

- esegue tra 0.004s

clausola EXISTS al posto di IN (subquery)

Un altro modello osservato in sviluppo di database è che le persone scelgono la facile e la soluzione più conveniente e per questo suggerimento, ci sarà uno sguardo a trovare un elemento in una lista. La soluzione più semplice e conveniente è l'utilizzo dell'operatore IN.

SELECT symbol, tstamp, price 
FROM ticker 
WHERE price IN (3,4,5); 

--o simbolo SELECT, tstamp, prezzo DA ticker DOVE prezzo IN (prezzo SELECT FROM soglia in cui l'azione = 'Buy');

Questo approccio è ok quando abbiamo una piccola lista gestibile. Quando la lista diventa molto grande e quando la lista è dinamica (sarà generata sulla base di parametri che avremo solo in fase di runtime) questo approccio tende a diventare piuttosto costoso per il database. La soluzione alternativa è l'utilizzo dell'operatore esiste come mostrato nel frammento di codice qui sotto:

SELECT symbol, tstamp, price 
FROM ticker t 
WHERE EXISTS (SELECT 1 FROM threshold m WHERE t.price = m.price AND m.action = 'Buy'); 

Questo approccio sarà più veloce perché una volta che il motore ha trovato un colpo, si annullerà cercando, come la condizione è dimostrato vero. Con IN raccoglierà tutti i risultati dalla subquery prima dell'ulteriore elaborazione.