Por favor, pare de usar este anti-padrão UPSERT

IF EXISTS (SELECT 1 FROM dbo.t WHERE [key] = @key)
BEGIN
  UPDATE dbo.t SET val = @val WHERE [key] = @key;
END
ELSE
BEGIN
  INSERT dbo.t([key], val) VALUES(@key, @val); 
END

• Já existe uma linha para esta chave?
  • SIM :OK, atualize essa linha.
  • NÃO :OK, adicione-o.

Mas isso é um desperdício.

• Se a chave existir e duas sessões tentarem atualizar simultaneamente, elas ambas serão atualizadas com sucesso (um vai "ganhar"; o "perdedor" seguirá com a mudança que fica, levando a uma "atualização perdida"). Isso não é um problema por si só, e é assim que devemos esperar que um sistema com simultaneidade funcione. Paul White fala sobre a mecânica interna com mais detalhes aqui, e Martin Smith fala sobre algumas outras nuances aqui.
• Se a chave não existir, mas ambas as sessões passarem na verificação de existência da mesma forma, tudo pode acontecer quando ambas tentarem inserir:
  • bloqueio devido a bloqueios incompatíveis;
  • gerar erros de violação de chave isso não deveria ter acontecido; ou,
  • inserir valores de chave duplicados se essa coluna não estiver adequadamente restrita.

"Muitas pessoas estão dizendo..."

• Remoção de mitos:soluções de atualização/inserção simultâneas – onde ele reconheceu que deixar a lógica inicial em vigor e apenas elevar o nível de isolamento apenas alterava as violações de chave para impasses;
• Tenha cuidado com a declaração de mesclagem - onde ele verificou seu entusiasmo sobre MERGE; e,
• O que evitar se você quiser usar MERGE – onde ele confirmou mais uma vez que ainda existem muitas razões válidas para continuar evitando MERGE .

A solução

BEGIN TRANSACTION;
 
UPDATE dbo.t WITH (UPDLOCK, SERIALIZABLE) SET val = @val WHERE [key] = @key;
 
IF @@ROWCOUNT = 0
BEGIN
  INSERT dbo.t([key], val) VALUES(@key, @val);
END
 
COMMIT TRANSACTION;

• UPDLOCK é usado para proteger contra impasses de conversão na instrução nível (deixe outra sessão esperar em vez de encorajar a vítima a tentar novamente).
• SERIALIZABLE é usado para proteger contra alterações nos dados subjacentes em toda a transação (garantir que uma linha que não existe continue a não existir).

• Se a chave existir e duas sessões tentarem atualizá-la ao mesmo tempo, elas se revezarão e atualizarão a linha com sucesso , como antes.
• Se a chave não existir, uma sessão "vencerá" e inserirá a linha . O outro terá que esperar até que os bloqueios sejam liberados para verificar a existência e serem forçados a atualizar.

Mas e se uma atualização for menos provável?

BEGIN TRANSACTION;
 
INSERT dbo.t([key], val) 
  SELECT @key, @val
  WHERE NOT EXISTS
  (
    SELECT 1 FROM dbo.t WITH (UPDLOCK, SERIALIZABLE)
      WHERE [key] = @key
  );
 
IF @@ROWCOUNT = 0
BEGIN
  UPDATE dbo.t SET val = @val WHERE [key] = @key;
END
 
COMMIT TRANSACTION;

BEGIN TRANSACTION;
 
BEGIN TRY
  INSERT dbo.t([key], val) VALUES(@key, @val);
END TRY
BEGIN CATCH
  UPDATE dbo.t SET val = @val WHERE [key] = @key;
END CATCH
 
COMMIT TRANSACTION;

E o upser de várias linhas?

CREATE PROCEDURE dbo.UpsertTheThings
    @tvp dbo.TableType READONLY
AS
BEGIN
  SET NOCOUNT ON;
 
  BEGIN TRANSACTION;
 
  UPDATE t WITH (UPDLOCK, SERIALIZABLE) 
    SET val = tvp.val
  FROM dbo.t AS t
  INNER JOIN @tvp AS tvp
    ON t.[key] = tvp.[key];
 
  INSERT dbo.t([key], val)
    SELECT [key], val FROM @tvp AS tvp
    WHERE NOT EXISTS (SELECT 1 FROM dbo.t WHERE [key] = tvp.[key]);
 
  COMMIT TRANSACTION;
END

Conclusão