Question

I had to write a query to update all records in a table based on records that exist in two other different tables. I wrote the following three iterations of the query, I think the third one is the most efficient and the first one the worst. I just wanted a second opinion, and find out if i can do better than the third version below:

P.S : The first one is not really a valid SQL query, but a pseudocode of how i planned to query the database.

SELECT AccountID,Label FROM QueueTable

For each record in query above

    SELECT FeedbackID FROM FeedbackIndexed WHERE FeedbackIndexed.Label = QueueTable.Label
                                       AND  FeedbackIndexed.AccountID = QueueTable.AccountID

    UPDATE FeedbackTable SET Flag = 1 WHERE FeedbackID=@FeedbackID
next


---------------------------------------------------------------------------------------------------------------------

UPDATE FeedbackTable
SET    Flag = 1
WHERE  FeedbackID IN(SELECT DISTINCT FeedbackID
                           FROM   FeedbackIndexed,
                                  QueueTable
                           WHERE  FeedbackIndexed.Label = QueueTable.Label
                                  AND FeedbackIndexed.AccountID = QueueTable.AccountID)



----------------------------------------------------------------------------------------------------------------------


UPDATE FeedbackTable 
SET    FeedbackTable.Flag = 1
FROM   FeedbackTable
       INNER JOIN FeedbackIndexed
         ON FeedbackIndexed.FeedbackID = FeedbackTable.FeedbackID
       INNER JOIN QueueTable WITH (TABLOCK)
         ON FeedbackIndexed.Label = QueueTable.Label
            AND FeedbackIndexed.AccountID = QueueTable.AccountID


(I used table lock on QueueTable because at the end of this query i want to drop all records from the que and don't want other parts of the app adding more records to this table while the query above runs, is that right way to do this?)

Answer 1

Both your second and third examples are valid. Here are a few points:

1. In your second query, it is not neccessary to use DISTINCT that will simply add overhead. When you perform an IN operation, SQL will typically not perform the complete join operation and exit early as soon as a match is found. It also doesn’t return all the rows, just true/false whether there is a match for a given value.
2. Using IN in your second example may yield a more optimal join operator (semi-join vs join) because you’re explicitly stating that you are not interested in the output from the subquery, just whether or not there are records returned.
3. You may be better off using the EXISTS clause. Although it’s a common misconception that IN less efficient than EXISTS (they actually implement queries the same in most cases) IN can give unexpected results when dealing with nulls.

The EXISTS version would look something like this:

UPDATE FT
SET    Flag = 1
FROM   FeedbackTable
WHERE  EXISTS(SELECT * 
        FROM FeedbackIndexed FI 
            INNER JOIN QueueTable QT 
            ON FI.Label = QT.Label 
                AND FI.AccountID = QT.AccountID
          WHERE FeedbackID = FT.feedbackID)

The underlying query plan will likely be exactly the same as your IN example (after you remove the redundant DISTINCT) and it may yield the same query plan as the 3rd example but it’s always good to know different approaches to solving a problem.

A few more points.

• Your TABLOCK will be released when the query completes unless you wrap the query and the query to drop the processed records in an explicit transaction. I’m pretty sure you’ll want to add HOLDLOCK here too. HOLDLOCK will hold the lock for the duration of the transaction.
• You mentioned a concern preventing writes to your queue table, what about reads? TABLOCK will implement a shared lock which may cause a race condition if your consumer proc is running multiple instances simultaneously. Consider using TABLOCKX if that will be a problem.
• There may be better ways manage locking and race conditions there. I like to use SP_GETAPPLOCK for this. I wrote an article on the subject several years ago, it may be worth a read sp_getapplock

I hope this helps.