Início / dba / Perguntas / 4469
Accepted
700 Software
Asked: 2011-08-09 12:13:45 +0800 CST

Os Deadlocks do InnoDB são exclusivos para INSERT/UPDATE/DELETE?

  • 772

Estou trabalhando em torno do erro do MySQL "Impasse encontrado ao tentar obter o bloqueio; tente reiniciar a transação" .

Vou ter que atualizar um programa para permitir deadlocks. É possível que essa SELECTinstrução produza erros de deadlock? Eu sei que é apenas um bloqueio de leitura, então seleções múltiplas não serão um problema, mas e se houver uma instrução INSERT, UPDATEou (com subconsultas possíveis com junções) e uma instrução (possível com junções ou subconsultas) ?DELETESELECT

É possível que o erro seja lançado em SELECTvez de INSERT, UPDATEou DELETE.

A história está aqui se você estiver curioso.

mysql innodb

1 respostas

  1. Best Answer

    A resposta direta ao título da sua pergunta é Não.

    As consultas SELECT podem executar bloqueios no gen_clust_index , também conhecido como índice clusterizado.

    Aqui estão três perguntas do DBA Stack Exchanges que examinei agressivamente com @RedBlueThing , a pessoa que fez essas perguntas. @RedBlueThing encontrou soluções alternativas para suas perguntas.

    Apenas para manter sua pergunta em perspectiva, quando você examina essas respostas (não olhe muito profundamente, até eu fico tonto olhando para minhas próprias respostas complicadas), deve ser rapidamente aparente que as consultas SELECT podem bloquear dados.

    Você também tem casos especiais de SELECT onde você pode bloquear linhas específicas sob demanda .

    ATUALIZAÇÃO 2011-08-08 16:49 EDT

    Você fez a pergunta de variação: "Exceções de deadlock do InnoDB possivelmente serão lançadas por SELECT" A resposta para isso pode ser Sim sob uma determinada condição. Qual é essa condição? Se apenas uma única instrução SQL for revertida como resultado de um erro, alguns dos bloqueios definidos pela instrução poderão ser preservados. Isso acontece porque o InnoDB armazena bloqueios de linha em um formato que não permite saber posteriormente qual bloqueio foi definido por qual instrução .

    Com base nessa afirmação, as sequências de eventos para causar isso poderiam teoricamente ser as seguintes:

    • Seu SQL atualiza uma única linha, mas gera um erro
    • O UPDATE causa uma reversão de uma linha
    • A linha tem um bloqueio persistente

    Pessoalmente, essa última afirmação me assusta. Teria sido bom para o MySQL informar a todos sobre essa peculiaridade. No entanto, essa declaração é da documentação do MySQL. (Ah, sim, a Oracle é dona do InnoDB)

    ATUALIZAÇÃO 2015-09-22 18:40 EST

    No início do ano, descobri que Percona tem uma verificação legal do Nagios para encontrar esses bloqueios irritantes escondidos atrás de conexões adormecidas. Tudo o que você precisa fazer agora é executar o código desse link:

    SELECT COALESCE(MAX(IF(p.command = 'Sleep', p.time, 0)), 0) AS idle_in_trx
FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS AS w
INNER JOIN INFORMATION_SCHEMA.INNODB_TRX        AS b ON  b.trx_id = w.blocking_trx_id
INNER JOIN INFORMATION_SCHEMA.INNODB_TRX        AS r ON  r.trx_id = w.requesting_trx_id
LEFT JOIN  INFORMATION_SCHEMA.PROCESSLIST       AS p ON  p.id     = b.trx_mysql_thread_id;

    Isso funcionará apenas para o MySQL 5.5+. Se você tiver o MySQL 5.1 ou anterior, deverá eliminar todas as conexões adormecidas para liberar os bloqueios.

    • 6

relate perguntas