Erro 1205 MySQL: Lock wait timeout, como investigar

Entenda o erro 1205 do MySQL, ache a transação que segura a trava, veja o que o timeout controla e como evitar o erro nas suas aplicações.

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

O erro 1205 MySQL, Lock wait timeout exceeded, diz que uma transação esperou além do limite por uma linha travada por outra transação, e o MySQL desistiu da espera. Para investigar, ache a transação que segura a trava.

Este guia mostra como ler a mensagem, a diferença para o deadlock (erro 1213), o que o MySQL desfaz quando o tempo acaba, como achar quem está travando, o que a variável innodb_lock_wait_timeout controla e como evitar o erro. Os fatos vêm do manual do MySQL 8.4; em outra versão, ou em outro servidor compatível, confira a documentação da sua. Os exemplos usam a tabela fictícia pedidos.

O que a mensagem diz

Na referência de erros do MySQL, o erro 1205 tem o símbolo ER_LOCK_WAIT_TIMEOUT, o SQLSTATE HY000 e esta mensagem:

Lock wait timeout exceeded; try restarting transaction

No cliente de linha de comando, ela aparece com o número do erro e o SQLSTATE na frente:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Lendo por partes:

• HY000: o SQLSTATE informado pela referência.
• Lock wait timeout exceeded: o tempo de espera por uma trava (lock) passou do limite.
• try restarting transaction: a sugestão do servidor de tentar a transação de novo.

O texto da referência diz que o InnoDB informa esse erro quando o tempo de espera por trava expira, e que a instrução que esperou demais foi desfeita, e não a transação inteira. Em palavras simples: uma transação precisou de uma linha que outra transação estava segurando, esperou e o MySQL desistiu.

Lock wait timeout x deadlock (erro 1213)

O 1205 se parece com o erro 1213, mas são situações diferentes. O 1213 tem o símbolo ER_LOCK_DEADLOCK, o SQLSTATE 40001 e a mensagem Deadlock found when trying to get lock; try restarting transaction.

• Deadlock (1213): duas transações esperam uma pela outra. O InnoDB detecta isso na hora e desfaz uma delas inteira, segundo a página de tratamento de erros do InnoDB.
• Lock wait timeout (1205): é uma espera comum que passou do tempo. Desfaz só a instrução atual.

O tempo limite não se aplica ao deadlock quando a variável innodb_deadlock_detect está ligada, que é o padrão, porque o InnoDB detecta o deadlock na hora. No 1205, a pergunta é qual transação está segurando a linha.

O que é desfeito quando o tempo acaba

Por padrão, o InnoDB desfaz só a última instrução quando o tempo expira. A variável innodb_rollback_on_timeout muda isso: com ela ligada, o estouro do tempo faz o InnoDB abortar e desfazer a transação inteira. Os dados da variável, segundo a página de parâmetros do InnoDB:

• Padrão: OFF.
• Escopo: global.
• Dinâmica: não. Ela só muda na inicialização do servidor, então um SET GLOBAL não serve para ela.

Isso tem uma consequência para a aplicação. A página de tratamento de erros manda repetir a instrução, se o comportamento for o padrão, ou a transação inteira, se a variável estiver ligada. Também avisa que as travas não são liberadas quando só uma instrução é desfeita. No padrão, a transação continua aberta, segurando as travas que já tinha, e a aplicação precisa decidir entre repetir, dar COMMIT ou dar ROLLBACK.

Como achar quem está travando

O caminho mais simples é a view sys.innodb_lock_waits, do schema sys, que o manual usa nos exemplos de informação do InnoDB:

SELECT waiting_pid, waiting_query, blocking_pid, blocking_query

FROM sys.innodb_lock_waits;

Colunas úteis dessa view:

• wait_age: há quanto tempo a espera dura.
• locked_table_schema e locked_table_name: o banco e a tabela travados.
• blocking_pid: o ID, na lista de processos, da transação que trava.
• sql_kill_blocking_query e sql_kill_blocking_connection: já trazem o comando KILL escrito para você.

Quando a sessão que trava ficou parada, a coluna blocking_query vem vazia (NULL). É o caso da transação aberta e esquecida. O manual manda, então, achar o THREAD_ID em performance_schema.threads e ver a última instrução da sessão em performance_schema.events_statements_current, ou as dez últimas em events_statements_history.

Outro caminho é a tabela information_schema.INNODB_TRX, que lista cada transação. Ela mostra o estado (trx_state, com valores como RUNNING e LOCK WAIT), o início (trx_started), o ID do processo (trx_mysql_thread_id), a consulta (trx_query) e as linhas travadas (trx_rows_locked). Exige o privilégio PROCESS:

SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query

FROM information_schema.INNODB_TRX

ORDER BY trx_started;

SHOW PROCESSLIST;

O SHOW PROCESSLIST mostra a coluna Id, que é o número usado no KILL. O comando SHOW ENGINE INNODB STATUS\G mostra a causa do deadlock mais recente, e serve quando o problema for o 1213. Para conceder privilégios a um usuário, o guia Criar usuário MySQL: como dar permissões com GRANT mostra o uso do GRANT.

