USTAW NOCOUNT NA użyciu


341

Zainspirowany tym pytaniem, gdzie istnieją różne widoki na SET NOCOUNT ...

Czy powinniśmy używać SET NOCOUNT ON dla SQL Server? Jeśli nie, dlaczego nie?

Co robi Edytuj 6, 22 lipca 2011 r

Pomija komunikat „wpływ xx wierszy” po dowolnym DML. Jest to zestaw wyników i po wysłaniu klient musi go przetworzyć. Jest mały, ale mierzalny (patrz odpowiedzi poniżej)

W przypadku wyzwalaczy itp. Klient otrzyma wiele „wpływających wierszy xx”, co powoduje wszelkiego rodzaju błędy dla niektórych ORM, MS Access, JPA itp. (Patrz zmiany poniżej)

Tło:

Ogólnie przyjętą najlepszą praktyką (myślałem do tego pytania) jest stosowanie SET NOCOUNT ONw wyzwalaczach i procedurach przechowywanych w SQL Server. Używamy go wszędzie, a szybkie google pokazuje wiele zgodnych MVP programu SQL Server.

MSDN twierdzi, że może to uszkodzić SQLDataAdapter .net .

Teraz oznacza to dla mnie, że SQLDataAdapter ogranicza się do całkowicie prostego przetwarzania CRUD, ponieważ oczekuje, że komunikat „n wierszy dotkniętych” zostanie dopasowany. Nie mogę więc użyć:

  • JEŚLI ISTNIEJE, aby uniknąć duplikatów (komunikat nie ma wpływu na wiersze) Uwaga: należy zachować ostrożność
  • GDZIE NIE ISTNIEJE (mniej wierszy niż oczekiwano
  • Filtruj trywialne aktualizacje (np. Żadne dane w rzeczywistości się nie zmieniają)
  • Czy wcześniej uzyskać dostęp do tabeli (np. Logowanie)
  • Ukryj złożoność lub denormlisation
  • itp

W pytaniu marc_s (który zna się na jego SQL-ach) mówi: nie używaj go. Różni się to od tego, co myślę (i uważam się za nieco kompetentnego w SQL).

Możliwe, że coś mi umknęło (nie krępuj się wskazać oczywiste), ale co tam myślicie ludzie?

Uwaga: minęły lata, odkąd widziałem ten błąd, ponieważ obecnie nie używam SQLDataAdapter.

Edycje po komentarzach i pytaniach:

Edycja: więcej myśli ...

Mamy wielu klientów: jeden może używać C # SQLDataAdaptor, inny może używać nHibernate z Java. Można to zmienić na różne sposoby SET NOCOUNT ON.

Jeśli traktujesz przechowywane procy jako metody, to zła forma (anty-wzorzec) zakłada, że ​​pewne wewnętrzne przetwarzanie działa w określony sposób na twoje własne potrzeby.

Edycja 2: wyzwalacz przerywający pytanie nHibernate , gdzie SET NOCOUNT ONnie można ustawić

(i nie, to nie jest duplikat tego )

Edycja 3: Jeszcze więcej informacji, dzięki mojemu koledze z MVP

Edytuj 4: 13 maja 2011 r

Łamie także SQL Linq 2, gdy nie jest określony?

Edytuj 5: 14 czerwca 2011 r

Łamie JPA, przechowywane proc ze zmiennymi tabel: Czy JPA 2.0 obsługuje zmienne tabel SQL Server?

Edytuj 6: 15 sierpnia 2011 r

Siatka danych „Edycja wierszy” SSMS wymaga ustawienia USTAW NOCOUNT: Zaktualizuj wyzwalacz za pomocą GROUP BY

Edycja 7: 07 marca 2013

Bardziej szczegółowe informacje z @RemusRusanu:
Czy USTAW NOCOUNT naprawdę robi tak dużą różnicę w wydajności


@AlexKuznetsov: Czym byłoby podejście „Threadsafe”? Czy na pewno odczyty wykonane w EXISTS nadal będą zawierać wszelkie zaległe transakcje?
AnthonyWJones

2
@Jeremy Seghi: przepraszam za późną odpowiedź. Komunikat (# wpływ dotyczy) jest narzędziem klienta interpretowanym przez SSMS itp., Jednak przesyłany jest pakiet z tą informacją. Oczywiście wiem o tym, jak działa @@ rowcount itp., Ale nie o to chodzi w pytaniu ...
gbn

1
Bez obaw. Osobiście zgadzam się z twoim stanowiskiem; Właśnie komentowałem, że nie ma bezpośredniej korelacji między wynikami konstruktu IF / WHERE EXISTS a SET NOCOUNT. Otrzymuję spójne wyniki z tych konstrukcji niezależnie od NOCOUNT. Jeśli masz coś odmiennego, prześlij to po swojemu.
Jeremy S,

1
@Jeremy Seghi: masz rację: USTAW NOCOUNT tylko pomija dodatkowy pakiet danych z powrotem do klienta. JEŚLI @@ ROWCOUNT itp. Nie ulegają zmianie. Och, i psuje SQLDataAdapters ... :-)
gbn

1
@Kieren Johnstone: z perspektywy czasu jest to źle sformułowane pytanie.
Głosowałbym

Odpowiedzi:


245

Ok, teraz przeprowadziłem badania, oto oferta:

W protokole TDS SET NOCOUNT ONzapisuje tylko 9 bajtów na zapytanie, podczas gdy sam tekst „SET NOCOUNT ON” ma aż 14 bajtów. Kiedyś myślałem, że 123 row(s) affectedzostał zwrócony z serwera zwykłym tekstem w osobnym pakiecie sieciowym, ale tak nie jest. W rzeczywistości jest to mała struktura o nazwie DONE_IN_PROCosadzona w odpowiedzi. To nie jest osobny pakiet sieciowy, więc nie marnuje się żadna podróż w obie strony.

Myślę, że możesz trzymać się domyślnego zachowania liczenia prawie zawsze, nie martwiąc się o wydajność. Są jednak przypadki, w których wcześniejsze obliczenie liczby wierszy wpłynęłoby na wydajność, na przykład kursor tylko do przodu. W takim przypadku NOCOUNT może być koniecznością. Poza tym, absolutnie nie ma potrzeby stosowania motta „używaj NOCOUNT tam, gdzie to możliwe”.

Oto bardzo szczegółowa analiza dotycząca nieistotności SET NOCOUNTustawienia: http://daleburnett.com/2014/01/everything-ever-wanted-know-set-nocount/


W rzeczy samej. Używam SET NOCOUNT ON na zawsze, ale marc_s wskazał na ograniczenie SQLDataAdapter w innym pytaniu.
gbn

Dzięki. Bajty lub rozmiar nie są dla mnie problemem, ale klient musi to przetworzyć. Jednak to zależność SQLDataAdapter nadal mnie zadziwia ...
gbn,

2
Dzięki za odpowiedź. Zaakceptuję to z powodu twoich dochodzeń, które wywołały więcej informacji i pracę ode mnie. Nie zgadzam się jednak z ogólnymi: może to mieć znaczenie, jak pokazują inne odpowiedzi. Pozdrawiam, gbn
gbn

13
To nie jest liczba bajtów opóźnienia w obie strony na przewodzie, który jest zabójcą wydajności
racingsnail

1
W strumieniu komunikatów TDS, a przykładem jest wstawianie tylko wartości do tabeli. Komunikat DONINPROC(RPC) lub DONE(BATCH) jest przesyłany strumieniowo z rowcountustawionymi wierszami, których dotyczy problem, podczas gdy done_countflaga jest true, niezależnie od tego, czy NO_COUNTjest ON. Zależy od implementacji lib klienta w przypadkach, gdy zapytanie zawiera instrukcje SELECT lub wywołania RPC, które dokonują wyboru, może wymagać wyłączenia zliczania ... GDY wyłączone, wiersze są nadal liczone dla instrukcji select, ale flaga DONE_COUNTjest ustawiona na false. Zawsze czytaj to, co sugeruje twoja biblioteka lib, ponieważ zamiast ciebie interpretuje strumień tokena (wiadomości)
Milan Jaric

87

Znalezienie prawdziwych danych porównawczych wokół NOCOUNT zajęło mi dużo czasu, więc pomyślałem, że podzielę się krótkim podsumowaniem.

  • Jeśli procedura składowana używa kursora do wykonywania wielu bardzo szybkich operacji bez zwracanych wyników, wyłączenie NOCOUNT może potrwać około 10 razy dłużej niż włączenie. 1 To jest najgorszy scenariusz.
  • Jeśli procedura składowana wykonuje tylko jedną szybką operację bez zwracanych wyników, ustawienie NOCOUNT WŁ. Może dać około 3% wzrost wydajności. 2 Byłoby to zgodne z typową procedurą wstawiania lub aktualizacji. (Zobacz komentarze do tej odpowiedzi, aby dowiedzieć się, dlaczego nie zawsze jest to szybsze).
  • Jeśli procedura składowana zwróci wyniki (tj. Wybierzesz coś), różnica wydajności zmniejszy się proporcjonalnie do wielkości zestawu wyników.

5
+1 do wpływu na kursor, jest to zgodne z moimi obserwacjami
zvolkov

Punkt 2 nie jest dokładny! Mam na myśli blog, do którego się odnosi. Nigdy nie było! DONE i DONEPROC i DONEINPROC są wysyłane z tym samym rozmiarem, niezależnie od tego, czy NO_COUNT jest ustawione na ON czy OFF. RowCount jest nadal dostępny jako ULONGLONG (64 bajty) i flaga DONE_COUNT jest nadal dostępna, ale wartość bitu wynosi 0. Serwer SQL i tak zlicza liczbę wierszy, nawet jeśli nie jesteś zainteresowany odczytaniem wartości z tokena GOTOWEGO. Jeśli czytasz @@ ROWCOUNT, to dodajesz więcej bajtów do strumienia tokenu albo w postaci tokenu wartości zwrotnej, albo jako kolejną token colmetadata + wiersz!
Milan Jaric,

@MilanJaric: Dzięki za wywołanie tego. Pomogłeś mi zrozumieć, że połączyłem niewłaściwy artykuł. Link jest teraz zaktualizowany, a artykuł zawiera przekonujący argument, aby pokazać, że może nastąpić niewielka poprawa wydajności dzięki SET NOCOUNT ON. Czy uważasz, że występują problemy z zastosowanymi metodami testów porównawczych?
StriplingWarrior

:) wciąż niedokładne w przypadku ustawienia NOCOUNT WYŁ. / WŁ. Błąd polega na tym, że drugi SP nie ma SET NOCOUNT OFF;i dlatego myślą, że nie otrzymają dodatkowych bajtów w odpowiedzi. Dokładnym punktem odniesienia byłoby zastosowanie SET NOCOUNT ONw SET NOCOUNT OFFprocedurze przechowywanej po lewej i po prawej stronie. W ten sposób otrzymasz pakiet TDS DONEINPROC (SET NOCOUNT ...), jeszcze raz dziesięć DONEINPROC (INSERT statement), a potem RETURNVALUE(@@ROWCOUNT), RETURNSTATUS 0dla sp i na końcu DONPROC. Wystąpił błąd, ponieważ w drugim sp nie ma SET NOCOUNT OFF w ciele!
Milan Jaric,

