Erro 2013 MySQL: Lost connection, como resolver

Entenda o erro 2013 do MySQL, veja a diferença para os erros 2006 e 2003 e confira as causas: consulta longa, pacote grande e tempo de conexão.

Por Redação Eleven Host · @robson.direitodigital · 31 de outubro de 2026 · 8 min de leitura

O erro 2013 MySQL, Lost connection to MySQL server during query, diz que a conexão com o servidor caiu no meio de uma consulta ou durante a conexão. A documentação lista três causas prováveis: problema de rede, muitos dados enviados de uma vez e tempo curto para conectar.

Este guia mostra como ler a mensagem, a diferença para os erros 2006 e 2003, e as causas em ordem: consulta longa ou grande, pacote maior que o aceito e a hora de conectar. Depois explica como ver e mudar as variáveis, onde olhar o log de erro e o que fazer quando o mysqldump cai com o 2013. Os fatos vêm do manual do MySQL 8.4; os nomes dos exemplos são fictícios.

O que a mensagem diz

Na referência de erros de cliente do MySQL 8.4, o erro 2013 tem o símbolo CR_SERVER_LOST e esta mensagem:

Lost connection to MySQL server during query

A página "Lost connection to MySQL server" do manual acrescenta que você pode ver "reading authorization packet" como parte da mensagem. Quando isso acontece, a documentação indica que a causa provável está na etapa de conexão.

Nos erros de cliente, o SQLSTATE é HY000. Perto do 2013 existe o 2055, CR_SERVER_LOST_EXTENDED, com a mensagem Lost connection to MySQL server at '%s', system error: %d.

Erro 2013 x erro 2006 x erro 2003

Os três são erros de conexão, mas acontecem em momentos diferentes. A página do manual sobre o "gone away" separa os dois primeiros:

• 2006 (CR_SERVER_GONE_ERROR): o cliente não conseguiu enviar a pergunta ao servidor.
• 2013 (CR_SERVER_LOST): o cliente não recebeu erro ao escrever no servidor, mas não recebeu a resposta completa, ou nenhuma resposta.

Em resumo, no 2006 o comando nem saiu; no 2013 ele saiu, mas a resposta não voltou inteira. O guia Erro 2006 MySQL: server has gone away, como resolver trata o primeiro caso. Se a mensagem for a do erro 2003, veja Erro 2003 MySQL: Can't connect to server, como investigar.

Causa 1: consulta longa ou com muitos dados

A documentação diz que, às vezes, o "during query" aparece quando milhões de linhas são enviadas numa consulta. O ajuste sugerido é aumentar o net_read_timeout do padrão de 30 segundos para 60 segundos ou mais, o suficiente para a transferência terminar.

Duas variáveis parecidas ajudam a entender o que cada uma controla, com os padrões do manual 8.4:

• net_read_timeout (30 segundos): quanto tempo esperar por mais dados de uma conexão antes de abortar a leitura.
• net_write_timeout (60 segundos): quanto tempo esperar para um bloco ser escrito na conexão antes de abortar a escrita.

Outra causa que a página "gone away" menciona é o comando INSERT ou REPLACE com muitas linhas: ele vira um pedido só, e reduzir o número de linhas por comando evita o erro. A mesma página diz que, se o servidor caiu e reiniciou, você deve procurar a causa da queda, e lembra que o tempo no ar pode ser visto com mysqladmin version.

Causa 2: pacote maior que o permitido

Valores BLOB maiores que o max_allowed_packet também levam à desconexão. Segundo o manual, se aparecer o erro ER_NET_PACKET_TOO_LARGE, isso confirma que você precisa aumentar o max_allowed_packet.

No servidor MySQL 8.4, o padrão é 67108864 bytes, ou 64MB. O cliente mysql tem padrão de 16MB.

Quer conhecer o banco de dados na nuvem 11SQL? 11SQL Mini a partir de R$ 9,90/mês; confira na loja o que cada plano inclui. Conhecer o 11SQL

Causa 3: na hora de conectar

A terceira causa é rara, segundo a documentação. Se o connect_timeout está configurado em poucos segundos, a sugestão é aumentá-lo para dez segundos, ou mais, em conexões longas ou lentas. O padrão do manual 8.4 é 10 segundos, e o mínimo aceito é 2. A variável define quanto tempo o mysqld espera um pacote de conexão antes de responder com Bad handshake.

