I'm writing an application to:

* select a small recordset from a table of subscribers (150k records);
* update those rows to indicate that an email is in the process of being sent;
* send email to the subscribers in the recordset;
* update the rows again to indicate that the email has been sent.

The wrinkle is that the table is simultaneously being accessed by multiple clients to distribute the email workload, which is why there is the intermediate update (to indicate in-process) is used -- to keep the different clients from selecting the same rows, which results in multiple emails being sent to the same subscriber. I've applied some randomizing logic to reduce the likelihood of two clients working with the same data, but it still happens occasionally.

So now I am looking at using SELECT ... FOR UPDATE in order to lock the relevant rows (so another client won't select them). My question: is it better to write the UPDATE statement based on the IDs of the `SELECT...FOR UPDATE` statement, or to create a loop to update each row individually?

Here's what I've got so far:

```
DELIMITER $$

CREATE DEFINER=`mydef`@`%` PROCEDURE `sp_SubscribersToSend`(v_limit INTEGER)
BEGIN

START TRANSACTION;

SELECT _ID, email, date_entered, DATE_FORMAT(date_entered, '%b %e, %Y') AS 'date_entered_formatted'
FROM _subscribers
WHERE send_state = 'Send'
AND status = 'Confirmed'
LIMIT v_limit
FOR UPDATE;

[[UPDATE _subscribers SET send_state = 'Sending' WHERE _ID IN (...?)]]

[[OR]]

[[Loop through the resultset and update each row?]]
COMMIT;

END

```

Seems like a single UPDATE is going to be more efficient; what is the best way to turn the `_ID` column of the resultset into a comma-delimited list for the `IN()` clause? (I've been doing this client-side before this) -- or is there a better way altogether?