Aby przeformułować to, co znaleźli, ale nie zdawali sobie sprawy, że jeśli masz requestst pobierania kursora 1K, najpierw zrób jedno żądanie, aby ustawić NOCOUNT na ON lub OFF dla połączenia, a następnie użyj tego samego połączenia, aby wywołać kursor pobierania 1K razy, aby zaoszczędzić trochę przepustowości. Rzeczywisty stan połączenia dla NOCOUNT ON lub OFF nie wpłynie na przepustowość, może po prostu pomylić bibliotekę klienta, np. ADO.net lub ODBC. Więc „nie używaj SET NOCOUNT <WHATEVER>, jeśli zależy ci na przepustowości” :)
Milan Jaric

77
  • Gdy SET NOCOUNT jest WŁĄCZONE, licznik (wskazujący liczbę wierszy, na które wpływa instrukcja Transact-SQL) nie jest zwracany. Gdy USTAW NOCOUNT jest WYŁĄCZONY, licznik jest zwracany. Jest używany z dowolną instrukcją SELECT, INSERT, UPDATE, DELETE.

  • Ustawienie SET NOCOUNT jest ustawiane w czasie wykonywania lub wykonywania, a nie w czasie analizy.

  • SET NOCOUNT ON poprawia wydajność procedury składowanej (SP).

  • Składnia: SET NOCOUNT {ON | WYŁ.}

