Temos um aplicativo em que apenas uma da tabela crescerá em milhões de linhas, mas o restante ficará abaixo de um milhão. Então, qual é o conselho que devemos seguir com innodb_file_per_table ou deixar apenas um .ibd? Li alguns artigos dizendo que não o acompanhe, pois você precisa de mais acesso ao disco quando houver junções a serem executadas? Teremos associação entre esta tabela e outras para fins de geração de relatórios.
Respostas:
Você deve seguir com innodb_file_per_table e precisa fazer algumas limpezas com a infraestrutura atual do InnoDB.
Eu já vi muitos clientes de hospedagem de banco de dados configurando o MySQL e deixando o InnoDB em seu estado padrão. Isso faz com que o espaço de tabela do sistema (mais conhecido como ibdata1) cresça rapidamente.
Mesmo se você alternar para innodb_file_per_table, o arquivo .ibd precisaria ser extraído do ibdata1 e o ibdata nunca diminuirá. Por exemplo, se você possui uma tabela chamada mydb.mytable que está dentro do ibdata1, ocupando 2 GB, para extraí-la, é necessário o seguinte:
PASSO 01) Adicione isso ao /etc/my.cnf
[mysqld]
innodb_file_per_tablePASSO 02) service mysql restart
PASSO 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;
Isso fará com que o arquivo /var/lib/mysql/mydb/mytable.ibd
Infelizmente, os 2 GB de espaço ocupado pela tabela antes da alteração não podem ser recuperados. Escrevi posts anteriores sobre como e por que limpar a infraestrutura do InnoDB:
Depois de fazer essa grande alteração, não esqueça de aumentar innodb_open_files (padrão 300) . Caso contrário, o acesso ao disco é muito limitado.
Com relação às associações, verifique se você possui índices adequados que suportam os critérios de associação.
O uso de innodb_file_per_table em uma nova instalação faz com que o ibdata1 cresça muito lentamente porque todo o DDL é feito externo ao ibdata. Você pode reduzir qualquer tabela do InnoDB, como mencionei antes, desta forma:
ALTER TABLE mydb.mytable ENGINE=InnoDB;Quando se trata de backups, seja extremamente cuidadoso ao fazer cópias de arquivos .ibd. Por quê?
Dentro de cada arquivo .ibd há um valor especial conhecido como tablespace_id. Há uma lista de valores tablespace_id em ibdata1. Se você executar uma manutenção de tabela que exija descartar e recriar a tabela, o tablespace_id se tornará diferente. Fazer uma cópia desse arquivo .ibd só pode ser intergated novamente no banco de dados para uso se você também fizer uma cópia do ibdata1. Isso coloca em risco o tablespace_id de todas as outras tabelas do InnoDB. À luz disso, é preferível que você execute backups do mysqldump porque o mysqldumps é cópias lógicas dos dados. Em outras palavras, o backup é independente do momento específico do ibdata1 e você pode recarregar sem problemas de operabilidade.
Concorde com o @RolandoMySQLDBA, por algo que ele não menciona: backups.
Se seu regime de backup do MySQL está completo, e você não está incluindo o arquivo .ibd na estratégia de backup do sistema de arquivos, isso não é tão importante. Mas considere que a adição de ONE BYTES a qualquer tabela innodb causará um backup incremental da sua tabela .ibd de outra maneira, e você poderá ver que rapidamente ficará sem armazenamento de backup.
Eu tenho um aplicativo em que tenho exatamente essa situação: algumas tabelas grandes e outras menores.
Decidi deixar os pequenos ibdata1enquanto colocava os maiores em seus próprios arquivos.
Faço-o por ter innodb_file_per_tableativado por padrão e só desligá-lo temporariamente para mover uma tabela para ibdata1com ALTER TABLE.
ALTER TABLE. Portanto, minha estratégia é innodb_file_per_tableativá-lo regularmente e desativá-lo casualmente para mover uma pequena mesa ibdata1e depois ligá-la novamente.