Eu tenho um procedimento armazenado que executa uma junção deTableB paraTableA:

 SELECT <--- Nested <--- TableA
             Loop   <--
                      |
                      ---TableB

Ao mesmo tempo, em uma transação, linhas são inseridas emTableAe depois paraTableB.

Ocasionalmente, essa situação está causando conflitos, pois o procedimento armazenado seleciona captura linhas deTabela B, enquanto a inserção adiciona linhas aTabelaAe cada um deseja que o outro solte a outra tabela:

INSERT     SELECT
=========  ========
Lock A     Lock B
Insert A   Select B
Want B     Want A
....deadlock...

A lógica requer oINSERT para adicionar primeiro linhas aAe depois paraB, enquanto eu pessoalmente não me importo com a ordem em que o SQL Server realiza sua associação - desde que ingresse.

A recomendação comum para a correção de conflitos é garantir que todos acessem os recursos na mesma ordem. Mas, neste caso, o otimizador do SQL Server está me dizendo que a ordem oposta é "melhor". posso forçar outra ordem de associação e ter uma consulta com pior desempenho.

Mas eu devo?

Devo substituir o otimizador, agora e para sempre, com uma ordem de junção que eu quero que ele use?

Ou devo apenas prender o erroerro nativo 1205e reenviar a instrução select?

A questão não é quão pior a consulta pode ser executada quando eu substituo o otimizador e ele faz algo não ideal. A questão é: é melhor tentar novamente automaticamente, em vez de executar consultas piores?