Przykład ustawienia NOCOUNT NA:

wprowadź opis zdjęcia tutaj

Przykład ustawienia NOCOUNT OFF:

wprowadź opis zdjęcia tutaj


7
Łatwy i szybki do zrozumienia dzięki zrzutom ekranu. Dobra robota. :)
shaijut

35

Myślę, że w pewnym stopniu jest to problem DBA vs. deweloper.

Jako deweloper powiedziałbym, że nie używaj go, chyba że absolutnie pozytywnie musisz - ponieważ użycie go może uszkodzić kod ADO.NET (jak udokumentował Microsoft).

I wydaje mi się, że jako DBA będziesz bardziej po drugiej stronie - używaj go, gdy tylko jest to możliwe, chyba że naprawdę musisz zapobiec jego użyciu.

Ponadto, jeśli Twoi deweloperzy kiedykolwiek używają „RecordsAffected” zwracanego przez ExecuteNonQuerywywołanie metody ADO.NET , masz kłopoty, jeśli wszyscy używają, SET NOCOUNT ONponieważ w tym przypadku ExecuteNonQuery zawsze zwróci 0.

Zobacz także post na blogu Petera Bromberga i sprawdź jego pozycję.

Tak naprawdę sprowadza się to do tego, kto może ustanowić standardy :-)

