Prestazioni atroci che uniscono tabelle INSERITE e CANCELLATE in un trigger

Ho un trigger UPDATE su una tabella che cerca una colonna specifica che cambia da un valore specifico a qualsiasi altro valore. Quando ciò accade, aggiorna alcuni dati correlati in un'altra tabella tramite una singola istruzione UPDATE.

La prima cosa che fa il trigger è verificare se le righe aggiornate hanno cambiato il valore di questa colonna rispetto al valore in questione. Unisce semplicemente INSERTED a DELETED e confronta il valore in quella colonna. Se nulla si qualifica, viene salvato in anticipo quindi l'istruzione UPDATE non viene eseguita.

IF NOT EXISTS (
    SELECT TOP 1 i.CUSTNMBR
    FROM INSERTED i
        INNER JOIN DELETED d
            ON i.CUSTNMBR = d.CUSTNMBR
    WHERE d.CUSTCLAS = 'Misc'
        AND i.CUSTCLAS != 'Misc'
)
    RETURN

In questo caso, CUSTNMBR è la chiave primaria della tabella sottostante. Se eseguo un aggiornamento di grandi dimensioni su questa tabella (diciamo, oltre 5000 righe), questa istruzione prende AGES, anche se non ho toccato la colonna CUSTCLAS. Posso vederlo bloccato su questa affermazione per diversi minuti in Profiler.

Il piano di esecuzione è bizzarro. Mostra una scansione inserita con 3.714 esecuzioni e ~ 18,5 milioni di righe di output. Ciò attraversa un filtro nella colonna CUSTCLAS. Unisce questo (tramite loop nidificato) a una scansione eliminata (filtrata anche su CUSTCLAS), che viene eseguita una sola volta e ha 5000 righe di output.

Che cosa idiota sto facendo qui per causare questo? Si noti che il trigger deve assolutamente gestire correttamente gli aggiornamenti multi-riga.

MODIFICA :

Ho anche provato a scriverlo in questo modo (nel caso EXISTS stesse facendo qualcosa di spiacevole), ma è comunque altrettanto terribile.

DECLARE @CUSTNMBR varchar(31)
SELECT TOP 1 @CUSTNMBR = i.CUSTNMBR
FROM INSERTED i
    INNER JOIN DELETED d
        ON i.CUSTNMBR = d.CUSTNMBR
WHERE d.CUSTCLAS = 'Misc'
    AND i.CUSTCLAS != 'Misc'

IF @CUSTNMBR IS NULL
    RETURN

Potresti valutare usando espliciti INNER MERGE JOINo INNER HASH JOINsuggerimenti, ma dato che presumibilmente stai usando di nuovo queste tabelle più tardi nel trigger, probabilmente stai meglio semplicemente inserendo il contenuto insertede le deletedtabelle in #temptabelle indicizzate e facendo ciò.

Non ottengono automaticamente utili indici creati per loro.

So che è stata data una risposta, ma è apparso di recente attivo e mi sono imbattuto anche in questo per le tabelle con milioni di righe. Pur non scontando la risposta accettata, posso almeno aggiungere che la mia esperienza dimostra che un fattore chiave nelle prestazioni di trigger quando si eseguono test simili (vedere se una o più colonne hanno effettivamente cambiato i loro valori) è se le colonne sono o meno in fase di test facevano effettivamente parte UPDATEdell'affermazione. Ho scoperto che il confronto di colonne tra le tabelle insertede deletedche in realtà non facevano parte dell'istruzione ha comportatoUPDATE un enorme trascinamento delle prestazioni che altrimenti non sarebbero state presenti se quei campi facessero parte dellaUPDATEistruzione (indipendentemente dal fatto che il loro valore venga effettivamente modificato). Perché tutto ciò funziona (ad esempio una query per confrontare N campi su X righe) per determinare se qualcosa è cambiato se è possibile escludere logicamente la possibilità che una di quelle colonne venga modificata, il che ovviamente non è possibile se non fossero presenti nella SETclausola della UPDATEdichiarazione.

