THIẾT LẬP NOCOUNT khi sử dụng

Lấy cảm hứng từ câu hỏi này , nơi có các quan điểm khác nhau về SET NOCOUNT ...

Chúng ta có nên sử dụng SET NOCOUNT ON cho SQL Server không? Nếu không, tai sao không?

Nó làm gì Chỉnh sửa 6, vào ngày 22 tháng 7 năm 2011

Nó chặn thông báo "xx hàng bị ảnh hưởng" sau bất kỳ DML nào. Đây là một tập kết quả và khi được gửi, khách hàng phải xử lý nó. Nó nhỏ, nhưng có thể đo lường được (xem câu trả lời bên dưới)

Đối với các kích hoạt, v.v., khách hàng sẽ nhận được nhiều "hàng xx bị ảnh hưởng" và điều này gây ra tất cả các lỗi cho một số ORM, MS Access, JPA, v.v. (xem các chỉnh sửa bên dưới)

Lý lịch:

Thực tiễn tốt nhất được chấp nhận chung (tôi nghĩ cho đến khi câu hỏi này) là sử dụng SET NOCOUNT ONtrong các trình kích hoạt và các thủ tục được lưu trữ trong SQL Server. Chúng tôi sử dụng nó ở mọi nơi và google nhanh chóng cho thấy rất nhiều MVP của SQL Server cũng đồng ý.

MSDN cho biết điều này có thể phá vỡ một SQLDataAd CHƯƠNG .net .

Bây giờ, điều này có nghĩa với tôi rằng SQLDataAd CHƯƠNG bị giới hạn trong việc xử lý CRUD hoàn toàn đơn giản vì nó hy vọng thông điệp "n hàng bị ảnh hưởng" khớp. Vì vậy, tôi không thể sử dụng:

• NẾU EXISTS để tránh trùng lặp (không có thông báo ảnh hưởng đến hàng) Lưu ý: sử dụng thận trọng
• Ở ĐÂU KHÔNG EXISTS (ít hàng hơn dự kiến
• Lọc ra các cập nhật nhỏ (ví dụ: không có dữ liệu thực sự thay đổi)
• Thực hiện bất kỳ truy cập bảng trước (chẳng hạn như đăng nhập)
• Ẩn sự phức tạp hoặc biến dạng
• Vân vân

Trong câu hỏi marc_s (người biết công cụ SQL của anh ta) nói không sử dụng nó. Điều này khác với những gì tôi nghĩ (và tôi cũng tự coi mình là người có năng lực ở SQL).

Có thể tôi đang thiếu một cái gì đó (cứ thoải mái chỉ ra điều hiển nhiên), nhưng bạn nghĩ sao?

Lưu ý: đã nhiều năm kể từ khi tôi gặp lỗi này vì hiện tại tôi không sử dụng SQLDataAd CHƯƠNG.

Chỉnh sửa sau khi nhận xét và câu hỏi:

Chỉnh sửa: Thêm suy nghĩ ...

Chúng tôi có nhiều khách hàng: một người có thể sử dụng C # SQLDataAdaptor, một người khác có thể sử dụng nHibernate từ Java. Đây có thể bị ảnh hưởng theo những cách khác nhau với SET NOCOUNT ON.

Nếu bạn coi các procs được lưu trữ như các phương thức, thì đó là hình thức xấu (chống mẫu) để cho rằng một số xử lý nội bộ hoạt động theo một cách nhất định cho mục đích riêng của bạn.

Chỉnh sửa 2: kích hoạt phá vỡ câu hỏi nHibernate , nơi SET NOCOUNT ONkhông thể được đặt

(và không, nó không phải là một bản sao của điều này )

Chỉnh sửa 3: Thông tin thêm, nhờ đồng nghiệp MVP của tôi

• KB 240882 , sự cố gây mất kết nối trên SQL 2000 trở về trước
• Bản trình diễn tăng hiệu suất

Chỉnh sửa 4: 13 tháng 5 năm 2011

Phá vỡ Linq 2 SQL quá khi không được chỉ định?

Chỉnh sửa 5: 14 tháng 6 năm 2011

Phá vỡ JPA, Proc được lưu trữ với các biến bảng: JPA 2.0 có hỗ trợ các biến bảng SQL Server không?

Chỉnh sửa 6: 15 tháng 8 năm 2011

Lưới dữ liệu "Chỉnh sửa hàng" SSMS yêu cầu THIẾT LẬP NOCOUNT: Cập nhật kích hoạt với GROUP BY

Chỉnh sửa 7: 07/03/2013

Thông tin chi tiết chuyên sâu từ @RemusRusanu:
Liệu SET NOCOUNT ON có thực sự tạo ra sự khác biệt lớn về hiệu suất không

Ok bây giờ tôi đã thực hiện nghiên cứu của mình, đây là thỏa thuận:

Trong giao thức TDS, SET NOCOUNT ONchỉ lưu 9 byte cho mỗi truy vấn trong khi văn bản "SET NOCOUNT ON" là một con số khổng lồ 14 byte. Tôi đã từng nghĩ rằng 123 row(s) affectedđã được trả về từ máy chủ ở dạng văn bản đơn giản trong một gói mạng riêng nhưng thực tế không phải vậy. Trên thực tế, đó là một cấu trúc nhỏ được gọi là DONE_IN_PROCnhúng trong phản hồi. Đây không phải là một gói mạng riêng biệt nên không có vòng tròn nào bị lãng phí.

Tôi nghĩ rằng bạn có thể dính vào hành vi đếm mặc định hầu như luôn luôn mà không phải lo lắng về hiệu suất. Tuy nhiên, có một số trường hợp, trong đó việc tính toán số lượng hàng trước sẽ ảnh hưởng đến hiệu suất, chẳng hạn như con trỏ chỉ chuyển tiếp. Trong trường hợp đó, NOCOUNT có thể là một điều cần thiết. Ngoài ra, hoàn toàn không cần phải tuân theo phương châm "sử dụng NOCOUNT bất cứ khi nào có thể".

Dưới đây là một phân tích rất chi tiết về tầm quan trọng của SET NOCOUNTcài đặt: http://daleburnett.com/2014/01/everything-ever-wocate-ledge-set-nocount/

Tôi đã mất rất nhiều công sức để tìm ra số liệu điểm chuẩn thực sự xung quanh NOCOUNT, vì vậy tôi đoán rằng tôi sẽ chia sẻ một bản tóm tắt nhanh chóng.

• Nếu quy trình được lưu trữ của bạn sử dụng một con trỏ để thực hiện nhiều thao tác rất nhanh mà không có kết quả trả về, thì việc NOCOUNT OFF có thể mất khoảng 10 lần miễn là BẬT nó. ¹ Đây là trường hợp xấu nhất.
• Nếu quy trình được lưu trữ của bạn chỉ thực hiện một thao tác nhanh duy nhất mà không có kết quả trả về, đặt NOCOUNT ON có thể mang lại hiệu suất tăng khoảng 3%. ² Điều này sẽ phù hợp với quy trình chèn hoặc cập nhật thông thường. (Xem các bình luận về câu trả lời này để biết một số thảo luận về lý do tại sao điều này có thể không luôn luôn nhanh hơn.)
• Nếu quy trình được lưu trữ của bạn trả về kết quả (nghĩa là bạn CHỌN một cái gì đó), sự khác biệt hiệu suất sẽ giảm tỷ lệ thuận với kích thước của tập kết quả.

• Khi SET NOCOUNT được BẬT, số đếm (cho biết số lượng hàng bị ảnh hưởng bởi câu lệnh Transact-SQL) sẽ không được trả về. Khi SET NOCOUNT TẮT, số lượng được trả về. Nó được sử dụng với bất kỳ câu lệnh CHỌN, CHERTN, CẬP NHẬT, XÓA.

• Cài đặt của SET NOCOUNT được đặt ở thời gian thực thi hoặc chạy và không phải lúc phân tích cú pháp.

• SET NOCOUNT ON cải thiện hiệu suất thủ tục được lưu trữ (SP).

• Cú pháp: THIẾT LẬP NOCOUNT {ON | TẮT }

Ví dụ về THIẾT LẬP NOCOUNT:

Ví dụ về TẮT NOCOUNT:

Tôi đoán ở một mức độ nào đó đó là vấn đề DBA so với nhà phát triển.

Là một nhà phát triển, tôi nói rằng đừng sử dụng nó trừ khi bạn hoàn toàn tích cực phải làm - bởi vì sử dụng nó có thể phá vỡ mã ADO.NET của bạn (như tài liệu của Microsoft).

Và tôi đoán là một DBA, bạn sẽ có nhiều mặt hơn - sử dụng nó bất cứ khi nào có thể trừ khi bạn thực sự phải ngăn chặn việc sử dụng nó.

Ngoài ra, nếu các nhà phát triển của bạn từng sử dụng "RecordsAffected" được trả về bởi ExecuteNonQuerylệnh gọi phương thức của ADO.NET , bạn sẽ gặp rắc rối nếu mọi người sử dụng SET NOCOUNT ONvì trong trường hợp này, ExecuteNonQuery sẽ luôn trả về 0.

Cũng xem bài viết trên blog của Peter Bromberg và kiểm tra vị trí của anh ấy.

Vì vậy, nó thực sự nắm bắt được ai sẽ thiết lập các tiêu chuẩn :-)

