Оптимизируется ли UPDATE, если значения полей на самом деле не меняются?

Question

[Евгений Обыкновенный]

Например, пусть на самом деле изменяется значение только value2, а остальные значения такие же, какие сейчас в базе. Будет ли разница между следующими двумя запросами?

UPDATE table_name
SET column1 = value1, column2 = value2,  column3 = value3
WHERE condition;

UPDATE table_name
SET column2 = value2
WHERE condition;

Иногда лень отслеживать, какие из полей объекта на самом деле обновились, а какие нет, и учитывать это при формировании запроса к БД. Но наверняка обновление дорогостоящее, особенно для полнотекстовых индексов.

Answer 1

[Melkij]

В postgresql создаётся физически новая версия строки при update (с обновлением всех индексов либо hot update если применимо) даже если ни одно поле не меняет своё действительное значение. Есть встроенный триггер suppress_redundant_updates_trigger, который можно повесить на таблицу, тогда ничего действительно не меняющий в данных update будет пропускаться.

Если меняется хотя бы одно значение - оптимизации не подлежит, должна быть записана новая версия строки в таблицу (чтобы MVCC обеспечить). Если возможно, оптимизация HOT update исключит сопутствующее обновление индексов.

Comments

[Евгений Обыкновенный]

А как MySQL с этим?

[Melkij]

по mysql на этот вопрос компетентно ответить не могу

[Владимир]

Евгений Обыкновенный, в MySQL до 8й версии (и в MariaDB) UPDATE ничего не меняет, если значения полей те же самые. В 8й скорее всего то же самое, но я с ней не работал, не поручусь.

[Melkij]

Владимир, а если меняется значение, но только одного поля - в UNDO едет копия всей строки или только изменившиеся колонки?

[Владимир]

Melkij, вот этого я, к сожалению, не знаю - информации об этом мне не попадалась. Но логично предположить, что раз MySQL определяет поля, которые не меняются и запросы, которые не меняют ничего, то в UNDO-лог едут только изменившиеся поля.

[Melkij]

Владимир, зато это могут быть совершенно разные куски кода, если условие "не изменилось ничего" проверяет ядро самого mysql, а не передаёт коду storage engine. Могли решить не менять api storage engine лишний раз ради проброса списка изменённых полей вдобавок к самому таплу ради такой оптимизации.

[Владимир]

Melkij, MySQL проверяет каждое поле, и если оно не меняется, то это поле в запросе игнорируется. На всякий случай повторюсь - с 8й версией я не работал, но в предыдущих - именно так.

[Melkij]

Владимир, я вот про это handler::update_row в api передаются только данные старого тапла и нового, если storage engine хочет, то может сверять данные самостоятельно, что изменилось в полях. Но ядро эту информацию не передаёт в явном виде. Но я плохо знаю internals mysql, внутрянка postgresql как-то ближе. Может ядро mysql и вовсе само не проверяет, что изменилось в данных, а делают это всегда сами storage engine и, соответственно, это может быть реализовано не во всех.

[Владимир]

Melkij, к сожалению, больше того, что есть в документации, я не подскажу, тем более читал я ее достаточно давно :/