Чи оновлення рядка з тим самим значенням насправді оновлює рядок?

У мене є питання щодо продуктивності. Скажімо, у мене є користувач з прізвищем Майкл. Візьміть наступний запит:

UPDATE users
SET first_name = 'Michael'
WHERE users.id = 123

Чи справді запит виконає оновлення, навіть якщо воно оновлюється до однакового значення? Якщо так, то як я можу запобігти цьому?

Завдяки моделі MVCC Postgres і відповідно до правил SQL, a UPDATEпише нову версію рядків для кожного рядка, яка не виключається в WHEREпункті.

Це робить мають більш-менш істотний вплив на продуктивність, прямо і побічно. "Порожні оновлення" мають таку саму ціну за рядок, як і будь-яке інше оновлення. Вони спрацьовують триггерами (якщо вони є), як і будь-яке інше оновлення, вони мають бути зафіксованими WAL, і вони створюють мертві рядки, що роздувають таблицю і створюють більше роботи для VACUUMподальшого, як і будь-яке інше оновлення.

Записи індексів та стовпців TOASTed, де жоден із залучених стовпців не змінено, можуть залишатися однаковими, але це справедливо для будь-якого оновленого рядка. Пов'язані:

• Початковий розмір бази даних PostgreSQL
• Надлишки даних у операторах оновлення

Майже завжди добре виключати такі порожні оновлення (коли є фактичний шанс, що це може статися). Ви не вказали визначення таблиці у своєму запитанні (що завжди гарна ідея). Ми повинні припустити, що це first_nameможе бути NULL (що не буде дивно для "імені"), тому запит повинен використовувати порівняння, безпечне для NULL :

UPDATE users
SET    first_name = 'Michael'
WHERE  id = 123
AND   first_name IS DISTINCT FROM 'Michael';

Якщо first_name IS NULLперед оновленням, тест з just first_name <> 'Michael'би оцінив NULL і виключив рядок із оновлення. Хитра помилка. Якщо стовпець визначенийNOT NULL , використовуйте просту перевірку рівності, оскільки це трохи дешевше.

Пов'язані:

• Як я можу (або можу) ВИБІР ВІДПОВІДЬ у кількох стовпцях?
• Стовпчик оновлення SQL з даними з іншої таблиці

ORM, як пропозиція Ruby on Rail, відкладає виконання, яке позначає запис як змінений (або ні), а потім, коли це потрібно або викликається, потім подає зміни в базу даних.

PostgreSQL - це база даних, а не ORM. Це знизило б ефективність, якби знадобився час, щоб перевірити, чи нове значення збігається з оновленим значенням у вашому запиті.

Тому воно оновить значення незалежно від того, є воно таким же, як нове значення чи ні.

Якщо ви хочете запобігти цьому, ви можете використовувати код, як Макс Вернон, запропонований у своїй відповіді.

Ви можете просто додати до whereпункту:

UPDATE users
SET first_name = 'Michael'
WHERE users.id = 123
    AND (first_name <> 'Michael' OR first_name IS NULL);

Якщо first_nameвизначено якNOT NULL , OR first_name IS NULLдеталь можна видалити.

Умова:

(first_name <> 'Michael' OR first_name IS NULL)

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

first_name IS DISTINCT FROM 'Michael'

З точки зору бази даних

Відповідь на ваше запитання ТАК. Оновлення відбудеться. База даних не перевіряє попереднє значення, вона лише встановлює нове значення.

Оскільки це відбувається в пам'яті (і буде записано у файли даних лише після видачі комісії), продуктивність не буде проблемою.

З точки зору ORM

Зазвичай у вас буде Об'єкт, що представляє один рядок бази даних (це може бути набагато складніше, ніж це, але давайте будемо простою). Цим об'єктом керується пам'ять (на рівні сервера додатків), і лише остання зафіксована версія цього об’єкта фактично перенесе його до бази даних у певний момент.

Це може пояснити різну поведінку.

Тепер не будемо порівнювати вантажне судно з 3D-принтером. Те, що ви можете надсилати 3D-принтери за допомогою вантажних суден, не означає, що між ними може бути якесь порівняння.

Насолоджуйтесь!

Я сподіваюся, що це прояснило деякі концепції.