Моя SQL инструкция может быть упрощена до чего-то похожего следующим образом:
INSERT INTO `TABLE1` (RUNNING_NO, A, B)
(SELECT RUN_ID, C, D FROM `TABLE2` WHERE ...)
ON DUPLICATE KEY UPDATE
RUNNING_NO = IF(RUNNING_NO > RUN_ID, RUNNING_NO, RUN_ID)
, A = IF(RUNNING_NO > RUN_ID, A, C)
, B = IF(RUNNING_NO > RUN_ID, B, D);
, где я хочу заменить строку, только если RUN_ID из TABLE2 больше, чем в TABLE1. У меня будет несколько сеансов с разными условиями WHERE, которые будут выполнять этот оператор одновременно, и они могут возвращать одинаковые значения C с разными RUN_ID.
Первичный ключ TABLE1 - это A, а в TABLE2 первичный ключ - RUN_ID + C.
Я использую движок InnoDB.
Блокирует ли база данных идентификатор RUNNING_ID, который был проверен на самое последнее значение записи (я боюсь, что значение было обновлено другим сеансом, который был с более высоким RUN_ID, чем исходный в TABLE1, а также текущий RUN_ID из TABLE2)? Если да, то есть ли какой-нибудь источник документов, в котором это упоминалось?
------------------------- [Отредактировано - пример данных ]
TABLE1
RUNNING_ID | A | B
10 AA Apple
TABLE2
RUN_ID | C | D
11 ....
20 AA Orange
21 ....
30 AA Melon
Два сеанса выполняются
Сессия A приняла записи с 11 до 20, Сессия B приняла записи с 21 до 30, Сессия B сначала завершила выбор вставки (что означает таблица TABLE1 обновлена до 30)
Может ли сеанс А по-прежнему выполнять сравнение с RUNNING_ID 10?