Marc

Nếu bạn đang nói rằng bạn cũng có thể có nhiều khách hàng khác nhau, thì có vấn đề với ADO cổ điển nếu SET NOCOUNT không được đặt thành BẬT.

Một điều tôi thường gặp: nếu một thủ tục được lưu trữ thực thi một số câu lệnh (và do đó, một số thông báo "xxx hàng bị ảnh hưởng" được trả về), ADO dường như không xử lý điều này và ném lỗi "Không thể thay đổi thuộc tính ActiveConnection của đối tượng Recordset trong đó có một đối tượng Command là nguồn của nó. "

Vì vậy, tôi thường ủng hộ việc đặt nó BẬT trừ khi không có lý do thực sự tốt. bạn có thể đã tìm thấy lý do thực sự tốt mà tôi cần phải đọc và đọc thêm.

Có nguy cơ làm cho mọi thứ trở nên phức tạp hơn, tôi khuyến khích một quy tắc hơi khác với tất cả những gì tôi thấy ở trên:

• Luôn luôn đặt NOCOUNT ONở đầu của một Proc, trước khi bạn thực hiện bất kỳ công việc nào trong Proc, nhưng cũng luôn luôn SET NOCOUNT OFFmột lần nữa, trước khi trả lại bất kỳ bản ghi nào từ các Proc được lưu trữ.

Vì vậy, "nói chung hãy tiếp tục, trừ khi bạn thực sự trả lại kết quả". Tôi không biết bất kỳ cách nào mà điều này có thể phá vỡ bất kỳ mã khách hàng nào, điều đó có nghĩa là mã khách hàng không bao giờ cần biết bất cứ điều gì về nội bộ của Proc và nó không đặc biệt khó chịu.

Liên quan đến việc kích hoạt NHibernate, tôi đã có trải nghiệm đó trực tiếp. Về cơ bản, khi NH thực hiện CẬP NHẬT, nó dự kiến ​​sẽ có một số hàng nhất định bị ảnh hưởng. Bằng cách thêm SET NOCOUNT ON vào các kích hoạt, bạn sẽ nhận được số lượng hàng trở lại với những gì NH mong đợi do đó khắc phục vấn đề. Vì vậy, vâng, tôi chắc chắn sẽ khuyên bạn nên tắt nó để kích hoạt nếu bạn sử dụng NH.

Về việc sử dụng trong SP, đó là vấn đề sở thích cá nhân. Tôi đã luôn tắt hàng, nhưng sau đó, một lần nữa, không có tranh luận mạnh mẽ thực sự.

