Ho una tabella MySQL InnoDB con 1.000.000 di record. È troppo? O i database possono gestire questo e altro? Lo chiedo perché ho notato che alcune query (ad esempio, ottenere l'ultima riga da una tabella) sono più lente (secondi) nella tabella con 1 milione di righe rispetto a una con 100.
Risposte:
Ho una tabella MySQL InnoDB con 1000000 registri. È troppo?
No, 1.000.000 di righe (record AKA) non sono troppe per un database.
Chiedo perché ho notato che alcune query (ad esempio, ottenere l'ultimo registro di una tabella) sono più lente (secondi) nella tabella con 1 milione di registri rispetto a una con 100.
C'è molto da spiegare in quella dichiarazione. I soliti sospetti sono:
Ho un database con più di 97.000.000 di record ( file di dati da 30 GB ) e non ho problemi.
Ricorda solo di definire e migliorare l' indice della tua tabella .
Quindi è ovvio che 1.000.000 non è MOLTO! (Ma se non indicizzi; sì, è MOLTO)
Usa "spiega" per esaminare la tua query e vedere se c'è qualcosa di sbagliato nel piano di query.
EXPLAIN, principianti o meno.
EXPLAIN ;)
Penso che questo sia un malinteso comune: la dimensione è solo una parte dell'equazione quando si tratta di scalabilità del database. Ci sono altri problemi che sono difficili (o più difficili):
Quanto è grande il working set (ovvero quanti dati devono essere caricati in memoria e su cui lavorare attivamente). Se inserisci i dati e poi non fai nulla, è in realtà un problema facile da risolvere.
Quale livello di concorrenza è richiesto? C'è solo un utente che inserisce / legge o abbiamo molte migliaia di client che operano contemporaneamente?
Quali livelli di promessa / durata e coerenza delle prestazioni sono richiesti? Dobbiamo assicurarci di poter onorare ogni impegno. Va bene se la transazione media è veloce o vogliamo assicurarci che tutte le transazioni siano affidabili (controllo di qualità six sigma come - http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization- e-sei-sigma / ).
Hai bisogno di fare problemi operativi, come ALTER lo schema della tabella? In InnoDB questo è possibile, ma incredibilmente lento poiché spesso deve creare una tabella temporanea in primo piano (bloccando tutte le connessioni).
Quindi affermerò che i due problemi limitanti saranno:
Se intendi 1 milione di righe, dipende da come viene eseguita l'indicizzazione e dalla configurazione del tuo hardware. Un milione di righe non è una grande quantità per un database aziendale o anche per un database di sviluppo su apparecchiature decenti.
se intendi 1 milione di colonne (non sono nemmeno sicuro che sia possibile in MySQL) allora sì, questo sembra un po 'grande e probabilmente causerà problemi.
Registrati? Intendi record?
Un milione di record non è un grosso problema per un database di questi tempi. Se riscontri problemi, probabilmente non è il sistema di database stesso, ma piuttosto l'hardware su cui lo stai eseguendo. Molto probabilmente non avrai problemi con il DB prima di esaurire l'hardware per lanciarlo.
Ora, ovviamente alcune query sono più lente di altre, ma se due query molto simili vengono eseguite in tempi molto diversi, è necessario capire qual è il piano di esecuzione del database e ottimizzarlo, ovvero utilizzare indici corretti, normalizzazione adeguata, ecc.
Per inciso, non esiste un "ultimo" record in una tabella, dal punto di vista logico non hanno un ordine intrinseco.
SELECT LAST_INSERT_ID()invece di quella query.
Ho visto tabelle non partizionate con diversi miliardi di record (indicizzati), che si uniscono autonomamente per il lavoro analitico. Alla fine abbiamo suddiviso la cosa, ma onestamente non abbiamo visto molta differenza.
Detto questo, era in Oracle e non ho testato quel volume di dati in MySQL. Gli indici sono tuoi amici :)
Supponendo che tu intenda "record" con "registri" no, non è troppo, MySQL scala molto bene e può contenere tutti i record che hai spazio sul tuo disco rigido.
Ovviamente però le query di ricerca saranno più lente. Non c'è davvero alcun modo per aggirare questo tranne assicurarsi che i campi siano indicizzati correttamente.
Più grande diventa la tabella (come in più righe in essa), le query più lente verranno in genere eseguite se non ci sono indici. Una volta aggiunti gli indici corretti, le prestazioni delle query dovrebbero migliorare o almeno non peggiorare tanto quanto la tabella cresce. Tuttavia, se la query stessa restituisce più righe man mano che la tabella diventa più grande, inizierai a vedere di nuovo il degrado.
Sebbene 1 milione di righe non siano così tante, dipende anche dalla quantità di memoria disponibile sul server DB. Se la tabella è troppo grande per essere memorizzata nella cache dal server, le query saranno più lente.
L'utilizzo della query fornita sarà eccezionalmente lento a causa dell'utilizzo di un metodo di unione di ordinamento per ordinare i dati.
Consiglierei di ripensare il design in modo da utilizzare gli indici per recuperarlo o assicurarti che sia già ordinato in quel modo, quindi non è necessario alcun ordinamento.