Reconstruir uma tabela InnoDB

Reconstruir uma tabela significa criar de novo a estrutura física dela, lendo as linhas e montando outra vez os índices definidos. A reconstrução pode resolver problemas em índices e reorganizar uma tabela fragmentada, mas depende de uma condição: os dados precisam poder ser lidos. Ela não é um reparo universal, e o comando de reparo do MySQL nem funciona nesse engine.

O REPAIR TABLE não serve ao InnoDB

O REPAIR TABLE funciona com os engines MyISAM, ARCHIVE e CSV. Em uma tabela InnoDB, o comando termina com a nota The storage engine for the table doesn't support repair, que informa a falta de suporte, e não um reparo. As opções QUICK, EXTENDED e USE_FRM também não mudam esse resultado. Por isso, o engine da tabela é conferido antes da escolha do procedimento, sem depender do costume das instalações antigas, em que as tabelas eram MyISAM.

Os comandos

• ALTER TABLE vendas ENGINE=InnoDB;: reconstrói a tabela, mantendo o engine, em qualquer versão;
• OPTIMIZE TABLE vendas;: no InnoDB, reconstrói a tabela e atualiza as estatísticas;
• ANALYZE TABLE vendas;: atualiza apenas as estatísticas usadas pelo otimizador.

No InnoDB, o OPTIMIZE TABLE responde com a nota Table does not support optimize, doing recreate + analyze instead, seguida do status OK. A nota é normal e informa que o comando fez uma reconstrução. O ANALYZE TABLE não refaz as páginas nem corrige um dano, e serve quando estatísticas desatualizadas levam a um plano ruim.

A reconstrução refaz os índices que fazem parte da definição atual da tabela. Um índice apagado antes não reaparece, porque já não está na definição.

Quando a reconstrução não basta

Um índice secundário danificado pode ser refeito a partir das linhas, que ficam no índice da chave primária. Quando o dano atinge as próprias linhas, a leitura falha, e a reconstrução falha junto. Nesse caso, o caminho passa pela cópia preservada, pela exportação do que ainda pode ser lido ou pela restauração.

O espaço em disco

A reconstrução cria uma cópia nova da tabela antes de descartar a antiga e pode precisar de arquivos temporários de ordenação. O espaço livre precisa comportar, pelo menos, os dados e os índices da tabela. O efeito no disco depende de como o InnoDB guarda as tabelas:

• Com um arquivo por tabela: o arquivo novo substitui o antigo, e o espaço que sobrava dentro da tabela volta para o disco.
• No arquivo compartilhado ibdata1: a cópia nova ocupa espaço dentro do próprio ibdata1, e esse arquivo nunca diminui. O espaço liberado fica reservado para o InnoDB, e o ibdata1 só encolhe com a exportação de todos os dados e a criação de uma instalação nova.

O arquivo compartilhado é o padrão das versões anteriores ao MySQL 5.6, como a 5.1. Nessas instalações, a reconstrução de uma tabela grande pode fazer o ibdata1 crescer e não devolve espaço ao disco.

Os bloqueios durante a reconstrução

Nas versões antigas, como a 5.1, a reconstrução copia a tabela e impede as gravações durante toda a operação, permitindo apenas as leituras. A partir do MySQL 5.6, a reconstrução de uma tabela InnoDB permite as gravações na maior parte do tempo, com esperas por bloqueio de metadados no início e no fim, que se alongam quando uma transação aberta usa a tabela. Em qualquer versão, a operação disputa o disco e o processamento com a loja.

Antes e depois

Antes da reconstrução, a tabela é preservada, e as medidas de referência são anotadas: a definição, a contagem exata, o maior identificador e o próximo valor do contador. Depois, as mesmas medidas são repetidas, e as buscas da aplicação são conferidas. Um comando concluído não dispensa essa conferência.