Como você já declarou
-innodb_file_per_table decidirá se uma tabela será armazenada em um arquivo ou (se particionada) em vários arquivos. Aqui estão alguns prós e contras de cada abordagem (não é necessário uma lista completa).
Single file per table Multiple files per (partitioned) table
-------------------------------------- --------------------------------------
+ System uses less filehandles - System uses more filehandles
+ One one fsync per second per table - Possibly many more fsync calls (bottleneck)
(less fs overhead (journal etc)) (more fs overhead)
+ Single file uses less space overall - Much larger disk space usage
- Single file fragments badly + Less fragmentation
- Optimize table (et al) takes longer + You can choose to optimize just one file
- One file = one filesystem + You can put heavy traffic files on a fast fs
(e.g. on a solid state disk)
- Impossible to reclaim disk space + possible to emergency-reclaim disk space
in a hurry (truncate table takes long) fast (just delete a file)
- ALTER TABLE can use large % of disk- + rebuilding with ALTER TABLE will use less
space for temp tables while rebuilding temp disk space
Em geral, eu não recomendar vários arquivos.
Se, no entanto, sua carga de trabalho levar a uma fragmentação pesada e
optimize table demora muito, usar vários arquivos fará sentido. Esqueça a recuperação de espaço
Algumas pessoas fazem muito barulho sobre o fato de que no InnoDB os arquivos de tabela sempre crescem e nunca encolhem, levando ao desperdício de espaço se as linhas forem excluídas.
Então eles inventam esquemas para recuperar esse espaço para para não ficar sem espaço livre em disco. (
truncate table x ).Isso funcionará muito mais rápido com vários arquivos, mas tudo isso não faz sentido, porque os bancos de dados quase sempre crescem e (quase) nunca diminuem, então toda essa recuperação de espaço desperdiçará muito tempo (CPU e IO) durante com sua tabela será totalmente bloqueado (sem leituras e sem gravações permitidas).
Só para descobrir que seu disco 90% cheio (50% após a recuperação) estará 99% cheio após as adições de dados nos próximos meses.
No entanto, ao usar ALTER TABLE, cuidado...
Considere o seguinte cenário:
- O disco está 60% cheio.
- o banco de dados ocupa 50%, outros arquivos ocupam 10%.
Se você fizer um
alter table em qualquer tabela, você ficará sem espaço em disco se tiver todas as tabelas em um arquivo.Se você tiver em vários arquivos, não deverá ter problemas (além da overdose de cafeína de toda essa espera).