La soluzione che ho usato è stata quella di utilizzare la funzione UPDATE () che funziona solo all'interno di Trigger. Questa funzione integrata indica se è stata specificata una colonna UPDATEnell'istruzione e può essere utilizzata per uscire dal trigger se le colonne di cui si è preoccupati non fanno parte di UPDATE. Questo può essere usato insieme a a SELECTper determinare se quelle colonne, supponendo che siano presenti nel UPDATE, hanno delle modifiche effettive. Ho il codice nella parte superiore di diversi trigger di controllo che assomigliano a:

-- exit on updates that do not update the only 3 columns we ETL
IF (
     EXISTS(SELECT 1 FROM DELETED) -- this is an UPDATE (Trigger is AFTER INSERT, UPDATE)
     AND (
            NOT (UPDATE(Column3) OR UPDATE(Column7)
                 OR UPDATE(Column11)) -- the columns we care about are not being updated
            OR NOT EXISTS(
                        SELECT 1
                        FROM INSERTED ins
                        INNER JOIN DELETED del
                                ON del.KeyField1 = ins.KeyField1
                                AND del.KeyField2 = ins.KeyField2
                        WHERE ins.Column3 <> del.Column3
                                 COLLATE Latin1_General_100_CS_AS -- case-sensitive compare
                        OR    ISNULL(ins.Column7, -99) <> 
                                 ISNULL(del.Column7, -99) -- NULLable INT field
                        OR    ins.[Column11] <> del.[Column11] -- NOT NULL INT field
                      )
          )
    )
BEGIN
    RETURN;
END;

Questa logica procederà al resto del trigger se:

1. L'operazione è un INSERT
2. Almeno uno dei campi rilevanti è nella SETclausola di una UPDATE e almeno una di quelle colonne in una riga è cambiata

Il NOT (UPDATE...) OR NOT EXISTS()potrebbe apparire strano o indietro, ma è progettato per evitare di fare il SELECTsui insertede deletedtavoli se nessuna delle colonne rilevanti fanno parte del UPDATE.

A seconda delle esigenze, la funzione COLUMNS_UPDATED () è un'altra opzione per determinare quali colonne fanno parte dell'istruzioneUPDATE .

Potrei provare a riscrivere usando se esiste

IF EXISTS (SELECT TOP 1 i.CUSTNMBR     
            FROM INSERTED i         
            INNER JOIN DELETED d             
            ON i.CUSTNMBR = d.CUSTNMBR and d.custclass = 'Misc'  
            WHERE d.CUSTCLAS <>i.CUSTCLAS)    
BEGIN

--do your triggerstuff here
END

http://dave.brittens.org/blog/writing-well-behaved-triggers.html

Secondo Dave, è necessario utilizzare tabelle temporanee o variabili di tabella con indici, poiché le tabelle INSERTED / DELETED virtuali non ne hanno. Se hai la possibilità di trigger ricorsivi, allora dovresti usare le variabili di tabella per evitare collisioni di nomi.

Spero che qualcuno lo trovi utile dato che il post originale era un po 'di tempo fa ...

Il codice seguente potrebbe aumentare le prestazioni di questo trigger. Non conoscevo il tipo di dati corretto della colonna [custclass] , quindi è necessario modificarlo.

DECLARE @i AS TABLE (CUSTNMBR VARCHAR(31) NOT NULL PRIMARY KEY, custclass VARCHAR(10) NOT NULL)
DECLARE @d AS TABLE (CUSTNMBR VARCHAR(31) NOT NULL PRIMARY KEY, custclass VARCHAR(10) NOT NULL)
INSERT INTO @i SELECT CUSTNMBR, custclass FROM inserted
INSERT INTO @d SELECT CUSTNMBR, custclass FROM deleted
IF NOT EXISTS
  (SELECT * FROM @i AS i INNER JOIN @d AS d ON d.CUSTNMBR = i.CUSTNMBR
   WHERE i.custclass <> d.custclass) RETURN

Si noti che è possibile includere colonne aggiuntive in queste copie di memoria delle tabelle inserite ed eliminate se sono necessarie nel codice di attivazione. Le chiavi primarie su queste tabelle aumenteranno notevolmente le prestazioni dei join quando si aggiornano più righe contemporaneamente. In bocca al lupo!