Поскольку вы не хотите использовать решение Dems из предыдущего вопроса, вот «решение» с JOIN:
UPDATE myTable m
JOIN myTable n
ON m.SensorID = n.SensorID
AND n.RawData <> 65535
AND m.TimestampMS < n.TimestampMS
JOIN myTable q
ON n.SensorID = q.SensorID
AND q.RawData <> 65535
AND n.TimestampMS <= q.TimestampMS
SET
m.RawData = n.RawData,
m.Data = n.Data
WHERE
m.RawData = 65535
;
EDIT
Мой запрос выше неправильный, совершенно неверный. Кажется, он работает в моем тестовом БД, но логика ошибочна. Я объясню ниже.
Почему вышеупомянутый запрос работает нормально, но совершенно неверно:
Во-первых, почему это не так.
Потому что он не будет возвращать одну строку для каждой комбинации (sensorID, неверная метка времени), но много строк. Если m
(m.TimestampMS
) - это неправильная временная метка, которую мы хотим найти, она вернет все комбинации этой неправильной временной метки и более поздних хороших временных меток n
и q
с n.TimestampMS <= q.TimestampMS
. Это был бы правильный запрос, если бы он нашел МИНИМУМ этих n
отметок времени.
Теперь, как же это на самом деле работает нормально в моем тестовом БД?
Я думаю, это потому, что MySQL, когда он использует SET ...
и имеет много опций (строк), просто использует первый вариант. Но, к счастью, я добавил тестовые строки в порядке возрастания меток времени, чтобы они были сохранены в том же порядке в БД, и (опять же, к счастью для меня, именно так запланирован план запроса (я полагаю).
Даже этот запрос работает в моей тестовой базе данных:
UPDATE myTable m
JOIN myTable n
ON m.SensorID = n.SensorID
AND n.RawData <> 65535
AND m.TimestampMS < n.TimestampMS
SET
m.RawData = n.RawData,
m.Data = n.Data
WHERE
m.RawData = 65535
;
будучи ошибочным по тем же причинам.