Per impostazione predefinita, MySQL InnoDB archivia tutte le tabelle di tutti i DB in un file globale. È possibile modificarlo impostando innodb_file_per_table nella configurazione, che quindi crea un file di dati per ogni tabella.
Mi chiedo perché innodb_file_per_tablenon sia abilitato per impostazione predefinita. Ci sono aspetti negativi nell'usarlo?
Risposte:
Ho la risposta completa per questo.
Una volta che innodb_file_per_table è stato messo in atto, e le nuove tabelle InnoDB possono essere ridotte usando ALTER TABLE <innodb-table-name> ENGINE=InnoDB';Ciò ridurrà i nuovi .ibdfile GARANTITI.
Se corri ALTER TABLE <innodb-table-name> ENGINE=InnoDB';su una tabella InnoDB creata prima di usare innodb_file_per_table, strapperà i dati e gli indici per quella tabella dal file ibdata1 e li memorizzerà in un .ibdfile, questo lascerà un intero piccione permanente nell'ibdata1 che non potrà mai essere riutilizzato .
Il ibdata1file contiene normalmente quattro tipi di informazioni
Pictorial Representation of ibdata1Ecco il modo garantito per ridurre il file ibdata1 praticamente per sempre ...
PASSAGGIO 01) MySQLDump di tutti i database in un file di testo SQL (chiamalo SQLData.sql)
PASSAGGIO 02) Eliminare tutti i database (tranne gli schemi mysql, information_schema e performance_schema)
PASSAGGIO 03) Spegnimento mysql
PASSAGGIO 04) Aggiungi le seguenti righe a /etc/my.cnf
[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
Sidenote: qualunque sia il tuo set per innodb_buffer_pool_size, assicurati che innodb_log_file_size sia il 25% di innodb_buffer_pool_size.
A questo punto, dovrebbe esserci solo lo schema mysql in / var / lib / mysql
Ciò ricrea ibdata1 a 10 MB (non configurare l'opzione), ib_logfile0 e ib_logfile1 a 1G ciascuno
ibdata1 crescerà ma conterrà solo metadati di tabella e dati MVCC intermittenti.
Ogni tabella InnoDB esiste al di fuori di ibdata1
Supponiamo di avere una tabella InnoDB denominata mydb.mytable. Se vai in /var/lib/mysql/mydb, vedrai due file che rappresentano la tabella
mytable.frm (Intestazione del motore di archiviazione)mytable.ibd(Home dei dati delle tabelle e degli indici delle tabelle per mydb.mytable)ibdata1 non conterrà più dati e indici InnoDB.
Con l' opzione innodb_file_per_table in /etc/my.cnf, puoi eseguire OPTIMIZE TABLE mydb.mytableOR ALTER TABLE mydb.mytable ENGINE=InnoDB;e il file /var/lib/mysql/mydb/mytable.ibdsi ridurrà effettivamente.
L'ho fatto numerose volte nella mia carriera come DBA MySQL senza un singolo problema da allora in poi. In effetti, la prima volta che l'ho fatto, ho compresso un file ibdata1 da 50 GB in 50 MB.
Provaci. Se hai ulteriori domande al riguardo, inviami un'e-mail. Fidati di me. Questo funzionerà a breve termine e nel lungo periodo.
C'è un avvertimento che ho a questo proposito che ho aggiornato in altri miei post, ma ho perso questo: sto aggiornando un po 'di più la mia risposta con innodb_fast_shutdown perché ho usato per riavviare mysql e fermare mysql per farlo. Ora, questo passaggio è fondamentale poiché ogni transazione non impegnata può avere altre parti mobili all'interno e all'esterno dei registri delle transazioni di InnoDB ( vedi InnoDB Infrastruttura ).
Si noti che l'impostazione innodb_fast_shutdown su 2 pulirà anche i logout ma esistono ancora più parti mobili e vengono raccolte su Crash Recovery durante l'avvio di mysqld. L'impostazione di 0 è la migliore.
innodb_fast_shutdown=0deve essere impostata in MySQL, prima di chiuderla per eliminare i file di registro! ( ib_logfile0e ib_logfile1) Altrimenti, potresti perdere dati!
Vedi bug .
Ci sono aspetti negativi nell'usarlo?
Uso sempre innodb_file_per_table su database di grandi dimensioni.
ibdata1l'alternativa al file per tabella. Almeno è possibile ridurre un .ibd usando optimize table, il che è banale rispetto alla riduzione di ibdata1.
innodb_file_per_table è abilitato di default in MariaDB.
Il motivo per cui ho deciso di non utilizzare innodb_file_per_table, è perché ogni tabella viene inserita nel proprio file, il che significa che ogni tabella ottiene il proprio overhead separato (firme dei file, ecc.) Che causa la dimensione totale e totale della MySQLdirectory più grande di se si utilizza un tablespace condiviso. Inoltre, c'è più spazio sprecato a causa del cluster-slack quando si hanno più file piccoli invece di uno singolo, grande.
Certo, l'overhead aggiuntivo non è una grande quantità nel grande schema delle cose, specialmente se stai utilizzando un disco di grandi dimensioni o hai un database gigante, ma per me stesso (e probabilmente molti "utenti domestici"), tutto sommato e era ancora troppo per il piccolo disco con cluster di grandi dimensioni in cui tenevo il mio negozio MySQL.
Ad esempio, il mio archivio di database con i miei database WordPress e pochi altri piccoli database (phpBB, dev, alcuni test AMP, ecc), la conversione in per-tavolo cambiato da 32MB a 50MB, e che non è nemmeno compreso il ibdata1che ancora richiede un minimo di 10 MB , per un totale di almeno 60 MB.
Come ho detto, questo potrebbe non essere un grosso problema per alcune persone, in particolare le imprese, ma se sei un utente domestico che ospita solo il tuo sito, blog, ecc., Può davvero essere un fattore in cose come la scelta un fornitore di host perché molti host limitano le dimensioni del database oltre all'utilizzo totale del disco.
IBDATA1). È passato da 30 MB a ~ 85 MB. Eliminando il tutto e importando un dump da zero, ho finito con un 69MB invece dei precedenti 30MB (una supposizione quale database ne occupasse più della metà ☺). Per qualche ragione, nonostante l'utilizzo per tabella, il mio ibdata1è ancora 18 MB. ☹
con innodb_file_per_table = 1, la tabella di rilascio può rallentare vedi qui