SQLServer thử hiệu suất bắt

Question

Có ai đã tìm thấy bất kỳ tăng/giảm hiệu suất nào khi sử dụng BEGIN TRY..END TRY trong máy chủ sql 2008, so với IF @ @ ERROR <> 0 cũ không? Chỉ cần tò mò để biết nếu có hình phạt hiệu suất hay không.

Answer 1

Đây là một câu hỏi cũ, nhưng trong năm 2012 Aaron Bertrand đã viết một bài viết chi tiết Performance impact of different error handling techniques nơi ông so vài phương pháp để đối phó với trường hợp ngoại lệ trong SQL Server và tôi nghĩ rằng nó là đáng nói đến nó ở đây.

Ông nói, rằng chính cách tiếp cận người sử dụng để đối phó với trường hợp ngoại lệ là:

• Chỉ cần cho động cơ xử lý nó, và bong bóng bất kỳ ngoại lệ lại cho người gọi.
• Sử dụng BEGIN TRANSACTION và ROLLBACK nếu @@ERROR <> 0.
• Sử dụng TRY/CATCH với ROLLBACK trong khối CATCH (SQL Server 2005+).

Và nhiều mất phương pháp mà họ nên kiểm tra xem họ sẽ chịu vi phạm lần đầu, vì nó có vẻ sạch hơn để xử lý các lặp lại chính mình hơn để buộc các động cơ để làm điều đó.

kết luận của ông là:

Nếu chúng ta nghĩ chúng ta sẽ có một tỷ lệ cao của thất bại, hoặc không có ý tưởng những gì tỷ lệ thất bại tiềm năng của chúng tôi sẽ được, sau đó kiểm tra đầu tiên tránh vi phạm trong động cơ sẽ có giá trị rất lớn trong số của chúng tôi trong khi. Ngay cả trong trường hợp chúng tôi đã chèn thành công mỗi lần, chi phí kiểm tra đầu tiên là biên và dễ dàng được chứng minh bằng chi phí xử lý lỗi sau này (trừ khi tỷ lệ lỗi dự kiến ​​làkhông chính xác là 0%).

Đây là bảng xếp hạng từ bài viết:

CheckInsert | Checks `IF EXISTS` first | Simple `INSERT` 
CheckRollback | Checks `IF EXISTS` first | Use `IF @@ERROR <> 0` 
CheckTryCatch | Checks `IF EXISTS` first | Use `TRY CATCH` 
JustInsert  |       | Simple `INSERT` 
JustRollback |       | Use `IF @@ERROR <> 0` 
JustTryCatch |       | Use `TRY CATCH` 

Answer 2

Kể từ SQL 2005, bạn nên cố gắng sử dụng cách TRY CATCH để xử lý các ngoại lệ hoặc ghi nhật ký lỗi. Nó được coi là thực hành tốt nhất. Không nên có hiệu suất lớn hit bằng cách sử dụng nó.

BEGIN TRY 
    BEGIN TRANSACTION 
    -- SQL 
    COMMIT TRANSACTION 
END TRY 
BEGIN CATCH 
    ROLLBACK 
    SELECT 
     ERROR_MESSAGE(), 
     ERROR_NUMBER() -- etc 
END CATCH 

Answer 3

Vì các vấn đề về đĩa cơ sở dữ liệu là giống hệt nhau, nên không có vấn đề về hiệu suất đáng kể.

Answer 4

Quên hiệu suất, đó là một cảnh chết tiệt an toàn hơn, tốt hơn và dễ hiểu hơn.

Tuy nhiên, việc sử dụng @@ ERROR thường yêu cầu GOTO và/hoặc nhiều câu lệnh IF để quản lý chính xác vì vậy tôi đoán có thể có một sự gia tăng nhỏ trong TRY..CATCH.

Answer 5

Hiệu suất của TRY ... CATCH có nhiều khả năng hơn một chút khi không có lỗi. Mặt khác, nó sẽ nhanh hơn trong nhiều trường hợp khi có lỗi.

Tuy nhiên, bạn không nên mã nghiêm ngặt cho hiệu suất. Và, chi phí, nếu có, sẽ khá nhỏ, vì vậy tôi sẽ không trao đổi cú pháp an toàn hơn cho hiệu năng trong trường hợp này. Ngoài ra, việc thử ... Catch làm cho mã dễ dàng hơn một chút để duy trì, đặc biệt là nếu nhóm dev SQL của bạn đã không được xung quanh SQL Server rất dài, mà không may, xảy ra một chút quá thường xuyên. Các tính năng chính: Tôi tưởng tượng điều này sẽ được nhiều hơn các trường hợp một vài năm kể từ bây giờ.

Answer 6

• Speed Test: Try/Catch Block
• Do try...catch blocks hurt runtime performance?