Antwoord.

Bulk UPDATE is een kritische procedure bij het wijzigen van een groot aantal rijen in gerelateerde tabellen. In de geschiedenis van SQL is de typische implementatie een UPDATE met een subquery of JOIN. Probleem: elke bulk-update zonder controle van de volgorde blokkeert veel rijen, veroorzaakt escalatie van blokkeringen en kan tot deadlocks leiden bij meerdere updates.

Oplossing:

Splits altijd de UPDATE in kleine batches (bijvoorbeeld op primaire sleutel of datumbereiken).
Gebruik SET-georiënteerde benaderingen via JOIN, maar vermijd bulk-updates zonder beperkingen.
Leg slim filters op, indexeer velden op de WHERE-voorwaarden, houd rekening met de volgorde van bewerkingen voor gerelateerde tabellen.

Voorbeeldcode (PostgreSQL):

UPDATE Orders o
SET status = 'archived'
FROM Customers c
WHERE o.customer_id = c.id
  AND c.closed = TRUE
  AND o.status != 'archived';

Of batchgewijs:

WITH upd AS (
   SELECT o.id
   FROM Orders o
   JOIN Customers c ON o.customer_id = c.id
   WHERE c.closed = TRUE
   AND o.status != 'archived'
   LIMIT 10000
)
UPDATE Orders
SET status = 'archived'
WHERE id IN (SELECT id FROM upd);

Belangrijke kenmerken:

Vermijd het "gelijktijdig bijwerken van de hele tabel" — altijd batchen.
Gebruik indexen op het bijgewerkte en filterende veld.
Stel de selectiecriteria duidelijk in, om bulk-updates van onnodige rijen te vermijden.

Lastige vragen.

Wat gebeurt er als je tegelijkertijd UPDATE's van vergelijkbare tabellen uitvoert zonder het splitsen van intervallen of tegenstrijdige filters?

Waarschijnlijk zou er een deadlock ontstaan: processen blokkeren dezelfde rijen terwijl ze op elkaar wachten. Om dit te vermijden -- de batches moeten niet overlappen of strikt achtereenvolgens worden uitgevoerd.

Is er een verschil tussen UPDATE via JOIN en subquery als het gaat om massale statuswijzigingen?

Als er geschikte indexen zijn, is het belangrijkste verschil alleen in de leesbaarheid en soms in de prestaties van de specifieke DBMS. JOIN is meestal sneller, omdat het de optimizer in staat stelt een betere planning te maken.

Wanneer is het relevant om TRUNCATE/DELETE in plaats van UPDATE te gebruiken?

Als de bedrijfslogica dat toestaat — bijvoorbeeld wanneer je fysieke archiefrecords moet verwijderen of een tabel moet resetten, en niet alleen de statusflag hoeft te wijzigen. Maar voor massale statusupdates — alleen UPDATE.

Veelvoorkomende fouten en antipatterns

Massale UPDATE "zonder filter": blokkeringen, rollback, deadlock.
Gebrek aan indexen — volledige tabelscans.
Gelijktijdig uitvoeren van UPDATE zonder het splitsen van het bereik op sleutels.

Voorbeeld uit het leven

Negatief geval

In een grote online winkel werden meerdere UPDATE's uitgevoerd voor het wijzigen van de status van bestellingen en klanten tegelijkertijd, zonder het splitsen van intervallen. Resultaat: wederzijdse blokkeringen, meerdere keren was een gedwongen rollback nodig en niet-opgeslagen gegevens werden teruggedraaid.

Voordelen:

Alles in één query.

Nadelen:

Mogelijke deadlock, verlies van prestaties, enorme hoeveelheden gegevens worden teruggedraaid bij zelfs de kleinste fout.

Positief geval

Grote datasets werden opgesplitst in batches, werden strikt achtereenvolgens uitgevoerd, en er werden alleen noodzakelijke rijen op basis van filters verwerkt.