Using SELECT...FOR UPDATE, then updating multiple rows - mysql

Question

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?

Answer 1

Instead of trying to create a comma-delimited list, just do an UPDATE with the same criteria as the SELECT
START TRANSACTION;
UPDATE _subscribers
SET send_state = 'Sending'
WHERE send_state = 'Send'
AND status = 'Confirmed'
ORDER BY <something>
LIMIT v_limit;
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'
ORDER BY <something>
LIMIT v_limit;
COMMIT;
The ORDER BY clause is necessary to ensure that both queries process the same rows; if you use LIMIT without ORDER BY, they could select a different subset of rows.

Answer 2

Thanks to Barmar, I took a different tack in the stored procedure:
SET #IDs := null;
UPDATE _subscribers
SET send_state = 'Sending'
WHERE send_state = 'Send'
AND status = 'Confirmed'
AND (SELECT #IDs := CONCAT_WS(',', _ID, #IDs) )
LIMIT v_limit;
SELECT CONVERT(#IDs USING utf8);
As Barmar suggested, it does an UPDATE but also concatenates the IDs of the rows being updated into a variable. Just SELECT that variable, and it gives you a comma-delimited list that can be passed into a PREPARE statement. (I had to use CONVERT because SELECTing the variable was returning a binary/blob value). So...this does not use SELECT...FOR UPDATE as I was originally intending, but it does ensure that the different clients won't be working with the same rows.