MySQL ALTER TABLE su un tavolo molto grande - è sicuro farlo funzionare?

Question

Ho un database MySQL con una tabella MyISAM con 4 milioni di righe. Aggiorno questa tabella circa una volta alla settimana con circa 2000 nuove righe. Dopo l'aggiornamento, ho quindi modificare la tabella in questo modo:

ALTER TABLE x ORDER BY PK DESC 

posso ordinare la tabella per il campo chiave primaria in ordine decrescente. Questo non mi ha dato alcun problema sulla mia macchina di sviluppo (Windows con memoria da 3 GB). Tre volte l'ho provato con successo sul server Linux di produzione (con 512 MB di RAM - e ottenendo la tabella ordinata risultante in circa 6 minuti ogni volta), l'ultima volta che l'ho provato ho dovuto interrompere la query dopo circa 30 minuti e ricostruire il database da un backup.

Un server da 512 MB può far fronte a tale alter statement su un tavolo così grande? Ho letto che una tabella temporanea viene creata per eseguire il comando ALTER TABLE.

Domanda: questo comando di modifica può essere eseguito in sicurezza? Quale dovrebbe essere il tempo previsto per l'alterazione del tavolo?

Answer 1

Probabilmente creerò una vista che è ordinata dal valore PK, quindi per una cosa non è necessario bloccare quella tabella enorme mentre ALTER viene eseguito.

Answer 2

Come ho appena letto, la query ALTER TABLE ... ORDER BY ... è utile per migliorare le prestazioni in determinati scenari. Sono sorpreso che l'indice PK non aiuti con questo. Ma, dal the MySQL docs, sembra che InnoDB compia l'indice. Tuttavia, InnoDB tende ad essere più lento come MyISAM. Detto questo, con InnoDB non avresti bisogno di riordinare il tavolo ma perderai la velocità incredibile di MyISAM. Potrebbe valerne la pena.

Il modo in cui spieghi i problemi, sembra che ci siano troppi dati caricati in memoria (forse c'è anche lo swapping in corso?). Si potrebbe facilmente controllare con il monitoraggio dell'utilizzo della memoria. È difficile dirlo perché non conosco MySQL così bene.

D'altra parte, penso che il tuo problema si trovi in ​​un posto molto diverso: stai usando una macchina con solo 512 Meg di RAM come server di database con una tabella contenente più di 4 file di mio ... E stai eseguendo un operazione molto ricca di memoria sull'intera tabella su quella macchina. Sembra che 512 Meg non saranno quasi sufficienti per questo.

Un problema molto più fondamentale che sto vedendo qui: State facendo sviluppo (e molto probabilmente anche test) in un ambiente che è molto diverso dall'ambiente di produzione. Il tipo di problema che stai spiegando è da aspettarsi. La tua macchina di sviluppo ha una memoria sei volte superiore alla tua macchina di produzione. Credo di poter dire con certezza che anche il processore è molto più veloce. In tal caso, ti suggerisco di creare una macchina virtuale che imiti il ​​tuo sito di produzione. In questo modo puoi facilmente testare il tuo progetto senza interrompere il sito di produzione.

Answer 3

Quello che stai chiedendo è di ricostruire l'intera tabella e tutti i suoi indici; questa è un'operazione costosa in particolare se i dati non si adattano al ram. Si completerà, ma sarà molto più lento se i dati non si adattano alla ram, in particolare se si hanno molti indici.

Mi interrogo sul giudizio quando si sceglie di eseguire una macchina con una memoria così piccola in produzione. Ad ogni modo:

• E 'davvero necessario questo ALTER TABLE; quale query specifica stai cercando di accelerare e hai provato senza?
• Hai mai pensato di rendere la tua macchina di sviluppo più simile alla produzione?Voglio dire, usare una scatola di sviluppo con MAGGIORE memoria non è mai una buona idea, e l'utilizzo di un sistema operativo diverso non è sicuramente neanche uno.

Probabilmente c'è anche qualche tuning che puoi fare per cercare di aiutarti; dipende in gran parte dal tuo schema (in particolare gli indici). Le file 4M non sono molte (per una macchina con quantità normali di ram).

Answer 4

Se si utilizza InnoDB, non è necessario eseguire esplicitamente il ORDER BY post-inserimento o al momento della query. Secondo il manuale di MySQL 5.0, InnoDB già default ordinazione chiave primaria per i risultati delle query:

http://dev.mysql.com/doc/refman/5.0/en/alter-table.html#id4052480

tabelle MyISAM restituire i record in ordine di inserimento di default, invece, che può funzionare anche se sempre e solo accodare a la tabella, anziché utilizzare una query UPDATE per modificare sul posto qualsiasi riga.

Answer 5

è la chiave primaria auto_increment? se è così, allora ALTER TABLE ... ORDER BY non migliorerà nulla dato che tutto verrà comunque inserito in ordine.

(a meno che non siano presenti molte eliminazioni)