Início / dba / Perguntas / 15906
Accepted
newbie14
Asked: 2012-04-01 19:44:49 +0800 CST

O innodb_file_per_table é aconselhável?

  • 772

Temos um aplicativo em que apenas uma tabela crescerá em milhões de linhas, mas o restante ficará um pouco abaixo de um milhão. Então, qual é o conselho que devemos usar innodb_file_per_table ou deixar apenas um .ibd? Eu li alguns artigos dizendo para não ir com isso, pois você precisa de mais acesso ao disco quando houver junções a serem executadas? Teremos junção entre esta tabela e outras para fins de geração de relatórios.

mysql innodb

3 respostas

  1. Best Answer

    Você deve ir com innodb_file_per_table e precisa fazer alguma limpeza com a infraestrutura atual do InnoDB.

    Já vi muitos clientes de hospedagem de banco de dados configurarem o MySQL e deixarem o InnoDB em seu estado padrão. Isso faz com que o tablespace do sistema (mais conhecido como ibdata1) cresça descontroladamente.

    Mesmo se você alternasse para innodb_file_per_table, o arquivo .ibd teria que ser extraído de ibdata1 e ibdata nunca diminuiria. Por exemplo, se você tem uma tabela chamada mydb.mytable que está dentro de ibdata1 ocupando 2GB, para extraí-la você tem que fazer o seguinte:

    PASSO 01) Adicione isto em /etc/my.cnf

    [mysqld]
innodb_file_per_table

    PASSO 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 ocupados pela mesa antes da alteração não podem ser recuperados. Escrevi postagens anteriores sobre como e por que limpar a infraestrutura do InnoDB:

    Depois de fazer essa alteração importante, não se esqueça de aumentar innodb_open_files (padrão 300) . Caso contrário, o acesso ao disco é muito limitado.

    Com relação às junções, certifique-se de ter índices adequados que suportem os critérios de junção.

    ATUALIZAÇÃO 2012-04-02 11:30 EDT

    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 externamente ao ibdata. Você pode encolher qualquer tabela InnoDB como mencionei antes assim:

    ALTER TABLE mydb.mytable ENGINE=InnoDB;

    ATUALIZAÇÃO 2012-04-02 16:50 EDT

    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 eliminar e recriar a tabela, o tablespace_id se tornará diferente. Fazer uma cópia desse arquivo .ibd só pode ser integrado ao banco de dados para uso se você também fizer uma cópia de ibdata1. Isso coloca em risco o tablespace_id de todas as outras tabelas InnoDB. Diante disso, é preferível que você execute backups mysqldump porque mysqldumps são cópias lógicas dos dados. Em outras palavras, o backup é independente do ponto no tempo do ibdata1 e você pode recarregar sem problemas de operacionalidade.

    • 25

  2. Concordo com @RolandoMySQLDBA, em algo que ele não menciona: backups.

    Se você tem seu regime de backup do MySQL todo planejado, E você não está incluindo seu arquivo .ibd em sua estratégia de backup do sistema de arquivos, então isso não é tão importante. Mas considere que adicionar UM BYTES a qualquer tabela innodb causará um backup incremental de sua tabela .ibd caso contrário, e você verá que rapidamente ficará sem armazenamento de backup.

    • 7

  3. Tenho uma aplicação onde tenho exatamente esta situação: algumas tabelas grandes e outras menores.

    Resolvi deixar os pequenos por ibdata1enquanto colocando os maiores em seus próprios arquivos.

    Eu faço isso innodb_file_per_tableligando por padrão e apenas desligo temporariamente para mover uma mesa para ibdata1com ALTER TABLE.

    • 4

relate perguntas