Я столкнулся с проблемой в MySQL 8.0x с SKIP LOCKED.
Таблица выглядит примерно так (слишком упрощенно)
Table users as U {
id int [pk, increment] // auto-increment
transaction_id int
full_name varchar
status int
created_at timestamp
country_code int
important varchar
}
Там много строк и несколько потоков пишут одновременно в таблицу.
Изначально я выбираю строку для обновления
SELECT * FROM Table, ГДЕ СОСТОЯНИЕ = 0 И ВАЖНО = " QgBv0kidCvg "AND country_code = 17200 AND TRANSACTION_ID <0 ORDER BY ID LIMIT 1 НА ОБНОВЛЕНИЕ <strong>Пропуск заблокирован
Затем с помощью оператора обновления я резервирую строку с временным кодом состояния, поэтому, если другой поток имеет те же параметры запроса, теперь строки будут возвращены во второй поток.
ОБНОВЛЕНИЕ Таблица УСТАНОВИТЬ СОСТОЯНИЕ = 3 ГДЕ ID = 4695
Код выполняет несколько интегрирований здесь и там и в конце, после того, как резервирование в порядке. Я
завершение значения состояния до 1
ОБНОВЛЕНИЕ таблицы SET SET STATUS = 1, TRANSACTION_ID = 2312313 WHERE ID = 4695
Так что это сценарий резервирования, где приходит запрос, чтобы проверить, существует ли свободная «важная», резервирует ее на некоторое время, изменяя статус на 3 (временное состояние), и после того, как пиры обновляются, мы помечаем строку как status = 1, что означает, что она зарезервирована.
Моя проблема здесь в том, что инструкция SKIP LOCKED возвращает NO ROWS, что означает, что строки не были найдены свободными. Нет шансов, что два параллельных потока будут запрашивать какой-либо ряд. Я проверял это несколько раз.
Что меня здесь беспокоит, так это то, что , если я удаляю SKIP LOCKED в конце оператора select for update, все работает как положено.