Marc


Mówi o prostym CRUD: wspomniana siatka danych mogłaby używać xml do wysyłania wielu wierszy, aby uniknąć podróży w obie strony itp.
gbn

Wydaje mi się, że jeśli nigdy nie użyjesz SqlDataAdapters i nigdy nie będziesz sprawdzać i polegać na liczbie „wpływających na rekordy” zwróconych przez ExecuteNonQuery (np. Jeśli używasz czegoś takiego jak Linq-SQL lub NHibernate), to prawdopodobnie nie masz żadnych problemów używając SET NOCOUNT ON we wszystkich zapisanych procesach.
marc_s

12

Jeśli mówisz, że możesz mieć również różnych klientów, występują problemy z klasycznym ADO, jeśli SET NOCOUNT nie jest ustawiony na ON.

Jeden z nich pojawia się regularnie: jeśli procedura przechowywana wykonuje wiele instrukcji (i w ten sposób zwracanych jest wiele komunikatów „xxx wpływających na wiersze”), ADO wydaje się nie obsługiwać tego i zgłasza błąd „Nie można zmienić właściwości ActiveConnection obiektu Recordset który ma obiekt Command jako źródło. ”

Dlatego generalnie zalecam włączenie go, chyba że istnieje naprawdę dobry powód, aby tego nie robić. być może znalazłeś naprawdę dobry powód, dla którego muszę przejść i przeczytać więcej.


9

Ryzykując, że wszystko się skomplikuje, zachęcam nieco inną zasadę niż wszystkie powyższe:

  • Zawsze ustawiany NOCOUNT ONna początku proc, przed wykonaniem jakiejkolwiek pracy w proc, ale także zawsze SET NOCOUNT OFFponownie, przed zwróceniem jakichkolwiek zestawów rekordów z zapisanego proc.

Więc „ogólnie nie wyłączaj nocount, z wyjątkiem sytuacji, gdy zwracasz zestaw wyników”. Nie wiem, w jaki sposób może to złamać dowolny kod klienta, oznacza to, że kod klienta nigdy nie musi nic wiedzieć o procesach wewnętrznych i nie jest to szczególnie uciążliwe.


Dzięki. Oczywiście możesz uzyskać liczbę wierszy z zestawu danych lub kontenera konsumującego, ale może być to przydatne. Nie możemy mieć wyzwalaczy na SELECT, więc byłoby to bezpieczne: większość błędów klienta jest spowodowana fałszywymi komunikatami o zmianach danych.
gbn

Problem z tą regułą polega na tym, że trudniej jest ją przetestować niż „Czy USTAW NOCOUNT WŁĄCZ na górze proc?”; Zastanawiam się, czy narzędzia analizy SQL, takie jak Sql Enlight, mogą testować tego rodzaju rzeczy ... Dodanie go do mojej długoterminowej listy rzeczy do zrobienia dla mojego projektu formatera SQL :)
Tao