Ở một lưu ý khác, bạn thực sự nên xem xét chuyển khỏi kiến ​​trúc dựa trên SP, sau đó bạn thậm chí sẽ không có câu hỏi này.

Tôi muốn tự xác minh rằng 'THIẾT LẬP NOCOUNT' không lưu gói mạng cũng không làm tròn số

Tôi đã sử dụng thử nghiệm SQLServer 2017 trên một máy chủ khác (Tôi đã sử dụng VM) create table ttable1 (n int); insert into ttable1 values (1),(2),(3),(4),(5),(6),(7) go create procedure procNoCount as begin set nocount on update ttable1 set n=10-n end create procedure procNormal as begin update ttable1 set n=10-n end Sau đó, tôi đã theo dõi các gói trên cổng 1433 bằng công cụ 'Wireshark': nút 'bộ lọc chụp' -> 'cổng 1433'

exec procNoCount

đây là gói phản hồi: 0000 00 50 56 c0 00 08 00 0c 29 31 3f 75 08 00 45 00 0010 00 42 d0 ce 40 00 40 06 84 0d c0 a8 32 88 c0 a8 0020 32 01 05 99 fe a5 91 49 e5 9c be fb 85 01 50 18 0030 02 b4 e6 0e 00 00 04 01 00 1a 00 35 01 00 79 00 0040 00 00 00 fe 00 00 e0 00 00 00 00 00 00 00 00 00

exec procNormal

đây là gói phản hồi: 0000 00 50 56 c0 00 08 00 0c 29 31 3f 75 08 00 45 00 0010 00 4f d0 ea 40 00 40 06 83 e4 c0 a8 32 88 c0 a8 0020 32 01 05 99 fe a5 91 49 e8 b1 be fb 8a 35 50 18 0030 03 02 e6 1b 00 00 04 01 00 27 00 35 01 00 ff 11 0040 00 c5 00 07 00 00 00 00 00 00 00 79 00 00 00 00 0050 fe 00 00 e0 00 00 00 00 00 00 00 00 00

Trên dòng 40 tôi có thể thấy '07' là số 'hàng bị ảnh hưởng'. Nó được bao gồm trong gói phản hồi. Không có gói phụ.

Tuy nhiên, nó có thêm 13 byte có thể được lưu, nhưng có lẽ không đáng giá hơn việc giảm tên cột (ví dụ: 'ManageDepidor' thành 'MD')

Vì vậy, tôi thấy không có lý do để sử dụng nó cho hiệu suất

NHƯNG Như những người khác đã đề cập, nó có thể phá vỡ ADO.NET và tôi cũng vấp phải một vấn đề khi sử dụng python: MSSQL2008 - Pyodbc - SQL trước đó không phải là một truy vấn

Vì vậy, có lẽ một thói quen tốt vẫn ...

SET NOCOUNT ON;

Dòng mã này được sử dụng trong SQL để không trả về các hàng số bị ảnh hưởng trong quá trình thực hiện truy vấn. Nếu chúng tôi không yêu cầu số lượng hàng bị ảnh hưởng, chúng tôi có thể sử dụng điều này vì điều này sẽ giúp tiết kiệm việc sử dụng bộ nhớ và tăng thời gian thực hiện truy vấn.

THIẾT LẬP NOCOUNT; Mã ở trên sẽ dừng thông báo được tạo bởi công cụ máy chủ sql đến cửa sổ kết quả phía trước sau khi thực hiện lệnh DML / DDL.

Tại sao chúng ta làm điều đó? Vì công cụ máy chủ SQL cần một số tài nguyên để nhận trạng thái và tạo thông báo, nó được coi là quá tải đối với công cụ máy chủ Sql. Vì vậy, chúng tôi đặt thông báo không đếm được.

Một nơi SET NOCOUNT ONthực sự có thể giúp là nơi bạn đang thực hiện các truy vấn trong một vòng lặp hoặc một con trỏ. Điều này có thể thêm tối đa lưu lượng mạng.

