Erro 1213 MySQL: Deadlock found, como resolver

Entenda o erro 1213 do MySQL: o que é o deadlock no InnoDB, como ver o último ocorrido, como reduzir e como repetir a transação no código.

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

O erro 1213 MySQL aparece quando duas ou mais transações do InnoDB travam uma à outra: cada uma segura um bloqueio de que a outra precisa. O banco desfaz uma delas e devolve a mensagem "Deadlock found"; essa transação precisa ser repetida.

Aqui você vê o texto exato da mensagem, o que o InnoDB faz com a transação escolhida e como ela se diferencia do erro 1205 (lock wait timeout). Depois, como consultar o último deadlock, as dicas do manual para reduzir a frequência e como repetir a transação no seu código. Os fatos vêm do manual do MySQL 8.4.

O que a mensagem diz

Na referência de erros do servidor do MySQL 8.4, o erro tem estes dados:

• Número: 1213
• Símbolo: ER_LOCK_DEADLOCK
• SQLSTATE: 40001

A mensagem, e a forma como o cliente mostra o erro, são:

Deadlock found when trying to get lock; try restarting transaction

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

A própria mensagem já traz a orientação: tentar reiniciar a transação. O manual vai na mesma direção e diz que, mesmo com a lógica da aplicação correta, é preciso tratar o caso em que uma transação precisa ser repetida.

O que o InnoDB faz quando acontece um deadlock

O manual define deadlock como uma situação em que várias transações não conseguem avançar porque cada uma segura um bloqueio de que outra precisa. Como todas esperam o mesmo recurso ficar livre, nenhuma delas libera o bloqueio que tem.

Com a detecção ligada (que é o padrão), o InnoDB percebe a situação e desfaz uma das transações, chamada de vítima. Sobre a escolha, a documentação diz que o InnoDB "tries to pick small transactions to roll back", e que o tamanho é medido pelo número de linhas inseridas, atualizadas ou apagadas. Pelo verbo "tries" (tenta), a regra é uma preferência, e não uma promessa de qual será escolhida.

O ponto mais importante para quem programa: segundo o manual, o deadlock faz o InnoDB desfazer a transação inteira, e não só o último comando. Por isso a recomendação é repetir a transação inteira.

Duas observações da documentação:

• Você pode ter deadlock mesmo em transações que só inserem ou apagam uma linha, porque o InnoDB usa bloqueio automático por linha.
• Se a detecção for desligada pela variável innodb_deadlock_detect, o InnoDB passa a depender do innodb_lock_wait_timeout para desfazer transações em caso de deadlock.

Deadlock (1213) x lock wait timeout (1205)

Os dois erros pedem para reiniciar a transação, mas acontecem em situações diferentes. Na referência de erros, o 1205 tem o símbolo ER_LOCK_WAIT_TIMEOUT, o SQLSTATE HY000 e a mensagem:

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

Em termos práticos, segundo o manual:

• 1213 (deadlock): o InnoDB desfaz a transação inteira. A transação deve ser repetida por completo.
• 1205 (timeout): o InnoDB desfaz só o comando que esperava o bloqueio e estourou o tempo. Para desfazer a transação inteira, o servidor precisa ser iniciado com --innodb-rollback-on-timeout ligado.

O tempo de espera do 1205 vem da variável innodb_lock_wait_timeout, que tem 50 segundos como padrão. A documentação explica que esse tempo não se aplica a deadlocks quando a detecção está ligada, porque o InnoDB detecta o deadlock na hora e desfaz uma das transações. Se a sua mensagem é a de timeout, o guia Erro 1205 MySQL: Lock wait timeout, como investigar cobre esse caso.

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 ver o último deadlock

Para investigar a causa, o manual indica o comando abaixo. Ele mostra, entre outras informações, o último deadlock detectado em uma transação de usuário do InnoDB:

SHOW ENGINE INNODB STATUS;

Na saída, procure a seção LATEST DETECTED DEADLOCK. Os títulos que o manual mostra no exemplo são, para cada uma das duas transações, a transação em si (*** (1) TRANSACTION: e *** (2) TRANSACTION:), os bloqueios que ela segura (HOLDS THE LOCK(S)) e o bloqueio que ela espera receber (WAITING FOR THIS LOCK TO BE GRANTED). No fim, uma linha como *** WE ROLL BACK TRANSACTION (2) indica qual foi a vítima.

Esse comando só mostra o último. Para registrar cada um, existe a variável innodb_print_all_deadlocks, de tipo booleano, com padrão OFF. Quando ligada, as informações de cada deadlock vão para o log de erros do mysqld. O manual traz estes comandos no exemplo:

SET GLOBAL innodb_print_all_deadlocks = ON;

