Tốc độ nào nhanh hơn, EXISTS trước hoặc sau INSERT?

Question

Tôi có một SP trong SQL Server chạy hàng trăm lần mỗi phút và cần kiểm tra lưu lượng truy cập đến dựa vào cơ sở dữ liệu. Tại thời điểm này nó như sau

INSERT INTO table 
SELECT @value1,@value2 WHERE NOT EXISTS 
(SELECT * FROM table WHERE value1 = @value1 AND value2 = @value2); 

Tuy nhiên, tôi cũng có thể đi với

IF NOT EXISTS(SELECT * FROM table WHERE value1 = @value1 AND value2 = @value2)  
    INSERT INTO table (value1,value2) VALUES (@value1,@value2); 

Đó sẽ là nhanh hơn? Tôi có cảm giác không có nhiều khác biệt giữa họ nhưng tôi về mặt lịch sử không giỏi về TSQL ... =/

CẬP NHẬT: Rất tiếc ... có nghĩa là nói rằng EXISTS sử dụng nhiều hơn 1 giá trị để tìm xem bản ghi tồn tại, do đó, một ràng buộc duy nhất sẽ không hoạt động. Đã chỉnh sửa mẫu để phản ánh điều đó ...

Answer 1

Sau khi thêm một bình luận gazillion về câu hỏi này và câu trả lời của nó, tôi sẽ có của riêng tôi đi trên trả lời nó.

Tôi sẽ không mong đợi bất kỳ sự khác biệt lớn nào về hiệu suất giữa hai đề xuất được đề xuất trong câu hỏi gốc. Một mặt, như được chỉ ra bởi Ray, cách tiếp cận thứ hai có thể giúp bạn tiết kiệm một số chuẩn bị cho việc chèn, nhưng mặt khác, một RDBMS thường hoạt động tốt nhất với các lệnh lô, như trong giải pháp đầu tiên.

KM và DVK đề xuất thêm ràng buộc UNIQUE, điều này sẽ làm cho thử nghiệm độc đáo tiềm ẩn, nhưng sẽ yêu cầu bạn thêm một số loại xử lý lỗi xung quanh tuyên bố INSERT của bạn. Tôi có một thời gian khó khăn phát hiện tại sao điều này nên thêm bất kỳ hiệu suất bổ sung, giả định rằng bạn đã có một chỉ số bao gồm hai cột. Nếu bạn không có chỉ mục như vậy, hãy thêm nó và xem xét lại nhu cầu của bạn để có hiệu suất cao hơn.

Cho dù kiểm tra tính duy nhất được thực hiện rõ ràng hay ngầm thì không quan trọng AFAIK.Nếu bất cứ điều gì đạt được bằng việc kiểm tra được thực hiện "bên trong" dạ dày của DBMS, mà đạt được chỉ có thể được ăn lên bởi chi phí liên quan đến nâng cao và xử lý lỗi khi trùng lặp tồn tại.

---

Điểm mấu chốt: Giả sử một chỉ mục đã có sẵn, nếu bạn vẫn thấy mình thực hiện yêu cầu, đề xuất của tôi là bạn thực hiện các thử nghiệm thực nghiệm về ba giải pháp được đề xuất. Nấu một chương trình nhỏ mô phỏng dữ liệu đầu vào mong đợi và thổi từng giải pháp trong số ba giải pháp đi với vài tỷ hàng, bao gồm số lượng trùng lặp hợp lý. làm điều này, đảm bảo đăng kết quả của bạn :-)

Answer 2

Nếu bạn muốn các giá trị là duy nhất, tại sao không chỉ tạo một ràng buộc duy nhất trên giá trị, thực hiện INSERT mà không chọn SELECT và xử lý lỗi vi phạm ràng buộc một cách duyên dáng?

Điều đó sẽ nhanh hơn một trong các cách tiếp cận này.

Ngoài ra, cách tiếp cận đầu tiên của bạn không hoạt động - vào lúc bạn chọn, bạn đã chèn giá trị để chọn rõ ràng sẽ tìm thấy những gì bạn vừa chèn vào.

