MySQL: "The table is full" — causas reais e roteiro de diagnóstico

O erro The table is full costuma gerar pânico porque o nome sugere que os dados acabaram — mas, segundo a própria documentação oficial do MySQL, ele é um sintoma genérico com duas causas possíveis: disco cheio, ou a tabela atingiu seu tamanho máximo efetivo. Tratar as duas causas como se fossem a mesma coisa é o motivo pelo qual esse erro volta a aparecer depois de uma correção incompleta.

O que o erro significa

A documentação oficial (seção "The table is full") é direta: se o erro de tabela cheia ocorre, pode ser que o disco esteja cheio ou que a tabela tenha atingido seu tamanho máximo. E completa: o tamanho máximo efetivo de uma tabela no MySQL geralmente é determinado por restrições do sistema operacional sobre tamanho de arquivo, não por limites internos do MySQL.

Ou seja, antes de qualquer ajuste de configuração, o primeiro passo é sempre distinguir entre "acabou o espaço em disco" e "a tabela/tablespace bateu num teto de tamanho de arquivo".

Causas mais comuns

Disco realmente cheio no filesystem onde estão os arquivos de dados (datadir) — a causa mais frequente na prática, e a mais rápida de descartar.

Tablespace do sistema InnoDB (ibdata1) configurado sem autoextend, ou com autoextend e um limite max definido no innodb_data_file_path — quando o arquivo atinge esse teto, novas escritas que dependem dele falham com esse erro.

Limite de tamanho de arquivo do sistema operacional/filesystem sendo menor que o esperado. A documentação do InnoDB alerta que o próprio InnoDB não tem conhecimento do limite máximo de arquivo do filesystem — o cuidado citado explicitamente é com filesystems cujo limite máximo é um valor baixo, como 2GB.

Tabela temporária interna (usada por GROUP BY, ORDER BY, joins complexos, etc.) excedendo o menor valor entre tmp_table_size e max_heap_table_size — nesse caso o MySQL converte a tabela temporária para disco automaticamente; o erro de tabela cheia nesse cenário normalmente indica que o disco de destino das tabelas temporárias também está sem espaço.

Tabela MyISAM legada com MAX_ROWS/AVG_ROW_LENGTH definidos de forma conservadora, ou com o parâmetro de tamanho de ponteiro de dados abaixo do necessário para o volume atual — cenário cada vez mais raro, mas ainda presente em bancos antigos migrados sem revisão. Valores padrão e nome exato do parâmetro de ponteiro de dados variam por versão — confirme na documentação da versão específica em uso antes de alterar.

Diagnóstico passo a passo

1. Descartar disco cheio primeiro. É a checagem mais barata e a causa mais comum:

df -h

Verifique especificamente o filesystem onde está o datadir do MySQL, e também o diretório usado para tabelas temporárias em disco (ver passo 5).

2. Verificar a configuração do tablespace do sistema InnoDB:

SHOW VARIABLES LIKE 'innodb_data_file_path';

A sintaxe desse parâmetro é nome_arquivo:tamanho[:autoextend[:max:tamanho_maximo]]. Se o último arquivo listado não tiver autoextend, ou tiver autoextend com um max definido, esse é um candidato direto para a causa do erro quando o disco não está cheio.

3. Confirmar se innodb_file_per_table está habilitado. Com essa opção ativa (comportamento padrão desde o MySQL 5.6.6), cada tabela InnoDB tem seu próprio arquivo .ibd, e o tablespace do sistema deixa de crescer com os dados das tabelas de usuário — isso muda onde procurar o teto de tamanho:

SHOW VARIABLES LIKE 'innodb_file_per_table';

4. Se innodb_file_per_table estiver ativo, identificar qual tabela está próxima do limite, olhando tamanho de dados e índice via INFORMATION_SCHEMA:

SELECT table_schema, table_name, engine,
       data_length, index_length, data_free
FROM information_schema.tables
WHERE engine IS NOT NULL
ORDER BY (data_length + index_length) DESC
LIMIT 20;

5. Verificar se o erro é de tabela temporária, não de tabela definitiva:

SHOW VARIABLES LIKE 'tmp_table_size';
SHOW VARIABLES LIKE 'max_heap_table_size';
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';

Um número alto e crescente em Created_tmp_disk_tables indica que consultas estão regularmente estourando o limite em memória e indo para disco — e é nesse disco (geralmente o diretório de tmpdir) que vale checar espaço livre.

6. Checar o filesystem quanto a limites de tamanho de arquivo, especialmente em volumes mais antigos ou montados com opções não padrão. O comando e a saída exata dependem do filesystem em uso — ext4, XFS etc. têm limites e formas de checagem distintas; confirme a documentação do filesystem do seu ambiente.

Solução aplicada

O ajuste correto depende de qual causa foi confirmada no roteiro acima, e não deve ser aplicado às cegas:

Se for disco cheio, a correção é liberar espaço (remoção de arquivos obsoletos, logs binários antigos via PURGE BINARY LOGS, expansão do volume) — nunca apenas reiniciar o serviço.

Se for o tablespace do sistema sem autoextend ou com max atingido, o ajuste é reconfigurar innodb_data_file_path para incluir autoextend (ou aumentar o max) no último arquivo listado, o que exige reinício do servidor. Vale considerar também migrar para innodb_file_per_table, se ainda não estiver habilitado, para não depender de um único tablespace compartilhado.

Se for tabela temporária estourando para disco, avaliar aumento de tmp_table_size/max_heap_table_size — mas isso é uma correção de sintoma; o ideal é revisar a consulta que está gerando a tabela temporária grande (índices ausentes, GROUP BY/ORDER BY em colunas não indexadas, joins mal otimizados).

Se for limite de filesystem, a correção está fora do MySQL: mover os arquivos para um filesystem sem essa restrição, ou reparticionar o volume.

Fechamento

The table is full é um dos erros do MySQL onde o texto da mensagem ajuda menos do que parece — ela não diz se o problema é disco, configuração de tablespace ou tabela temporária, e cada uma dessas causas tem uma correção diferente. Seguir o roteiro (disco, innodb_data_file_path, innodb_file_per_table, tabelas temporárias, filesystem) evita aplicar a correção errada e ver o mesmo erro reaparecer dias depois.

Precisa de suporte para diagnosticar ou revisar a capacidade do seu ambiente MySQL? Fale com a nossa equipe — contato: contato@siltechconsult.com.br — www.siltechconsult.com.br