Para confirmar que a falha foi mesmo na conexão inicial, o manual manda olhar o contador de conexões abortadas, que sobe uma unidade a cada conexão inicial abortada:

SHOW GLOBAL STATUS LIKE 'Aborted_connects';

Se a sua mensagem inclui "reading authorization packet", a documentação diz que essa também é uma pista de que o ajuste do connect_timeout é o que você precisa.

Ver e mudar as variáveis

Para ver os valores atuais no servidor, use SHOW VARIABLES. Estes são exemplos montados com a sintaxe documentada:

SHOW GLOBAL VARIABLES LIKE 'net_read_timeout';

SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';

SHOW GLOBAL VARIABLES LIKE '%timeout%';

Para mudar, o manual mostra que SET GLOBAL vale para novas sessões até você trocar o valor de novo ou o servidor reiniciar. A mudança, portanto, é temporária. Um exemplo montado com valores sugeridos na documentação, só como ponto de partida:

SET GLOBAL net_read_timeout = 60;

SET GLOBAL connect_timeout = 10;

SET GLOBAL max_allowed_packet = 134217728;

Esse último valor equivale a 128MB. As três variáveis podem ser mudadas sem reiniciar o servidor, segundo a tabela do manual. O SET PERSIST, que o manual também descreve, grava a mudança no arquivo mysqld-auto.cnf, no diretório de dados, e ela sobrevive ao reinício.

Para deixar o valor fixo pelo arquivo de configuração, o exemplo do manual usa a seção [mysqld]:

[mysqld]

max_allowed_packet=128M

O manual também mostra as formas de linha de comando: mysql --max_allowed_packet=32M para o cliente e mysqld --max_allowed_packet=128M para o servidor. O caminho do arquivo de configuração depende de como o MySQL foi instalado; veja o guia Instalar MySQL no Ubuntu: passo a passo na VPS para o contexto da instalação.

Olhar o log de erro

Se a queda partiu do servidor, o log de erro mostra o que aconteceu. No Unix, sem a opção --log-error, o destino é o console. Com a opção sem nome, o arquivo é host_name.err no diretório de dados, e com um nome, o arquivo é aquele. O servidor guarda o destino na variável log_error:

SHOW GLOBAL VARIABLES LIKE 'log_error';

O manual lembra que é comum que instalações por pacotes Yum ou APT apontem o log para a pasta /var/log, com uma opção como log-error=/var/log/mysqld.log. Para ver mais detalhes sobre conexões desfeitas, a página "gone away" manda iniciar o mysqld com log_error_verbosity igual a 3. O padrão dela é 2, com valores de 1 a 3.

Quando o mysqldump cai com o erro 2013

Se o mysqldump perde a conexão no meio da cópia, vale conhecer duas opções do manual do mysqldump:

• --quick: faz o mysqldump buscar as linhas de uma tabela uma por vez, em vez de carregar tudo na memória. Ela já vem ligada, porque a opção --opt, ativada por padrão, inclui o --quick.
• --max-allowed-packet: o padrão é 24MB e o máximo é 1GB. Ela não passa do max_allowed_packet do servidor.

Um exemplo montado com essas opções, com nomes fictícios:

mysqldump --quick --max-allowed-packet=512M -u meu-app -p meu_banco > meu_banco.sql

Se o servidor continuar recusando, volte à causa 2 e confira o limite do servidor.

Quer conhecer a VPS da Eleven Host? VPS a partir de R$ 17,00/mês no Plano Bronze; confira na loja o que cada plano inclui. Ver a VPS

Perguntas frequentes

O que significa o erro 2013 do MySQL?

Significa que o cliente não recebeu a resposta completa do servidor, ou nenhuma resposta, depois de enviar o comando. O símbolo é CR_SERVER_LOST.

Qual a diferença entre o erro 2013 e o 2006?

No 2006, o cliente não conseguiu enviar a pergunta ao servidor. No 2013, ele enviou, mas a resposta não chegou inteira.

Como aumentar o net_read_timeout?

A documentação sugere sair do padrão de 30 segundos para 60 segundos ou mais. Com SET GLOBAL net_read_timeout = 60; a mudança vale até o servidor reiniciar.

O que fazer quando aparece "reading authorization packet"?

Segundo a documentação, essa variante sugere que o ajuste do connect_timeout é o que você precisa. O padrão é 10 segundos e a sugestão é subir para dez ou mais em conexões lentas.