Abbiamo un'applicazione in cui solo una tabella diventerà milioni di linee, mentre il resto sarà appena inferiore a un milione. Qual è il consiglio che dovremmo seguire con innodb_file_per_table o lasciarlo come un solo file .ibd? Ho letto alcuni articoli che dicono di non andare con esso in quanto è necessario più accesso al disco quando ci sono join da eseguire? Dovremo unirci tra questa tabella e altre per generare report.
Risposte:
Devi andare con innodb_file_per_table e devi fare un po 'di pulizia con l'infrastruttura attuale di InnoDB.
Ho visto molti client di hosting DB installare MySQL e lasciare InnoDB nel suo stato predefinito. Questo fa crescere selvaggiamente il tablespace di sistema (meglio noto come ibdata1).
Anche se si passasse a innodb_file_per_table, il file .ibd dovrebbe essere estratto da ibdata1 e ibdata non si ridurrà mai. Ad esempio, se hai una tabella chiamata mydb.mytable che è all'interno di ibdata1 che occupa 2 GB, per estrarla devi quanto segue:
PASSAGGIO 01) Aggiungi questo a /etc/my.cnf
[mysqld]
innodb_file_per_tablePASSO 02) service mysql restart
PASSAGGIO 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;
Ciò renderà il file /var/lib/mysql/mydb/mytable.ibd
Sfortunatamente, i 2 GB di spazio occupati dal tavolo prima della modifica non possono essere recuperati. Ho scritto post precedenti su come e perché pulire l'infrastruttura di InnoDB:
Dopo aver apportato questa modifica importante, non dimenticare di aumentare innodb_open_files (impostazione predefinita 300) . Altrimenti, l'accesso al disco è molto limitato.
Per quanto riguarda i join, assicurarsi di disporre di indici adeguati che supportino i criteri di join.
L'uso di innodb_file_per_table in una nuova installazione fa sì che ibdata1 cresca molto lentamente perché tutto il DDL viene eseguito all'esterno di ibdata. Puoi ridurre qualsiasi tabella InnoDB come ho già detto prima in questo modo:
ALTER TABLE mydb.mytable ENGINE=InnoDB;Quando si tratta di backup, fare molta attenzione a fare copie dei file .ibd. Perché?
All'interno di ogni file .ibd è presente un valore speciale noto come tablespace_id. C'è un elenco di valori tablespace_id in ibdata1. Se si esegue mai la manutenzione della tabella che richiede l'eliminazione e la ricreazione della tabella, tablespace_id diventerà diverso. La creazione di una copia di tale file .ibd può essere reinserita nel database per essere utilizzata solo se si esegue anche una copia di ibdata1. Ciò mette in pericolo il tablespace_id di tutte le altre tabelle InnoDB. Alla luce di ciò, è preferibile eseguire backup mysqldump perché mysqldump sono copie logiche dei dati. In altre parole, il backup è indipendente dal punto temporale di ibdata1 e si è liberi di ricaricare senza problemi di operabilità.
Concordo con @RolandoMySQLDBA, per qualcosa che non menziona: i backup.
Se hai il tuo regime di backup MySQL tutto risolto e NON stai includendo il suo file .ibd nella tua strategia di backup del file system, questo non è così importante. Ma considera che l'aggiunta di ONE BYTES a qualsiasi tabella innodb provocherà un backup incrementale della tua tabella .ibd in altro modo, e puoi vedere che sarai rapidamente a corto di memoria di backup.
Ho un'applicazione in cui ho esattamente questa situazione: alcuni tavoli grandi e alcuni più piccoli.
Ho deciso di lasciare i più piccoli ibdata1mentre mettevo quelli più grandi nei loro file.
Lo faccio innodb_file_per_tableaccendendo di default e spegnendolo temporaneamente solo per spostare una tabella ibdata1con ALTER TABLE.
ALTER TABLEloro. Quindi la mia strategia è quella di innodb_file_per_tableaccenderlo regolarmente e spegnerlo casualmente per spostare un tavolino ibdata1e poi riaccenderlo.