Devo ter cuidado com ON DUPLICATE KEY UPDATE?

Em primeiro lugar:

• Sim, é uma prática comum e normal. Para upserts simples, eu diria que é a melhor prática.

Existem alguns casos bastante raros para se preocupar e coisas que podem incomodar você - especialmente considerando que você vem do mundo do SQL Server:

• Quando você o usa em uma tabela com duas ou mais UNIQUErestrições. Nesses casos, você não pode definir facilmente comportamentos diferentes para diferentes violações de restrição (embora seja possível com a MERGEinstrução).
  Um INSERTque viole 1 das 2 restrições únicas irá para a UPDATEcláusula. Se você quiser um comportamento diferente dependendo de qual restrição for violada, será difícil implementá-lo (possivelmente com algumas CASEexpressões complexas, mas pode não ser viável em todos os cenários).

• Uma grande diferença com o SQL Server (e todas as outras implementações principais do SQL) é que UNIQUEas restrições são verificadas após cada linha INSERTouUPDATE não como o padrão SQL diz no final da instrução (e nem pense em verificações de restrição adiadas).

  O problema com isso é para uma INSERT ... SELECT ... ON DUPLICATE KEY UPDATE ...;instrução, a ordem de como as linhas são processadas é importante. Se o SELECT criar 2 linhas para serem inseridas que conflitem em uma restrição UNIQUE, a primeira a ser processada será inserida e a segunda cairá para a UPDATEcláusula (e a ordem de processamento obviamente dependerá do plano de execução). Isso significa resultado não determinístico no estado da tabela após a instrução. Portanto, é preciso ter muito cuidado ao escrever essas declarações (e qualquer UPDATEdeclaração, na verdade).

• Relacionado ao ponto anterior, as INSERT ... ON DUPLICATE KEY UPDATEinstruções são marcadas como não seguras para replicação baseada em instrução, portanto, se você usá-las, ficará restrito à replicação baseada em linha ou mista.