QPrincess

Как вариант у каждого файла вычислить хеш md5

Да, притом, и на клиенте и на сервере.
На сервере - для тех, что уже на сервере.
На клиенте - для загружаемого файла (через JS в браузере перед отправкой), чтобы не грузить уже имеющийся на сервере и сразу отправить только хеш для получения результата: качать или уже такой есть.

Чтобы ускорить процесс - можно вначале собрать дирлист с размерами файлов и объединить одинаковые размеры в кластеры. И уже в них - выявлять: одинаковые там файлы или нет.
Кластеры - можно сохранить и обновлять в БД.
Чтобы быстрее было по размеру искать нужные файлы (не по хешу!).
Вариантов оптимизации - много и зависит от задачи.

Если отвечать на вопрос, который вынесен в заголовок, то это возможно только в mysql 8, при блокировке с использованием опции SKIP LOCKED.

Если же версия другая (и если решать проблему, которая стоит перед автором), то возможны варианты.

Например добавить третий статус, "обработка".
То есть скрипт выбирает строку, ставит статус 3, завершает обработку, и потом стиавит 2.
Только в этом случае будут иметь смысл блокировки, хотя я все равно не очень вижу, что тут блокировать, кроме всей таблицы целиком, а это как бы не замедлило весь процесс еще больше. В общем, все зависит от времени, которое требуется на обработку строки.
Если обработка быстрая, то пусть выполняют работу повторно.
Если долгая, то лочить строки со статусом 2 на чтение, выбирать строку, сразу ставить ей статус 3, анлочить все строки, обрабатывать полученную, ставить статус 2.
Плюс добавить еще поле время смены статуса и периодически собирать зависшие в 3 статусе

Более жизненный вариант (опять же, для решения проблемы, а не вопроса) - это каждый воркер работает со своим блоком данных . например, один выбирает только id, которые кончаются на 1, второй - на 2 - и так далее. можно придумать более-менее равномерный алгоритм, чтобы воркеры не мешали друг другу, на тех же принципах, на которых делается шардирование.

Ну а самый простой и надёжный - это ставить строке уникальный идентификатор, UUID вполне подойдет.
Тогда вместо селект+апдейт можно делать сразу апдейт (с условием, которое раньше шло в селект)

update table set guid = {$UUID} where ... limit 1;
... много кода ...
update table set .... guid = null where guid = {$UUID};