Tecniche di ottimizzazione del database per dilettanti

Question

Possiamo ottenere un elenco di tecniche di ottimizzazione di base che vanno (qualsiasi cosa dalla modellazione alla interrogazione, la creazione di indici, vista l'ottimizzazione delle query). Sarebbe bello avere un elenco di questi, una tecnica per ogni risposta. Come un hobbista avrei trovato questo per essere molto utile, grazie.

E per il bene di non essere troppo vago, diciamo che stiamo usando un maintstream DB come MySQL o Oracle, e che il DB conterrà 500,000-1m o giù di lì record in tutto ~ 10 tavoli, alcuni con vincoli chiave esterna, il tutto utilizzando i motori più conservativa tipica (es: InnoDB per MySQL). E, naturalmente, i principi fondamentali, come PK sono definiti così come vincoli FK.

Answer 1

.

Ulteriori informazioni su indici e utilizzarli in modo corretto * In 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
• Altro selettivo campi sono migliori candidati per l'indicizzazione
• Per ottenere le migliori prestazioni su query cruciali, di design "che copre gli indici" per le query
• Assicurati che il tuo indici sono 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 sta facendo. La mia esperienza è Microsoft SQL Server, ma vorrei presumere la maggior parte di questo consiglio sarebbe ancora applicarsi a un diverso RDMS.

Answer 2

IMO, di gran lunga la migliore ottimizzazione è quello di avere il modello di dati adatta il dominio del problema per il quale è stato costruito. Quando ciò non avviene, il sintomo risultante è difficile da scrittura o query contorto al fine di ottenere le informazioni desiderate e che di solito si impenna quando i rapporti sono costruiti in base al database. Così, in progettazione di un database aiuta ad avere un'idea per quanto riguarda i tipi e la natura delle informazioni, quali i rapporti, che gli utenti vorranno dal sistema.

Answer 3

Quando si parla di progettazione di database, controlla la normalizzazione dei database, per esempio voce di Wikipedia:. Forme normali

Se si dispone di un buon design e ancora è necessario per ottimizzare le prestazioni, prova a Denormalizzazione .

Se avete esigenze specifiche che non sono coperti da modello relazionale in modo efficiente, occhiata a altri modelli coperti dal termine NoSQL .

Answer 4

Alcuni di query / ottimizzazioni schema:

• Essere consapevoli quando si utilizza DISTINCT o GROUP BY. Trovo che molti nuovi sviluppatori utilizzeranno DISTINCT in luoghi dove in realtà non è necessario o potrebbe essere riscritto in modo più efficiente utilizzando un EXISTS o una query derivata.

• Essere consapevoli della entra a far parte di sinistra. Troppo spesso trovo nuovi sviluppatori SQL ignorare lo schema in atto e utilizzare entra a far parte di sinistra, dove in realtà non sono necessari. Ad 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.

• essere uno studente di nuove funzionalità. Attualmente, MySQL non supporta le espressioni comuni-tavolo che significa che alcuni tipi di query sono ingombranti e, probabilmente, più lento a scrivere di quanto lo sarebbero se CTE sono stati sostenuti. Tuttavia, ciò non sarà vero per sempre. Tenere il passo sulle nuove funzionalità di sintassi in MySQL che potrebbero essere utilizzati per rendere le query esistenti in modo più efficiente.

• Non è necessario usare chiavi surrogate ovunque. Ci potrebbe essere tavoli più adatto a una chiave intelligente (ad esempio abbreviazioni stato US, Codici Valuta ecc) che consentirà agli sviluppatori di evitare ulteriore unisce in molti casi.

• Se possibile, trovare il modo di archiviare i dati a un server di report OLAP o. Il più piccolo si può fare i dati di produzione, più velocemente verrà eseguito.

Answer 5

Un design che i modelli in modo coinciso il vostro problema è sempre un buon inizio. Overgeneralizing il modello di dati può portare a problemi di prestazioni. Per esempio, ho sentito notizie di progetti che lottano per la super-flessibilità che utilizzano i RDBMS come un muto negozio "nome / valore" - e le prestazioni risultante era raccapricciante

.

Una volta che una buona progettazione è a posto, quindi utilizzare gli strumenti forniti dal RDBMS per aiutarla a ottenere buone prestazioni. PK singolo campo (non compositi), ma chiavi di business compositi come un indice con vincolo unico, uso di tipi appropriati di dati, ad esempio, utilizzando opportuni tipi numerici per i valori numerici anziché char o simili. attributi fisici dell'hardware RDBMS è in esecuzione su dovrebbero essere considerati, dal momento che la maggior parte del tempo di query è spesso disco I / O - ma naturalmente non prendere questo per scontato - utilizzare un profiler per scoprire dove il tempo sta andando .

A seconda del rapporto di aggiornamento / interrogazione, viste materializzate / viste indicizzate possono essere utili per migliorare le prestazioni per le query marcia lenta. Un'alternativa del povero uomo è quello di utilizzare i trigger per richiamare una procedura che popola la tabella con il risultato di una visione lenta esecuzione di rado-cambiato.

l'ottimizzazione delle query è un po 'di magia nera dal momento che è spesso di database-dipendente, ma alcune regole pratiche sono riportati qui - Ottimizzazione SQL .

Infine, anche se forse al di fuori del campo di applicazione previsto della tua domanda, utilizzare un livello di accesso ai dati di buona nell'applicazione, ed evitare la tentazione di rotolare il proprio - ci sono sicuramente testate e implementazioni performanti disponibili per tutte le principali lingue. L'uso del caching a livello di accesso ai dati, livello intermedio e livello di applicazione possono contribuire a migliorare notevolmente le prestazioni.

Answer 6

uso Do meno di query , quando possibile. Utilizzare "Join", e di gruppo le tabelle in modo che una singola query dà i risultati.

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

Answer 7

adottare un approccio olistico per l'ottimizzazione.

Si consideri l'impatto dei dischi lenti, latenza di rete, mancanza di memoria, e il carico del server.