Have several rows, or one single row with a huge comma separated data? I have many workers processes working at the same time. They grab an ID from a list called available_ids, work on that ID, and put that ID on a list, called used_ids. 

The list available_ids can have the same ID several times, so when a worker pulls an ID from it, it has to check if that ID is already in used_ids. If it is, it skips that ID as there's no need to work on it anymore.

This is all file based, and I'd like to transfer the lists over to a mysql database.

My question is, should I have one table called used_ids, and add each used ID to it as rows (one ID per row), or should I have one single row, with all my IDs, comma separated?

There are thousands of IDs. My fear is, since my workers have to check every single ID before doing their task, by running through sereval rows, wouldn't there be a big overhead, slowing down everything?

Thank you.
Use 1 row per ID, add an index on the ID. SQL is pretty good about finding a single value in a table, even if there are millions of rows. If you run periodic cleanup to wipe the old ID values out (like maybe have an automatic timestamp column and then have a job to drop all values older than X days), you wont run into any performance issues.

To give you an idea, in the production environment I work with, we have a similar table, about 40 columns wide, with some instances having >50 billion records, and pulling a single record out, queried by its unique, indexed ID, takes around 0.5s. Its very good hardware but its still pretty performant.