Answer 3

Nếu tôi phải đoán, tôi đoán tùy chọn thứ hai sẽ nhanh hơn. Máy chủ sql sẽ không phải thực hiện bất kỳ loại thiết lập nào để chèn nếu tồn tại không thành công, trong khi ở đầu tiên, nó có thể tra cứu một số tên bảng và trường và chuẩn bị cho một chèn không bao giờ xảy ra. Tuy nhiên, tôi sẽ thử nó trong bộ phân tích truy vấn và xem những gì kế hoạch nói.

Answer 4

chỉ làm điều đó, và bỏ qua bất kỳ lỗi (giả định một hạn chế duy nhất trên giá trị gia tăng) ...

BEGIN TRY 
    INSERT INTO Table (value) VALUES (@value); 
END TRY 
BEGIN CATCH 
    PRINT 'it was already in there!' 
END CATCH 

Kể từ này chạy hàng trăm lần một phút, khóa gợi ý nên được thêm vào các lựa chọn và một giao dịch để avoid a race condition

(SELECT * FROM Table WITH (UPDLOCK, HOLDLOCK) WHERE value = @value); 

Tuy nhiên, ý tưởng đề xuất của tôi chỉ INSERT và bỏ qua bất kỳ lỗi khó khăn trùng lặp sẽ tránh được tình trạng chủng tộc là tốt.

Answer 5

Trong môi trường hầu như không đồng thời, INSERT đồng thời có thể xảy ra ở giữa IF NOT EXISTS và INSERT trong truy vấn thứ hai của bạn.

Truy vấn đầu tiên của bạn sẽ đặt khóa chia sẻ trên bản ghi mà nó kiểm tra, sẽ không được dỡ bỏ cho đến khi kết thúc truy vấn, vì vậy sẽ không thể chèn bản ghi mới cho đến khi truy vấn đang chạy.

Tuy nhiên, bạn không nên chỉ dựa vào hành vi này. Đặt thêm UNIQUE ràng buộc trên value.

Nó sẽ không chỉ làm cho cơ sở dữ liệu phù hợp hơn, nhưng sẽ tạo ra một chỉ mục mà sẽ làm cho truy vấn đầu tiên nhanh hơn.

Answer 6

Cả hai biến thể đều không chính xác. Bạn sẽ chèn các cặp trùng lặp @ value1, @ value2, đảm bảo.

Các cách chính xác để xử lý này là để thực thi một hạn chế duy nhất trên hai cột và luôn INSERT và xử lý các vi phạm chế:

ALTER TABLE Table ADD CONSTRAINT uniqueValue1Value UNIQUE (value1, values2); 

và để chèn:

BEGIN TRY 
    INSERT INTO Table (value1, value2) VALUES (@value1, @value2); 
END TRY 
BEGIN CATCH 
    DECLARE @error_number int, @error_message NVARCHAR(4000), @xact_state INT; 
    SET @error_number = ERROR_NUMBER(); 
    SET @error_message = ERROR_MESSAGE(); 
    SET @xact_state = XACT_STATE(); 
    IF (@xact_state = -1) 
    BEGIN 
    ROLLBACK TRANSACTION; 
    END 
    IF (@error_number != 2627) /* 2627 is ' Cannot insert duplicate key in object ...' */ 
    BEGIN 
     RAISERROR(N'Error inserting into Table: %i %s', 16,1, @errror_number, @error_message); 
    END 
ENd CATCH 

Trong khi những điều này có vẻ phức tạp, người ta phải tính đến một chi tiết nhỏ có tên là độ chính xác. Điều này đơn giản hơn rất nhiều khi so sánh với một giải pháp dựa trên gợi ý khóa. Đây cũng là giải pháp hiệu quả nhất: chỉ có một người tìm kiếm. Tất cả các giải pháp khác cần ít nhất hai tìm kiếm (một để xác nhận rằng nó có thể được chèn vào, một để chèn).