Tecniche di ottimizzazione del database per i dilettanti

Question

Possiamo ottenere un elenco delle tecniche di ottimizzazione di base in corso (qualsiasi cosa, dalla modellazione all'interrogazione, alla creazione di indici, alle visualizzazioni all'ottimizzazione delle query). Sarebbe bello avere una lista di questi, una tecnica per risposta. Come hobbista, lo troverei molto utile, grazie.

E per non essere troppo vago, diciamo che stiamo usando un DB maintream come MySQL o Oracle e che il DB conterrà 500.000-1m circa di record su ~ 10 tabelle, alcuni con contorni di chiave esterna , tutti utilizzano i più comuni motori di archiviazione (ad esempio: InnoDB per MySQL). E, naturalmente, le basi come i PK sono definiti così come i vincoli FK.

Answer 1

Ulteriori informazioni sugli indici e utilizzarli correttamente. generale *, seguire queste linee guida:

• Ogni tabella dovrebbe avere un indice cluster
• Campi usati per i filtri e le specie sono buoni candidati per l'indicizzazione
• Più selettivi campi sono migliori candidati per l'indicizzazione
• Per prestazioni ottimali su query cruciali, progettare "indici di copertura" per tali query
• Assicurarsi che gli indici siano effettivamente utilizzati e rimuovere quelli che non sono
• Se la tabella dispone di 15 campi, e si effettua 15 indici, ciascuno con un solo campo, si sta facendo male :)

* Ci sono alcune eccezioni a queste regole, se si sa cosa si stai facendo. La mia esperienza è Microsoft SQL Server, ma suppongo che la maggior parte di questo consiglio si applichi a un RDMS diverso.

Answer 2

Quando si parla della progettazione del database, verificare la normalizzazione del database, ad es. l'articolo di Wikipedia: Normal forms.

Se si dispone di un buon design e ancora è necessario ottimizzare le prestazioni, provare Denormalisation.

Se si dispone di esigenze specifiche che non sono coperte dal modello relazionale in modo efficiente, consultare altri modelli coperti dal termine NoSQL.

Answer 3

IMO, l'ottimizzazione di gran lunga migliore consiste nel far corrispondere il modello di dati al dominio del problema per il quale è stato creato. In caso contrario, il sintomo risultante è costituito da query difficili da scrivere o convolute al fine di ottenere le informazioni desiderate e che in genere aumenta quando i report vengono creati rispetto al database. Pertanto, nella progettazione di un database è utile avere un'idea dei tipi e della natura delle informazioni, come i report, che gli utenti vorranno dal sistema.

Answer 4

Un design che modella concisamente il tuo problema è sempre un buon inizio. L'overgeneralization del modello di dati può portare a problemi di prestazioni. Ad esempio, ho sentito rapporti di progetti che cercano la massima flessibilità che utilizzano l'RDBMS come un "nome/valore" stupido, e le prestazioni risultanti sono state terribili.

Una volta installato un buon progetto, utilizzare gli strumenti forniti da RDBMS per ottenere prestazioni ottimali. PK a campo singolo (senza materiali compositi), ma chiavi aziendali composte come indice con vincolo univoco, utilizzo di tipi di dati appropriati, ad es. utilizzando tipi numerici appropriati per valori numerici piuttosto che char o simili.Dovrebbero essere considerati anche gli attributi fisici dell'hardware su cui è in esecuzione RDBMS, dal momento che la maggior parte del tempo di interrogazione è spesso I/O su disco, ma ovviamente non lo si dà per scontato - utilizzare un profiler per scoprire dove sta andando il tempo .

A seconda del rapporto di aggiornamento/query, le viste materializzate/viste indicizzate possono essere utili per migliorare le prestazioni per le query lente. L'alternativa di un uomo povero consiste nell'utilizzare i trigger per richiamare una procedura che popola la tabella con il risultato di una visualizzazione lenta e con scarsa frequenza di visualizzazione.

L'ottimizzazione delle query è un po 'un'arte nera poiché è spesso dipendente dal database, ma alcune regole sono fornite qui - Optimizing SQL.

Infine, anche se probabilmente al di fuori dell'ambito previsto della domanda, utilizzare un livello di accesso ai dati valido nell'applicazione ed evitare la tentazione di eseguire il rollover - esistono sicuramente implementazioni testate e performanti disponibili per tutte le principali lingue. L'uso della memorizzazione nella cache a livello di accesso ai dati, livello intermedio e livello applicazione può aiutare a migliorare notevolmente le prestazioni.

Answer 5

Alcune ottimizzazioni di query/schema:

• essere consapevoli quando si utilizza DISTINCT o GROUP BY. Trovo che molti nuovi sviluppatori utilizzeranno DISTINCT in luoghi in cui non è realmente necessario o potrebbero essere riscritti in modo più efficiente utilizzando un'istruzione Exists o una query derivata.

• Attenzione agli attacchi a sinistra. Troppo spesso trovo che nuovi sviluppatori SQL ignoreranno lo schema e useranno i Left Joins dove non sono realmente necessari. Per esempio:

Select 
From Orders 
    Left Join Customers 
     On Customers.Id = Orders.CustomerId

Se Orders.CustomerID è una colonna obbligatoria, allora non è necessario utilizzare una sinistra join.

• Diventa uno studente di nuove funzionalità. Attualmente, MySQL non supporta le espressioni di tabella comune, il che significa che alcuni tipi di query sono ingombranti e probabilmente più lenti a scrivere di quanto sarebbero se le CTE fossero supportate. Tuttavia, ciò non sarà vero per sempre. Tieni traccia delle nuove funzionalità di sintassi in MySQL che potrebbero essere utilizzate per rendere più efficienti le query esistenti.

• Non è necessario utilizzare le chiavi surrogate ovunque. Potrebbero esserci tabelle più adatte a una chiave intelligente (ad esempio le abbreviazioni degli Stati Uniti, i codici valuta, ecc.) Che consentirebbero agli sviluppatori di evitare ulteriori join in molti casi.

• Se possibile, trovare le modalità di archiviazione dei dati su un server OLAP o di report. Più piccolo è possibile rendere i dati di produzione, più veloce sarà eseguito.

Answer 6

Adottare un approccio olistico all'ottimizzazione.

Considerare l'impatto di dischi lenti, latenza di rete, mancanza di memoria e carico del server.

Answer 7

Utilizzare meno query quando possibile. Utilizza "UNISCI" e raggruppa le tabelle in modo che una singola query fornisca i risultati.

Un buon esempio è il Modified Preorder albero trasversale (MPTT) per ottenere tutti un nodo della struttura genitori, ordinata, in una singola query.