Perché usare innodb_file_per_table?
Perché è più facile gestire i singoli poiché può essere eseguito a livello di file. Ciò significa che anche se il server è inattivo, è comunque possibile copiare i dati copiando i file della tabella mentre l'utilizzo di un tablespace condiviso significa copiare tutto che può essere inutilmente massiccio, sia trovare un modo per far funzionare il server per estrarre i dati ( non vuoi davvero estrarre manualmente i dati con un editor esadecimale).
Qualcuno ha avvertito che non è possibile semplicemente copiare e incollare i .ibdfile da un server all'altro. Questo può essere vero, ma non dovrebbe applicarsi ai backup sullo stesso server (sto usando il termine backup qui nel senso tradizionale del fare una copia; cioè, non cambiando drasticamente il tutto). Inoltre, ibdata1viene ricreato automaticamente all'avvio (come visto nella fase di eliminazioneibdata1 della maggior parte delle guide di "conversione in file per tabella"). Pertanto, non è necessario copiare ibdata1oltre ai .ibdfile (e i .frmfile corrispondenti , ecc.).
Se si tenta di ripristinare una tabella persa, dovrebbe essere sufficiente copiarne .ibde il .frmfile, nonché information_schema(che è molto più piccolo di ibdata1). In questo modo, puoi metterli in un server fittizio ed estrarre il tuo tavolo senza dover copiare l'intera cosa enorme.
Tuttavia, la richiesta di prestazioni migliori è discutibile. ... Con innodb_file_per_table, sono necessarie più operazioni di I / O su disco; e questo è significativo nei complicati JOIN e nei vincoli ESTERI CHIAVE.
Non sorprende, le prestazioni dipenderanno interamente dai database specifici in uso. Una persona avrà (anche molto) risultati diversi da un'altra.
È vero che ci saranno più operazioni di I / O su disco con file per tabella, ma solo leggermente di più. Pensa a come funziona il sistema.
Noterai che quando il server è in esecuzione, non puoi spostare i file di dati perché il server ha degli handle aperti su di essi. Questo perché quando si avvia, li apre e li lascia aperti. Non li apre e li chiude per ogni singola query.
Come tale, ci sono solo alcune altre operazioni di I / O all'inizio, all'avvio del server; non mentre è in esecuzione. Inoltre, sebbene ogni singolo .ibdfile abbia un proprio overhead separato (firme, strutture dei file, ecc.), Essi vengono memorizzati nella cache e non vengono riletti per ogni query. Inoltre, le stesse strutture vengono lette anche con un tablespace condiviso, quindi non c'è quasi più (se non del tutto) più memoria richiesta.
Innodb_file_per_table ha un effetto su una migliore prestazione di mysql?
In realtà, se non altro, le prestazioni potrebbero in effetti essere peggiori .
Quando si utilizza un tablespace condiviso, le operazioni di lettura e scrittura possono talvolta / spesso essere combinate in modo che il server legga un campione di dati da più tabelle in una volta sola ibdata.
Tuttavia, se i dati sono distribuiti su più file, è necessario eseguire un'operazione I / O separata per ognuno di essi.
Ovviamente questo è di nuovo interamente dipendente dal database in questione; l'impatto sulle prestazioni del mondo reale dipenderà dalle dimensioni, dalla frequenza delle query e dalla frammentazione interna del tablespace condiviso. Alcune persone possono notare una grande differenza, mentre altri potrebbero non vedere alcun impatto.
Il tablespace è condiviso su un singolo ibdata; come tablespace dedicati per tabelle separate possono risparmiare spazio su disco?
Non è così. Semmai, aumenta l' utilizzo del disco in parte.
Non ho un database da 60 GB con cui testare, ma il mio database personale "scarso" che contiene la mia installazione di WordPress e alcune piccole tabelle per uso personale e test di sviluppo pesava a ~ 30 MB mentre utilizzava un tablespace condiviso. Dopo averlo convertito in file per tabella, si è gonfiato a ~ 85 MB. Anche facendo cadere tutto e reimportando, era ancora> 60 MB.
Questo aumento è dovuto a due fattori:
La dimensione minima assoluta per ibdata1è - per qualche motivo - 10 MB, anche se non hai altro che information_schemaarchiviato al suo interno.
Con un tablespace condiviso, ibdata1ha solo un sovraccarico come firme di file, metadati, ecc., Ma per tabella, ogni singolo .ibdfile ha tutto questo. Ciò significa che il totale (anche con un ipotetico <10 MB ibdata1) sarebbe un po 'più grande di almeno:
GetTotalSizeofOverhead() * GetNumTables()
Ovviamente questi non aumenteranno enormemente (a meno che tu non stia utilizzando un host che limiti le dimensioni del tuo database o li memorizzi su un'unità flash, ecc.), Ma sono comunque aumenti e passando da ( ogni ) tabella a file -per-tavolo è possibile ridurre ibdata1a 10 MB, il totale complessivo sarà invariabilmente maggiore di quello che era.