Question

I have this SQL update query:

UPDATE table1 
SET table1.field1 = 1 
WHERE table1.id NOT IN (SELECT table2.table1id FROM table2);

Other portions of the application can add records to table2 which use the field table1id to reference table1.

The goal here is to remove records from table1 which aren’t referenced by table2.

Does SQL Server automatically lock table2 with this kind of query so that a new record can’t be added to table2 while executing this query?

I’ve also considered:

UPDATE table1 
SET field1 = 1 
WHERE 0 = (SELECT COUNT(*) FROM table2 WHERE table1.id = table2.table1id);

Which seems possibly safer, but much slower (because a SELECT would be called on each row of table1 instead of just one select for the NOT IN)

Answer 1

No, is not inherently safe. The subquery will grab locks and release them immediately, allowing for concurrent updates/inserts/deletes on table2. Also multiple transactions running this query may attempt to modify the same rows in table1 even when table2 is stable, likely deadlocking each other.

Your second query is just as unsafe.

It is very hard to get these kind of queries right. For some queries you can use an XLOCK hint, but in your case you are interested in the missing keys, so it won’t help. The only 100% safe alternative TABLOCKX hint, but that’s a sledgehammer which will kill all concurrency.

Ultimately you have to go back to the drawing back and ask yourself the business meaning of the operation.

• What is somebody inserts a new key in table2 after you checked for it? It wasn’t there where you looked for it, so your operation is correct. If not, then how come a transaction is inserting something another transaction is just deleting? It goes back to understanding your domain model to decide the proper action.
• What is you block an insert of a new key in table2 while you update table1? How is this different from the point above?
• What is somebody deletes a key you found in table2 after your query did not update table1 because the key was present? Same as before, how is this different from deleting the key after the update completed?