5

Jeśli chodzi o wyzwalacze przełamujące NHibernate, miałem to doświadczenie z pierwszej ręki. Zasadniczo, gdy NH wykonuje AKTUALIZACJĘ, oczekuje pewnej liczby wierszy, których to dotyczy. Dodając SET NOCOUNT ON do wyzwalaczy, otrzymujesz liczbę wierszy z powrotem do tego, czego oczekiwał NH, tym samym rozwiązując problem. Więc tak, zdecydowanie polecam wyłączenie go dla wyzwalaczy, jeśli używasz NH.

Jeśli chodzi o użycie w SP, jest to kwestia osobistych preferencji. Zawsze wyłączałem liczenie wierszy, ale z drugiej strony nie ma żadnych silnych argumentów.

Z drugiej strony, naprawdę powinieneś rozważyć odejście od architektury opartej na SP, wtedy nawet nie będziesz mieć tego pytania.


1
Nie zgadzam się z odejściem od przechowywanych procesów. Oznaczałoby to, że musimy mieć ten sam kod SQL w 2 różnych bazach kodu klienta i zaufać naszym programistom. Jesteśmy deweloperami DBA. I nie masz na myśli „set NOCOUNT ON ”?
gbn

@CodeBlend: wystarczy go Google na więcej niż kiedykolwiek potrzebujesz. Jednak ... stackoverflow.com/a/4040466/27535
gbn

3

Chciałem sprawdzić, czy „USTAW NOCOUNT” nie zapisuje pakietu sieciowego ani obchodu

Użyłem testowego SQLServer 2017 na innym hoście (użyłem maszyny wirtualnej). 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 Następnie przeszukałem pakiety na porcie 1433 za pomocą narzędzia „Wireshark”: przycisk „przechwyć filtr” -> „port 1433”

exec procNoCount

to jest pakiet odpowiedzi: 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

to jest pakiet odpowiedzi: 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

W linii 40 widzę „07”, czyli liczbę „wpływających wierszy”. Jest on zawarty w pakiecie odpowiedzi. Bez dodatkowego pakietu.

Ma jednak 13 dodatkowych bajtów, które można zapisać, ale prawdopodobnie nie jest to bardziej warte niż redukcja nazw kolumn (np. „ManagingDepartment” do „MD”)

Więc nie widzę powodu, aby używać go do wydajności

ALE, jak wspomnieli inni, może złamać ADO.NET i natknąłem się również na problem przy użyciu Pythona: MSSQL2008 - Pyodbc - Poprzedni SQL nie był zapytaniem

Więc prawdopodobnie dobry nawyk wciąż ...


1
SET NOCOUNT ON;

Ten wiersz kodu jest używany w języku SQL, aby nie zwracać liczby wierszy, których dotyczy wykonanie zapytania. Jeśli nie wymagamy liczby wierszy, których dotyczy problem, możemy to wykorzystać, ponieważ pomogłoby to zaoszczędzić pamięć i zwiększyć szybkość wykonywania zapytania.


2
Pamiętaj, że @@ ROWCOUNT jest nadal ustawiony. USTAW NOCOUNT ON pomija wszelkie dodatkowe odpowiedzi, które SQL Server wysyła do klienta. Zobacz zaakceptowaną odpowiedź powyżej
gbn

1

USTAW NOCOUNT ON; Powyższy kod zatrzyma komunikat generowany przez silnik serwera SQL do okna wyników z przodu po wykonaniu polecenia DML / DDL.

Dlaczego to robimy? Ponieważ silnik serwera SQL potrzebuje pewnego zasobu, aby uzyskać status i wygenerować komunikat, uważa się to za przeciążenie silnika serwera Sql, więc włączamy komunikat niezliczony.


1

Jednym z miejsc, które SET NOCOUNT ONnaprawdę mogą pomóc, jest zapytania w pętli lub kursorze. Może to zsumować duży ruch sieciowy.

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

Włączenie statystyki klienta w SSMS, seria EXEC NoCountOni EXEC NoCountOffpokazuje, że na NoCountOff był dodatkowy ruch 390 KB:

statystyki klienta

