Por que usar innodb_file_per_table?
Porque é mais fácil gerenciar indivíduos, pois isso pode ser feito no nível do arquivo. Isso significa que, mesmo que o servidor esteja inoperante, você ainda pode copiar os dados copiando os arquivos da tabela, enquanto usar um espaço de tabela compartilhado significa copiar tudo o que pode ser desnecessariamente grande ou encontrar uma maneira de fazer o servidor executar a extração de dados ( você realmente não deseja extrair manualmente os dados com um editor hexadecimal).
Alguém avisou que você não pode simplesmente copiar e colar .ibdarquivos de um servidor para outro. Isso pode ser verdade, mas não deve se aplicar a backups no mesmo servidor (estou usando o termo backup aqui no sentido tradicional de fazer uma cópia; ou seja, não alterando drasticamente a coisa toda). Além disso, ibdata1é recriado automaticamente na inicialização (como visto na etapa de exclusãoibdata1 da maioria dos guias de “conversão em arquivo por tabela”). Como tal, você não precisa copiar ibdata1além dos seus .ibdarquivos (e seus .frmarquivos correspondentes etc.).
Se estiver tentando recuperar uma tabela perdida, deve ser suficiente copiar o arquivo .ibde .frm, além de information_schema(que é muito menor que ibdata1). Dessa forma, você pode colocá-los em um servidor fictício e extrair sua tabela sem ter que copiar toda a coisa enorme.
No entanto, a reivindicação de melhor desempenho é questionável. … Com innodb_file_per_table, são necessárias mais operações de E / S de disco; e isso é significativo em restrições JOINs e FOREIGN KEY complicadas.
Não é de surpreender que o desempenho dependa inteiramente dos bancos de dados específicos em uso. Uma pessoa terá (até muito) resultados diferentes de outra.
É verdade que haverá mais operações de E / S de disco com arquivo por tabela, mas apenas um pouco mais. Pense em como o sistema funciona.
Você notará que, quando o servidor está em execução, não é possível mover os arquivos de dados porque o servidor possui identificadores abertos. Isso ocorre porque, ao iniciar, ele os abre e os deixa abertos. Não os abre e fecha para cada consulta individual.
Como tal, há apenas mais algumas operações de E / S no início, quando o servidor é inicializado; não enquanto estiver em execução. Além disso, embora cada .ibdarquivo individual tenha sua própria sobrecarga separada (assinaturas, estruturas etc.), eles são armazenados em cache na memória e não são lidos novamente para cada consulta. Além disso, as mesmas estruturas são lidas mesmo com um espaço de tabela compartilhado, portanto, quase não há (se é que existe) mais memória necessária.
O innodb_file_per_table afeta o desempenho do mysql?
Na verdade, se houver, o desempenho pode ser de fato pior .
Ao usar um espaço de tabela compartilhado, as operações de leitura e gravação podem às vezes / frequentemente ser combinadas para que o servidor leia uma amostra de dados de várias tabelas de uma só vez ibdata.
No entanto, se os dados estiverem espalhados entre vários arquivos, ele deverá executar uma operação de E / S separada para cada um individualmente.
É claro que isso novamente depende inteiramente do banco de dados em questão; o impacto no desempenho do mundo real dependeria do tamanho, da frequência da consulta e da fragmentação interna do espaço de tabela compartilhado. Algumas pessoas podem notar uma grande diferença, enquanto outras podem não ter nenhum impacto.
O espaço de tabela é compartilhado em um único ibdata; como os espaços de tabela dedicados para tabelas separadas podem economizar espaço em disco?
Isso não. Se alguma coisa, aumenta o uso do disco.
Não tenho um banco de dados de 60 GB para testar, mas meu "insignificante" banco de dados pessoal, que contém minha instalação do WordPress e algumas tabelas pequenas para uso pessoal e testes de desenvolvimento, pesavam ~ 30 MB ao usar um espaço de tabela compartilhado. Depois de convertê-lo em arquivo por tabela, ele aumentou para ~ 85 MB. Mesmo eliminando tudo e reimportando, ele ainda tinha mais de 60 MB.
Esse aumento é devido a dois fatores:
O tamanho mínimo absoluto para ibdata1é - por algum motivo - 10 MB, mesmo que você não tenha nada além de information_schemaarmazenado.
Com um espaço de tabela compartilhado, só ibdata1há sobrecarga, como assinaturas de arquivos, metadados, etc., mas com cada tabela, cada .ibdarquivo individual tem tudo isso. Isso significa que o total (mesmo com um hipotético <10MB ibdata1) seria um pouco maior em pelo menos:
GetTotalSizeofOverhead() * GetNumTables()
Obviamente, esses não serão grandes aumentos (a menos que você esteja usando um host que limite o tamanho do banco de dados ou os armazene em uma unidade flash etc.), mas eles aumentam mesmo assim e ao alternar ( todas ) as tabelas para arquivos Por tabela, você pode reduzir ibdata1para 10 MB, o total geral será invariavelmente mais do que era.