Ustaw NOCOUNT przy użyciu

Szukanie prawdziwych benchmarków wokół NOCOUNT Zajęło mi sporo czasu, więc pomyślałem, że podzielę się krótkim podsumowaniem.

• Jeśli Twoja 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. ¹ to najgorszy scenariusz.
• Jeśli Twoja procedura składowana wykona tylko jedną szybką operację bez zwracanych wyników, ustawienie NOCOUNT na spowoduje zysk około 3% wzrost wydajności. ² byłoby to zgodne z typową procedurą wstawiania lub aktualizacji.
• Jeśli Twoja procedura składowana zwróci wyniki (tzn. wybierzesz coś), różnica wydajności zmniejszy się proporcjonalnie do rozmiaru zestawu wyników.

• Gdy ustawione NOCOUNT jest włączone, liczba (określająca liczbę wierszy, na które wpływa polecenie Transact-SQL) nie jest zwracana. Gdy ustawione NOCOUNT jest wyłączone, licznik jest zwracany. Jest on używany z dowolną instrukcją SELECT, INSERT, UPDATE, DELETE.

• Ustawienie SET NOCOUNT jest ustawiane w czasie wykonania lub uruchomienia, a nie w czasie parse.

• Ustaw NOCOUNT na poprawia wydajność procedury składowanej (SP).

• Składnia: SET NOCOUNT { ON / OFF }

Przykład ustawienia NOCOUNT na:

Przykład wyłączonego ustawienia NOCOUNT:

Myślę, że do pewnego stopnia jest to problem DBA vs.developer.

Jako dev głównie, powiedziałbym, nie używaj go, chyba że absolutnie pozytywnie musisz - ponieważ korzystanie z niego może złamać twoje ADO.NET kod (zgodnie z dokumentacją firmy Microsoft).

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

Również, jeśli twoi Programiści kiedykolwiek użyją "rekordów" zwracanych przez ADO.NET 'S ExecuteNonQuery method call, you' re in trouble if każdy używa SET NOCOUNT ON, ponieważ w tym przypadku ExecuteNonQuery zawsze zwróci 0.

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

To, czego doświadczam regularnie: jeśli procedura składowana wykona pewną liczbę poleceń (a tym samym zwracane są komunikaty "XXX rows affected"), ADO zdaje się tego nie obsługiwać i wyrzuca błąd "nie może zmienić właściwości ActiveConnection obiektu Recordset, który ma obiekt Command jako źródło."

Więc generalnie popieram włączam, chyba że jest naprawdę naprawdę dobry powód, żeby tego nie robić. być może znalazłeś naprawdę naprawdę dobry powód, który muszę iść i przeczytać więcej.

Ryzykując, że wszystko będzie bardziej skomplikowane, zachęcam do nieco innej zasady do wszystkich, które widzę powyżej:

• zawsze Ustaw NOCOUNT ONna górze proc, zanim wykonasz jakąkolwiek pracę w proc, ale również Zawsze SET NOCOUNT OFF ponownie, przed zwróceniem jakichkolwiek zestawów rekordów z przechowywanego proc.

Tak więc "zazwyczaj nocount jest włączone, z wyjątkiem sytuacji, gdy zwracasz resultset". Nie wiem, jak to może złamać dowolny kod klienta, oznacza to, że kod klienta nigdy nie potrzebuje wiedzieć cokolwiek o procach i nie jest to szczególnie uciążliwe.

Jeśli chodzi o wyzwalacze łamią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, naprawiając tym samym problem. Więc tak, zdecydowanie polecam wyłączenie go dla wyzwalaczy, jeśli używasz NH.

Jeśli chodzi o użycie w SPs, jest to kwestia osobistych preferencji. Zawsze wyłączałem licznik wierszy, ale potem znowu, tak czy siak nie ma mocnych argumentów.

Z innej uwagi, powinieneś naprawdę rozważyć odejście od architektury opartej na SP, wtedy nawet nie będziesz miał tego pytania.

USTAW NOCOUNT NA; Powyższy kod zatrzyma wiadomość wygenerowaną przez silnik sql server do okna wynikowego po wykonaniu polecenia DML / DDL.

Dlaczego to robimy? Ponieważ silnik SQL server pobiera trochę zasobów, aby uzyskać status i wygenerować wiadomość, jest on uważany za przeciążenie serwera Sql engine.So włączamy komunikat o braku kont.

Nie wiem, jak przetestować SET NOCOUNT pomiędzy Klientem a SQL, więc przetestowałem podobne zachowanie dla innych poleceń SET "SET poziom izolacji transakcji READ UNCIMMITTED"

Wysłałem polecenie z mojego połączenia zmieniające domyślne zachowanie SQL( read COMMITTED) i zostało zmienione dla kolejnych poleceń. Kiedy zmieniłem poziom izolacji wewnątrz procedury składowanej, nie zmieniło to zachowania połączenia dla następnego polecenia.

Current wniosek,

1. Zmiana ustawień wewnątrz procedury składowanej nie zmienia domyślnych ustawień połączenia.
2. Zmiana ustawień poprzez wysyłanie poleceń za pomocą ADOCOnnection zmienia domyślne zachowanie.

Myślę, że jest to istotne dla innych poleceń SET, takich jak "SET NOCOUNT ON"

SET NOCOUNT ON;

Ta linia kodu jest używana w SQL, aby nie zwracać wierszy liczb, których dotyczy zapytanie. Jeśli nie wymagamy liczby wierszy, których to dotyczy, możemy użyć tej opcji, ponieważ pomogłoby to w oszczędzaniu pamięci i zwiększyłoby szybkość wykonywania zapytania.

If (set no count== off)

{ następnie będzie przechowywać dane o tym, ile rekordów dotkniętych więc zmniejsz wydajność } else { nie będzie śledził zapisów zmian dlatego popraw perfomace } }

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

Najlepszym sposobem użycia "SET NOCOUNT ON" jest umieszczenie go jako pierwszej instrukcji w SP i ponowne wyłączenie tuż przed ostatnią instrukcją SELECT.