Prawdopodobnie nie jest to idealne do robienia zapytań w pętli lub kursorze, ale my też nie żyjemy w idealnym świecie :)


0

Wiem, że to dość stare pytanie. ale tylko do aktualizacji.

Najlepszym sposobem na użycie „SET NOCOUNT ON” jest umieszczenie go jako pierwszej instrukcji w SP i ponowne ustawienie OFF tuż przed ostatnią instrukcją SELECT.


0

SET NOCOUNT ON pozwala nawet na dostęp do dotkniętych wierszy w następujący sposób:

SET NOCOUNT ON

DECLARE @test TABLE (ID int)

INSERT INTO @test
VALUES (1),(2),(3)

DECLARE @affectedRows int = -99  

DELETE top (1)
  FROM @test
SET @affectedRows = @@rowcount

SELECT @affectedRows as affectedRows

Wyniki

wpływa Wiersze

1

Wiadomości

Polecenia zostały wykonane pomyślnie.

Czas realizacji: 2020-06-18T16: 20: 16.9686874 + 02: 00


-1

Nie wiem, jak przetestować SET NOCOUNT ON między klientem a SQL, więc przetestowałem podobne zachowanie dla innej komendy SET „USTAW POZIOM IZOLACJI ODCZYTAJ NIEOGRANICZONE”

Wysłałem polecenie z mojego połączenia, zmieniając domyślne zachowanie SQL (CZYTAJ ZAKOŃCZONO) i zostało ono zmienione dla następnych poleceń. Kiedy zmieniłem poziom ISOLATION w procedurze przechowywanej, nie zmieniło to zachowania połączenia dla następnego polecenia.

Aktualny wniosek,

  1. Zmiana ustawień w procedurze przechowywanej nie zmienia domyślnych ustawień połączenia.
  2. Zmiana ustawienia poprzez wysyłanie poleceń za pomocą ADOCOnnection zmienia domyślne zachowanie.

Myślę, że dotyczy to innych poleceń SET, takich jak „SET NOCOUNT ON”


Czy powyższy punkt 1 oznacza, że ​​tak naprawdę nie musisz WYŁĄCZAĆ NOCOUNT na końcu, ponieważ nie wpływa to na środowisko globalne?
funkymushroom

Nie jestem pewien, czy to właśnie miał na myśli w punkcie 1, ale w moich testach tak, najwyraźniej SET NOCOUNT ON nie ma wpływu na procedurę przechowywaną.
Doug

To był zły wybór porównania, ponieważ poziom izolacji jest wyraźnie związany z określoną transakcją, więc nie ma szczególnego powodu, aby oczekiwać, że będzie on zgodny z ustawieniem takim jakNOCOUNT
IMSoP

-1

if (ustaw bez liczenia == wyłącz)

{wtedy będzie przechowywać dane o tym, ile rekordów wpłynęło, więc zmniejszy wydajność} else {nie będzie śledził rejestru zmian, a tym samym ulepszy perfomace}}


-1

Czasami nawet najprostsze rzeczy mogą coś zmienić. Jednym z tych prostych elementów, które powinny być częścią każdej procedury składowanej, jestSET NOCOUNT ON . Ten jeden wiersz kodu umieszczony na górze procedury przechowywanej wyłącza komunikaty, które SQL Server wysyła z powrotem do klienta po wykonaniu każdej instrukcji T-SQL. Jest to wykonywane dla wszystkich SELECT, INSERT, UPDATE, iDELETE sprawozdania. Posiadanie tych informacji jest przydatne podczas uruchamiania instrukcji T-SQL w oknie zapytania, ale podczas uruchamiania procedur przechowywanych nie ma potrzeby przekazywania tych informacji z powrotem do klienta.

Usunięcie tego dodatkowego obciążenia z sieci może znacznie poprawić ogólną wydajność bazy danych i aplikacji.

Jeśli nadal potrzebujesz uzyskać liczbę wierszy, na które wpływa wykonywana instrukcja T-SQL, nadal możesz użyć @@ROWCOUNT opcji. Wydanie SET NOCOUNT ONtej funkcji ( @@ROWCOUNT) nadal działa i może być nadal używane w procedurach przechowywanych w celu określenia, ile wierszy dotyczy instrukcja.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.