SELECT @@log_error;

O segundo consulta a variável log_error, ligada ao log de erros do servidor. Para conferir se a variável está ligada, a consulta SHOW VARIABLES LIKE 'innodb_print_all_deadlocks'; usa o nome documentado. O manual orienta desligar a opção quando terminar a depuração. Para contar quantos deadlocks já ocorreram, a página usa:

SELECT `count` FROM INFORMATION_SCHEMA.INNODB_METRICS

WHERE NAME="lock_deadlocks";

Como reduzir os deadlocks

Segundo a página "How to Minimize and Handle Deadlocks", deadlocks são um problema clássico de bancos transacionais, mas não são perigosos, a menos que sejam tão frequentes que algumas transações não consigam rodar. Um deadlock ocasional não é necessariamente um problema. Muitos deles, porém, podem indicar a necessidade de reestruturar as transações. As dicas do manual:

• Mantenha as transações pequenas e curtas, para que colidam menos.
• Faça commit logo depois de um conjunto de mudanças relacionadas. Em especial, não deixe uma sessão interativa do mysql aberta por muito tempo com uma transação sem commit.
• Se usar leituras com bloqueio (SELECT ... FOR UPDATE ou SELECT ... FOR SHARE), tente um nível de isolamento menor, como READ COMMITTED.
• Ao alterar várias tabelas, ou conjuntos diferentes de linhas da mesma tabela, faça as operações em uma ordem consistente a cada vez. Assim as transações formam filas bem definidas e não travam umas às outras.
• Crie índices bem escolhidos, para que as consultas leiam menos registros de índice e façam menos bloqueios. O manual manda usar EXPLAIN SELECT para ver quais índices o servidor considera mais adequados.
• Use menos bloqueios: se você aceita que um SELECT devolva dados de um retrato antigo, não acrescente FOR UPDATE nem FOR SHARE.
• Se nada mais ajudar, serialize as transações com bloqueios de tabela. Com o InnoDB, o manual manda começar com SET autocommit = 0 (e não com START TRANSACTION), seguido de LOCK TABLES, e só chamar UNLOCK TABLES depois do commit explícito. O custo, segundo a página, é menos resposta em um sistema ocupado.
• Outra forma de serializar é criar uma tabela "semáforo" auxiliar com uma só linha e fazer cada transação atualizar essa linha antes de acessar as outras tabelas.

Em sistemas com muita concorrência, a detecção também tem custo: o manual diz que ela pode causar lentidão quando muitas threads esperam o mesmo bloqueio, e que às vezes pode ser mais eficiente desligá-la e depender do innodb_lock_wait_timeout. É uma decisão de quem administra o servidor, e não um primeiro passo.

Como tratar no código: repetir a transação

Como o manual diz para estar preparado para reemitir a transação, o tratamento mais simples é repetir. Em passos, sem depender de linguagem:

1. Execute a transação inteira: o início, os comandos e o commit.
2. Se algum comando devolver o erro 1213 (SQLSTATE 40001), considere que o InnoDB desfez a transação inteira. Nada do que ela fez ficou gravado.
3. Execute a transação inteira de novo, desde o início, e não só o comando que falhou.
4. Defina um limite de tentativas. Se o erro continuar, registre o problema e investigue com o SHOW ENGINE INNODB STATUS.
5. Se o erro ocorre muitas vezes, siga as dicas da seção anterior, como ordem consistente de acesso e transações mais curtas.

O limite de tentativas e a espera entre elas são escolhas suas; o manual não define esses valores. Se a conexão cair no meio do caminho, o erro é outro e o guia Erro 2013 MySQL: Lost connection, como resolver mostra como investigar.

Precisa de um servidor para o seu projeto? VPS a partir de R$ 17,00/mês no Plano Bronze; confira na loja o que cada plano inclui. Ver os planos de VPS

Perguntas frequentes

O que significa o erro 1213 no MySQL?

Significa que o InnoDB detectou um deadlock, isto é, transações que se travam mutuamente, e desfez uma delas. O símbolo é ER_LOCK_DEADLOCK e o SQLSTATE é 40001.

Preciso repetir a transação depois do erro 1213?

Sim. O manual diz que o deadlock faz o InnoDB desfazer a transação inteira e manda repeti-la por completo.

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

No 1213, o InnoDB desfaz a transação inteira por causa de um deadlock. No 1205, o tempo de espera por um bloqueio estoura e, por padrão, só o comando é desfeito.

Dá para eliminar os deadlocks?

O manual não promete isso. Diz que mesmo com a lógica correta é preciso tratar o caso e repetir a transação; as dicas de redução apenas diminuem a chance de colisão.