Faça uma tabela Ignore atualizações triviais

Você deve adicionar qual sistema de banco de dados, versão e edição você está usando...

...porque sua quilometragem pode variar em algumas das conclusões que você tirou, dependendo desses fatores.

Por exemplo:

O SQL Server não processa UPDATEinstruções redundantes, em diferentes extensões, em cenários específicos.

Então suas declarações...

Todas essas atualizações precisam ser registradas! Então, no processo de não fazer nada, fragmentamos e dividimos as páginas de índice e dados que temos para a tabela na RAM e no disco. E estamos colocando tráfego desnecessário no log.

Se não mudarmos nada, uma atualização trivial ainda estará causando rotatividade na RAM e no disco.

...estão incorretas em alguns contextos.

Prova

Paul White escreveu um post de blog muito interessante sobre este assunto intitulado The Impact of Non-Updating Updates . É uma leitura curta, então recomendo fortemente que você o leia na íntegra. Mas alguns (não quero revelar todos os detalhes interessantes) dos pontos-chave que ele resume no final são:

• Atualizações não atualizadas em uma tabela agrupada geralmente evitam registro extra e limpeza de página, a menos que uma coluna que forma (parte) da chave de agrupamento seja afetada pela operação de atualização.

• As tabelas de heap se comportam da mesma forma que as tabelas em cluster, exceto que elas não têm uma chave de cluster para causar qualquer registro extra ou limpeza de página.

  Isso continua sendo o caso mesmo quando uma chave primária não clusterizada existe no heap. Atualizações não atualizadas em um heap, portanto, geralmente evitam o registro e a descarga extras (mas veja abaixo)

• Tanto os heaps quanto as tabelas agrupadas sofrerão registro e liberação extras para qualquer linha em que uma coluna LOB contendo mais de 8000 bytes de dados for atualizada para o mesmo valor usando qualquer sintaxe diferente de SET column_name = column_name.

...sério, não confie em mim para copiar e colar corretamente acima, e vá ler o artigo de Paul na íntegra.

Portanto

Pelo menos no SQL Server, atualizações redundantes, também conhecidas como atualizações sem atualização, nem sempre " causam rotatividade desnecessária na RAM e no disco ".

Mas é bom ser explícito

Porque nem todos os casos são garantidos e as coisas podem mudar no futuro, seja na forma como o mecanismo de banco de dados processa uma atualização não atualizada UPDATEou na forma como seu código e dados evoluem ao longo do tempo.

Existem algumas maneiras diferentes de tentar resolver:

Existe algo que eu possa fazer na tabela para que ela aja como se soubesse passar atualizações triviais?

A resposta de Akina é uma opção, embora ela ainda gere registros de log para exclusões das linhas que você removeu antecipadamente e exija uma passagem dupla para atingir seu objetivo.

Outra opção é fazer hash da linha e materializar o valor hash em uma coluna para que ela possa ser indexada. Então você pode comparar suas chaves SourceTablee TargetTablenas chaves deles onde os valores hash não correspondem, de uma forma muito eficiente, por meio de uma consulta como:

UPDATE T
SET T.SomeField1 = S.SomeField1
FROM SourceTable AS S
INNER JOIN TargetTable AS T
    ON S.KeyField = T.KeyField -- Same row by key
    AND S.RowHash <> T.RowHash; -- But has changes

Uma passagem, comparação eficiente, sem necessidade de gerar registros de log extras excluindo as linhas que não serão usadas para a atualização porque seus valores são redundantes.

No passado, usei essa técnica para grandes conjuntos de dados para problemas semelhantes. Eu particularmente uso a HASHBYTES()função para calcular o hash da linha, que é determinístico e pode ser armazenado em uma coluna computada ou em uma visualização indexada (se você não quiser modificar o esquema da tabela). Mas, novamente, suas opções aqui dependerão do seu sistema de banco de dados, versão e edição.

Nota lateral

Imperturbável é uma boa palavra para usar aqui...

Acho que " não molestado " é uma péssima escolha de palavras neste contexto devido às suas conotações usuais.

Você recebe seu CSV e o salva na [their].[catalog]tabela.

Como primeiro passo, exclua as linhas desta tabela que causarão "atualizações triviais".

DELETE FROM [their].[catalog] AS tc
WHERE EXISTS (
    SELECT NULL
    FROM [my].[catalog] AS mc
    WHERE mc.id = tc.id 
      AND mc.[field1] = tc.[field1] 
      AND mc.[field2] = tc.[field2]
    );