Encerrar a sessão que trava

Se a sessão que trava é uma transação esquecida, a saída é encerrar a sessão ou pedir a quem a abriu que dê COMMIT ou ROLLBACK. A sintaxe é KILL [CONNECTION | QUERY] id:

KILL QUERY 42;

KILL 42;

• KILL QUERY: para só a instrução em execução e mantém a conexão.
• KILL ou KILL CONNECTION: derruba a conexão.

O 42 é um exemplo; use o ID que você achou. Antes de dar o KILL, confirme de quem é a sessão: a conexão derrubada pode ser de outra pessoa. Sem o privilégio CONNECTION_ADMIN (ou SUPER), você só encerra os seus próprios processos, e sem o PROCESS você só vê as próprias conexões. O encerramento pode levar um tempo: a documentação explica que a marca de encerramento só é checada em certos intervalos, e durante um rollback o SHOW PROCESSLIST mostra Rolling back na coluna State. A página do KILL não detalha o que acontece com as alterações da sessão, então confirme o resultado depois.

A variável innodb_lock_wait_timeout

É ela que define quanto tempo uma transação espera por uma trava de linha antes do erro 1205. Segundo a página de parâmetros do InnoDB:

• Padrão: 50 segundos. O mínimo é 1 e o máximo é 1073741824.
• Escopo: global e de sessão.
• Dinâmica: sim, muda sem reiniciar o servidor.
• Alcance: vale para travas de linha do InnoDB, e a documentação diz que o tempo não se aplica à espera por travas de tabela.

Para ver o valor e mudá-lo:

SELECT @@innodb_lock_wait_timeout;

SET SESSION innodb_lock_wait_timeout = 120;

SET GLOBAL innodb_lock_wait_timeout = 30;

O SET SESSION afeta só a conexão atual, e cada cliente pode mudar o seu. O SET GLOBAL exige o privilégio de alterar variáveis globais e vale para quem se conectar depois.

O manual trata a variável como um ajuste de espera: aumentar se as instruções precisam esperar mais, ou diminuir se muitas transações longas causam problemas de trava. Mudar o valor muda quanto o MySQL espera antes de desistir. Não muda quem está segurando a trava, então a investigação da seção anterior continua necessária.

Se o seu problema for outro limite do servidor, o guia Erro 1040 MySQL: Too many connections, como resolver trata do limite de conexões, que é um assunto separado.

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

Como evitar o erro 1205

O manual afirma que deadlocks e estouros de tempo de espera são normais em servidores ocupados, e que as aplicações precisam saber que eles podem ocorrer e tratá-los repetindo a operação. As práticas que a documentação lista:

• Transações curtas: mantenha as transações pequenas e de curta duração, fazendo o mínimo possível entre a primeira alteração e o commit. Às vezes, dividir o trabalho em várias transações ajuda.
• Commit logo depois das alterações: confirme a transação assim que terminar um conjunto de mudanças relacionadas.
• Não deixar sessão aberta: a documentação pede para não deixar uma sessão interativa do mysql aberta por muito tempo com uma transação sem commit.
• Índices bem escolhidos: eles fazem a consulta varrer menos registros e travar menos. O EXPLAIN ajuda a conferir.

Sobre o autocommit: por padrão ele vem ligado, e o MySQL faz um commit depois de cada instrução que não retornou erro. Com SET autocommit = 0, a sessão passa a ter uma transação aberta até o COMMIT ou o ROLLBACK. O commit e o rollback liberam todas as travas do InnoDB da transação, e uma sessão com autocommit desligado que termina sem commit tem a transação desfeita. Uma transação curta fica assim:

START TRANSACTION;

UPDATE pedidos SET status = 'pago' WHERE id = 1001;

COMMIT;

Para outro erro de integridade que aparece em gravações, o guia Erro 1452 MySQL: foreign key constraint, como resolver trata da chave estrangeira.

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 planos de VPS

Perguntas frequentes

O que significa o erro 1205 do MySQL?

Que uma transação esperou por uma linha travada por outra transação além do tempo limite. A mensagem é Lock wait timeout exceeded; try restarting transaction.

O erro 1205 desfaz a transação inteira?

Por padrão, não: o MySQL desfaz só a instrução que esperou. A transação inteira só é desfeita se o servidor foi iniciado com innodb_rollback_on_timeout ligada.

Qual a diferença entre o erro 1205 e o 1213?

O 1213 é deadlock: duas transações esperam uma pela outra e o InnoDB desfaz uma delas inteira. O 1205 é uma espera comum que passou do tempo.

Qual é o tempo padrão do innodb_lock_wait_timeout?

50 segundos. Ele vale para travas de linha do InnoDB, e pode ser mudado na sessão ou de forma global, sem reiniciar o servidor.

Como descobrir qual consulta está travando?

Consulte a view sys.innodb_lock_waits, que mostra a consulta que espera e a que bloqueia, ou a tabela information_schema.INNODB_TRX, que lista as transações.