Quali sono alcuni dei metodi/tecniche con gli sviluppatori SQL utilizzati per determinare se una query SQL particolare si scalerà bene con il carico in aumento, le righe nelle tabelle associate aumenteranno ecc.Come capire se una query si ridimensiona bene?
Alcune regole che seguo fanno la differenza.
Non Utilizzare le funzioni per-riga nelle query come if, case, coalesce e così via. Lavora attorno a loro inserendo i dati nel database nel formato che ti servirà, anche se questo implica dati duplicati.
Per esempio, se avete bisogno di ricercare cognomi veloce, memorizzarli in forma entrato e nella loro forma minuscola, e l'indice la forma minuscola. Quindi non devi preoccuparti di cose come select * from tbl where lowercase(surname) = 'smith';
Sì, so che interrompe 3NF ma puoi comunque garantire l'integrità dei dati con un uso giudizioso di trigger o colonne pre-calcolate. Ad esempio, un trigger di inserimento/aggiornamento sulla tabella può forzare la colonna lower_surname da impostare sulla versione in lettere minuscole di surname.
Questo sposta il costo della conversione allo insert/update (che si verifica di rado) e lontano dallo select (che si verifica molto di più). In pratica ammortizzi il costo della conversione.
assicurarsi che ogni colonna utilizzata in una clausola where è indicizzato. Non necessariamente da solo, ma almeno come la parte principale di una chiave composita.
Sempre iniziare in 3NF e tornare solo se si hanno problemi di prestazioni (nella produzione). 3NF è spesso il più facile da gestire e il ripristino deve essere eseguito solo se assolutamente necessario.
Profilo, in produzione (o altrove, purché si disponga di dati e schemi di produzione).L'ottimizzazione del database non è un'operazione di tipo set-and-forget a meno che i dati nelle tabelle non cambino mai (molto raro). Dovresti monitorare e, se possibile, regolare periodicamente per evitare la possibilità che la modifica dei dati ridurrà le prestazioni.
non lo fanno, se non assolutamente necessario, consentire le query al database nudi. Prova a controllare quali query possono essere eseguite. Il tuo lavoro come un DBA sarà molto più difficile se qualche manager può venire avanti e basta eseguire:
select * from very_big_table order by column_without_index;
sul database.
Se i gestori desiderano essere in grado di eseguire query ad-hoc, fornire loro un DBMS (o una replica) clonato in modo che i propri utenti reali (quelli che hanno bisogno di prestazioni) non siano interessati.
Non utilizzare union quando union all sarà sufficiente. Se sai che non ci possono essere duplicati tra due selezioni di un sindacato, non ha senso lasciare che il DBMS provi a rimuoverli.
Analogamente, non utilizzare select distinct su una tabella se si stanno recuperando tutte le colonne della chiave primaria (o tutte le colonne in un vincolo univoco). C'è no possibilità di duplicati in questi casi, quindi, di nuovo, stai chiedendo al DBMS di fare il lavoro non necessario.
Esempio: abbiamo avuto un cliente con una vista utilizzando select distinct * su una delle loro tabelle. Interrogare la visualizzazione è durato 50 secondi. Quando lo abbiamo sostituito con una vista a partire da select *, il tempo scendeva al secondo inferiore. Inutile dire che ho avuto una buona bottiglia di vino rosso da quella :-)
cercare di evitare select * il più possibile. In altre parole, ottieni solo le colonne di cui hai bisogno. Questo fa poca differenza quando si utilizza MySQL sul PC locale, ma quando si ha un'applicazione in California in cui si esegue una query in un database in Mongolia interna, si desidera ridurre al minimo la quantità di traffico inviata attraverso il filo il più possibile.
Lanciare uno sh * tload di dati su di esso, e profilo.
Questo, e assicurarsi che segue le migliori pratiche per l'indicizzazione, la progettazione dello schema, ecc
non fanno le tabelle ampia, tenerli restringere così come gli indici. Assicurati che le query siano completamente coperte dagli indici e che tali query siano SARGable.
test con una tonnellata di dati prima di andare in produzione, dare un'occhiata a questo: Your testbed has to have the same volume of data as on production in order to simulate normal usage
Inoltre (e lungo le stesse linee) al suggerimento di Robert, si consideri il piano di esecuzione. Sta usando gli indici? Ci sono scansioni o simili? Puoi semplicemente fare una ricerca in qualche modo? Ad esempio, Elimina IN in favore di EXISTS e partecipa solo alle tabelle che è necessario a per partecipare.
Non si parla della tecnologia: tenere presente che diverse tecnologie possono influenzare l'efficienza di query più complesse.
Sollevare il piano di esecuzione e cercare qualsiasi dei seguenti:
Qualsiasi di queste cose (in ordine decrescente dal più al meno scalabile) significa che il database/query probabilmente non sarà in scala per tabelle molto più grandi. Una query ideale avrà per lo più indici di ricerca, hash o unione di join, l'ordinamento occasionale e altre operazioni a basso impatto (spool e così via).
L'unico modo per dimostrare che è scala, come altre risposte hanno evidenziato, è di testarlo su dati della dimensione desiderata. Quanto sopra è solo una regola empirica.
Consiglio vivamente di leggere alcuni materiali di riferimento su questo.Questo (collegamento ipertestuale di seguito) è probabilmente un buon libro da esaminare. Assicurati di guardare sotto "Selettività", tra gli altri argomenti.