MERGE có sử dụng tempdb không?

12

Hãy xem xét các truy vấn sau:

MERGE [Parameter] with (rowlock) AS target
    USING (SELECT @AreaId, @ParameterTypeId, @Value)
            AS source (AreaId, ParameterTypeId, Value)
    ON (target.AreaId = source.AreaId AND 
        target.ParameterTypeId = source.ParameterTypeId)
    WHEN MATCHED THEN 
        UPDATE SET target.Value = source.Value, @UpdatedId = target.Id
    WHEN NOT MATCHED THEN
        INSERT ([AreaId], [ParameterTypeId], [Value])
        VALUES (source.AreaId, source.ParameterTypeId, source.Value);

Thống kê I / O cho đầu ra sau:

Bảng 'ParameterType'. Quét số 0, đọc logic 2, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc trước 0.
Bảng 'Khu vực'. Quét số 0, đọc logic 2, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc trước 0.
Bảng 'Tham số'. Quét số 1, đọc logic 4, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc trước 0.
Bảng 'Worktable'. Quét số 1, đọc logic 0, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc 0, đọc trước 0.

Worktable xuất hiện trong tab tin nhắn khiến tôi nghĩ rằng tempdb đang được sử dụng MERGE.

Tôi không thấy bất cứ điều gì trong kế hoạch Thi hành cho thấy cần phải có tempdb

Có phải MERGEluôn luôn sử dụng tempdb?

Có bất cứ điều gì trong BOL giải thích hành vi này?

Sẽ sử dụng INSERTvà UPDATEđược nhanh hơn trong tình huống này?

Trái

nhập mô tả hình ảnh ở đây

Đúng

nhập mô tả hình ảnh ở đây

Đây là cấu trúc bảng

nhập mô tả hình ảnh ở đây

sql-server t-sql

— Craig Efrein
nguồn

Các ống chỉ trong kế hoạch là một bàn làm việc trong tempdb. Có vẻ kỳ lạ rằng nó là có cho một hàng duy nhất mặc dù. Tôi đoán nó có thể ở đó để bảo vệ Halloween.

— Martin Smith

Tôi thấy nó bây giờ. Lưu trữ dữ liệu từ đầu vào vào một bảng tạm thời để tối ưu hóa tua lại.

— Craig Efrein

8

^{(Mở rộng về nhận xét của tôi về câu hỏi.)}

Nếu không có một ràng buộc duy nhất về sự kết hợp của AreaIdvà ParameterTypeId, mã đã cho sẽ bị hỏng vì @UpdatedId = target.Idsẽ chỉ ghi một hàng duy nhất Id.

Trừ khi bạn nói như vậy, SQL Server không thể ngầm biết các trạng thái có thể có của dữ liệu. Phải ràng buộc ràng buộc hoặc nếu nhiều hàng hợp lệ , mã sẽ cần được thay đổi để sử dụng một cơ chế khác để xuất các Idgiá trị.

Do khả năng toán tử quét sẽ bắt gặp nhiều hàng khớp, truy vấn phải háo hức làm hỏng tất cả các trận đấu để bảo vệ Halloween. Như đã nêu trong các nhận xét, ràng buộc là hợp lệ, do đó, việc thêm nó sẽ không chỉ thay đổi kế hoạch từ quét sang tìm kiếm mà còn loại bỏ sự cần thiết của bộ đệm bảng, vì SQL Server sẽ biết sẽ có 0 hoặc 1 hàng trả về từ toán tử tìm kiếm.

— Jon Seigel
nguồn

6

Nếu bản cập nhật có thể thay đổi vị trí của hàng trong chỉ mục được quét bởi bản cập nhật, SQL Server cần bảo vệ khỏi Sự cố Halloween . Vì vậy, SQL Server thường chèn một bộ đệm bảng háo hức vào kế hoạch thực hiện ngay sau khi quét chỉ mục. Toán tử đó về cơ bản tạo ra một bản sao của các hàng trong câu hỏi và nó sử dụng tempdb cho điều đó.

Phần cập nhật của câu lệnh MERGE phải tuân theo các quy tắc tương tự và cũng sử dụng bộ đệm bảng trong hầu hết các trường hợp bắt buộc phải có Bảo vệ Halloween.

Mặc dù tôi không thể biết liệu đây có phải là trường hợp trong truy vấn của bạn hay không, vì tôi không biết (các) định nghĩa chỉ mục, đây rất có thể là những gì đang xảy ra ở đây.

— Sebastian Meine
nguồn