Liệu việc cập nhật một hàng có cùng giá trị có thực sự cập nhật hàng không?

Tôi có một câu hỏi liên quan đến hiệu suất. Hãy nói rằng tôi có một người dùng với tên Michael. Thực hiện truy vấn sau:

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

Liệu truy vấn có thực sự thực hiện cập nhật hay không, mặc dù nó đang được cập nhật về cùng một giá trị? Nếu vậy, làm thế nào để tôi ngăn chặn nó xảy ra?

Do mô hình MVCC của Postgres và theo quy tắc của SQL, một UPDATEphiên bản hàng mới viết cho mỗi hàng không được loại trừ trong WHEREmệnh đề.

Điều này có tác động ít nhiều đến hiệu suất, trực tiếp và gián tiếp. "Cập nhật trống" có cùng chi phí cho mỗi hàng như mọi bản cập nhật khác. Chúng kích hoạt kích hoạt (nếu có) như bất kỳ bản cập nhật nào khác, chúng phải được ghi nhật ký WAL và chúng tạo ra các hàng chết làm đầy bảng và gây ra nhiều công việc hơn cho VACUUMsau này như bất kỳ bản cập nhật nào khác.

Các mục chỉ mục và các cột TOASTed trong đó không có cột nào liên quan được thay đổi có thể giữ nguyên, nhưng điều đó đúng với bất kỳ hàng cập nhật nào. Liên quan:

• Kích thước cơ sở dữ liệu ban đầu của PostgreSQL
• Dữ liệu dư thừa trong báo cáo cập nhật

Hầu như luôn luôn là một ý tưởng tốt để loại trừ các cập nhật trống như vậy (khi có cơ hội thực tế nó có thể xảy ra). Bạn đã không cung cấp một định nghĩa bảng trong câu hỏi của bạn (luôn luôn là một ý tưởng tốt). Chúng ta phải giả sử first_namecó thể là NULL (điều này sẽ không gây ngạc nhiên cho "tên gọi"), do đó truy vấn phải sử dụng so sánh NULL an toàn :

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

Nếu first_name IS NULLtrước khi cập nhật, một bài kiểm tra chỉ first_name <> 'Michael'đánh giá NULL và như vậy sẽ loại trừ hàng khỏi bản cập nhật. Lỗi lén lút. Tuy nhiên, nếu cột được xác địnhNOT NULL , hãy sử dụng kiểm tra đẳng thức đơn giản, vì nó rẻ hơn một chút.

Liên quan:

• Làm cách nào để tôi (hoặc tôi có thể) CHỌN DISTINCT trên nhiều cột?
• Cột Cập nhật SQL với dữ liệu từ một bảng khác

ORM giống như đề nghị hoãn lại của Ruby on Rail, đánh dấu một bản ghi là đã thay đổi (hoặc không) và sau đó khi cần hoặc được gọi, sau đó gửi thay đổi tới cơ sở dữ liệu.

PostgreSQL là một cơ sở dữ liệu chứ không phải ORM. Nó sẽ giảm hiệu suất nếu mất thời gian để kiểm tra xem giá trị mới có giống với giá trị được cập nhật trong truy vấn của bạn không.

Do đó, nó sẽ cập nhật giá trị bất kể nó có giống với giá trị mới hay không.

Nếu bạn muốn ngăn chặn điều này, bạn có thể sử dụng mã như Max Vernon đề xuất trong câu trả lời của anh ấy.

Bạn chỉ có thể thêm vào wheremệnh đề:

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

Nếu first_nameđược định nghĩa là NOT NULL, OR first_name IS NULLphần có thể được gỡ bỏ.

Điều kiện:

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

cũng có thể được viết thanh lịch hơn như (trong câu trả lời của Erwin):

first_name IS DISTINCT FROM 'Michael'

Từ quan điểm cơ sở dữ liệu

Câu trả lời cho câu hỏi của bạn là có. Việc cập nhật sẽ diễn ra. Cơ sở dữ liệu không kiểm tra giá trị trước đó, nó chỉ đặt giá trị mới.

Vì điều này xảy ra trong bộ nhớ (và sẽ chỉ được ghi vào các tệp dữ liệu sau khi cam kết được ban hành), hiệu suất sẽ không thành vấn đề.

Từ góc độ ORM

Thông thường bạn sẽ có một Object đại diện cho một hàng cơ sở dữ liệu (nó có thể phức tạp hơn thế nhiều, nhưng hãy giữ cho nó đơn giản). Đối tượng này được quản lý trong bộ nhớ (ở cấp máy chủ ứng dụng) và chỉ phiên bản được cam kết mới nhất của đối tượng đó mới thực sự đưa nó vào cơ sở dữ liệu tại một điểm nhất định.

Điều đó có thể giải thích các hành vi khác nhau.

Bây giờ, chúng ta đừng so sánh một con tàu chở hàng với máy in 3D. Việc bạn có thể gửi máy in 3D bằng tàu chở hàng không có nghĩa là có thể có bất kỳ loại so sánh nào giữa chúng.

Thưởng thức!

Tôi hy vọng điều này làm rõ một số khái niệm.