Esta consulta usará índices compostos de acordo com muita eficiência. Então, não esqueça de criar esses índices em sua tabela temporária que contém o estado real dos dados recebidos de sua "fonte da verdade".

Após essa exclusão, a tabela [their].[catalog]conterá apenas as linhas que causarão "atualizações práticas", e você poderá atualizar sem filtragem adicional:

UPDATE mc 
SET [field1] = tc.[field1]
  , [field2] = tc.[field2]
FROM [my].[catalog] as mc  
INNER JOIN [their].[catalog] as tc
    ON mc.id = tc.id;

Esta consulta, novamente, pode usar índices (primários?) de acordo com eficiência.

Eu realmente aprecio as contribuições acima. Valeu, pessoal! O link para o artigo de Paul White é realmente útil. Muito obrigado.

A solução que tenho é adicionar uma coluna calculada persistente à tabela [row_hash]. É o resultado da função Hashbytes do SQL Server.

Um gatilho INSTEAD OF me permite agrupar as pseudotabelas inseridas e excluídas por suas chaves e agir somente em linhas que tenham uma hash_column alterada.

Com o gatilho em vigor, a tabela é mais tolerante para um desenvolvedor menos iniciado. E também posso cortar parte da sobrecarga que venho construindo com praticamente todas as instruções MERGE que escrevo.

Com o row_hash persistido e o gatilho INSTEAD OF agindo como o border collie, apenas as linhas com alterações reais são alteradas.

O código para configurar isso está neste documento: https://github.com/islandmonk/update_only_when_changed/blob/main/row_hash%20infrastructure.sql

Um exemplo de uso é em uma tabela com o seguinte esquema:

    CREATE TABLE [dbo].[note](
          [note_id] [int] IDENTITY(1,1) NOT NULL PRIMARY KEY 
        , [object_id] [int] NULL 
        , [column_id] [int] NULL 
        , [parent_note_id] [int] NULL 
        , [note] [nvarchar](max) NULL 
        , [created] [datetime] NOT NULL default(getdate())
    )  

O código necessário para configurar isso para ignorar atualizações redundantes é este:

-- Add row_hash column to table [dbo].[note]
--
ALTER TABLE [dbo].[note] ADD row_hash as HASHBYTES('sha2_512', CONCAT(
      [object_id]
    , [column_id]
    , [parent_note_id]
    , [note]
    , [created])
) PERSISTED; 
GO



--------
-- INSTEAD OF UPDATE trigger for [dbo].[note]
CREATE OR ALTER TRIGGER dbo_note__instead_of_IUD ON [dbo].[note]
INSTEAD OF UPDATE, INSERT, DELETE 
AS
    /*
    This is the definition of an INSTEAD OF trigger. Its initial purpose is to reduce churn on tables
    mostly for the sake of performance. There is nothing stopping you from altering this trigger to
    add other functionality. Keep in mind, also, that you can have AFTER UPDATE triggers on the same
    table as one with an INSTEAD OF UPDATE trigger. So that is still available to you even if you
    go with this approach.
    */

    UPDATE d
    SET 
          [object_id] = i.[object_id]
        , [column_id] = i.[column_id]
        , [parent_note_id] = i.[parent_note_id]
        , [note] = i.[note]
    FROM [dbo].[note] as d -- deleted
    INNER JOIN inserted as i 
        ON d.[note_id] = i.[note_id] 

    -- rows where there is no difference between inserted and deleted are redundant and ignored
    WHERE d.[row_hash] <> i.[row_hash] 


    -- Inserts proceed as usual

    INSERT [dbo].[note] (
          [object_id]
        , [column_id]
        , [parent_note_id]
        , [note]
        , [created]
    )
    SELECT 
          [object_id]
        , [column_id]
        , [parent_note_id]
        , [note]
        , [created]
    FROM inserted as i
    WHERE NOT EXISTS (
        SELECT TOP 1 1
        FROM deleted as d
        WHERE d.[note_id] = i.[note_id]     
    )

    -- DELETES proceed as usual

    DELETE t 
    FROM [dbo].[note] as t -- target 
    INNER JOIN deleted as d
        ON d.[note_id] = i.[note_id] 
    WHERE NOT EXISTS (
        SELECT TOP 1 1
        FROM inserted as i
        WHERE d.[note_id] = i.[note_id]     
    )
GO
--------------