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

Vou precisar atualizar um programa para permitir conflitos. É possível que a SELECTinstrução produza erros de conflito? Eu sei que é apenas um bloqueio de leitura para que vários seleciona não será um problema, mas o que se há uma INSERT, UPDATEou DELETEdeclaração (com subqueries possível com junta) e uma SELECTdeclaração (possível com junta ou subqueries) ?

É possível que o erro seja gerado no SELECTlugar do INSERT, UPDATEou DELETE.

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

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 sobre trocas de pilhas do DBA que examinei agressivamente com o @RedBlueThing , a pessoa que fez essas perguntas. O @RedBlueThing encontrou soluções para suas perguntas.

• Motivos para consultas lentas ocasionalmente?
• Problemas ao decifrar um impasse em um log de status do innodb
• Essas duas consultas resultarão em um impasse se executadas em sequência?

Apenas para manter sua pergunta em perspectiva, quando você examinar essas respostas (não olhe muito fundo, até eu fico tonto ao ver minhas próprias respostas complicadas), deve ficar claro rapidamente que as consultas SELECT podem bloquear dados.

Você também tem casos especiais de SELECT, nos quais é possível bloquear linhas específicas sob demanda .

UPDATE 2011-08-08 16:49 EDT

Você fez a pergunta de variação: "As exceções de impasse do InnoDB possivelmente serão lançadas pelo SELECT" A resposta para isso pode ser Sim sob uma determinada condição. O que é 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 linhas em um formato que não pode saber posteriormente qual bloqueio foi definido por qual instrução .

Com base nessa afirmação, as seqüê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 possui o InnoDB)

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

No início do ano, eu aprendi que Percona tem uma verificação legal do Nagios para encontrar essas fechaduras traquinas escondidas atrás de conexões adormecidas. Tudo o que você precisa fazer agora é executar o código nesse 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ê possui o MySQL 5.1 ou anterior, você deve eliminar todas as conexões inativas para liberar os bloqueios.