CREATE PROCEDURE NoCountOn
AS
set nocount on
    DECLARE @num INT = 10000
    while @num > 0
    begin
       update MyTable SET SomeColumn=SomeColumn
       set @num = @num - 1
    end
GO


CREATE PROCEDURE NoCountOff
AS
set nocount off
    DECLARE @num INT = 10000
    while @num > 0
    begin
       update MyTable SET SomeColumn=SomeColumn
       set @num = @num - 1
    end
GO

Bật số liệu thống kê của khách hàng trong SSMS, một lần chạy EXEC NoCountOnvà EXEC NoCountOffcho thấy rằng có thêm lưu lượng truy cập 390KB trên NoCount Offer:

Có lẽ không lý tưởng để thực hiện các truy vấn trong một vòng lặp hoặc con trỏ, nhưng chúng ta cũng không sống trong thế giới lý tưởng :)

Tôi biết đó là câu hỏi khá cũ. nhưng chỉ để cập nhật.

Cách tốt nhất để sử dụng "THIẾT LẬP NOCOUNT ON" là đưa nó lên như một câu lệnh đầu tiên trong SP của bạn và đặt lại TẮT ngay trước câu lệnh CHỌN cuối cùng.

Tôi không biết cách kiểm tra SET NOCOUNT ON giữa máy khách và SQL, vì vậy tôi đã thử nghiệm một hành vi tương tự cho lệnh SET khác "SET TRANSACTION ISOLATION LEVEL READ UNCIMMITTED"

Tôi đã gửi một lệnh từ kết nối của mình thay đổi hành vi mặc định của SQL (READ CAMITED) và nó đã được thay đổi cho các lệnh tiếp theo. Khi tôi thay đổi mức ISOLATION trong một thủ tục được lưu trữ, nó không thay đổi hành vi kết nối cho lệnh tiếp theo.

Kết luận hiện tại,

1. Thay đổi cài đặt bên trong quy trình được lưu trữ sẽ không thay đổi cài đặt mặc định của kết nối.
2. Thay đổi cài đặt bằng cách gửi lệnh bằng ADOCOnnection sẽ thay đổi hành vi mặc định.

Tôi nghĩ rằng điều này có liên quan đến lệnh SET khác, chẳng hạn như "SET NOCOUNT ON"

if (set no Count == off)

{sau đó nó sẽ giữ dữ liệu có bao nhiêu bản ghi bị ảnh hưởng để giảm hiệu suất} khác {nó sẽ không theo dõi bản ghi các thay đổi do đó cải thiện perfomace}}

Đôi khi ngay cả những điều đơn giản nhất cũng có thể tạo ra sự khác biệt. Một trong những mục đơn giản nên là một phần của mọi thủ tục được lưu trữ là SET NOCOUNT ON. Một dòng mã này, được đặt ở đầu của một thủ tục được lưu trữ sẽ tắt các thông báo mà SQL Server gửi lại cho máy khách sau khi mỗi câu lệnh T-SQL được thực thi. Này được thực hiện cho tất cả SELECT, INSERT, UPDATE, và DELETEbáo cáo. Có thông tin này rất hữu ích khi bạn chạy câu lệnh T-SQL trong cửa sổ truy vấn, nhưng khi các thủ tục được lưu trữ được chạy, không cần thông tin này được gửi lại cho máy khách.

Bằng cách loại bỏ chi phí phụ này khỏi mạng, nó có thể cải thiện hiệu năng tổng thể cho cơ sở dữ liệu và ứng dụng của bạn.

Nếu bạn vẫn cần lấy số lượng hàng bị ảnh hưởng bởi câu lệnh T-SQL đang thực thi, bạn vẫn có thể sử dụng @@ROWCOUNTtùy chọn. Bằng cách ban hành một SET NOCOUNT ONhàm này ( @@ROWCOUNT) vẫn hoạt động và vẫn có thể được sử dụng trong các thủ tục được lưu trữ của bạn để xác định có bao nhiêu hàng bị ảnh hưởng bởi câu lệnh.