SET NOCOUNT ON penggunaan


341

Terinspirasi oleh pertanyaan ini di mana terdapat perbedaan pandangan tentang SET NOCOUNT ...

Haruskah kita menggunakan SET NOCOUNT ON untuk SQL Server? Jika tidak, mengapa tidak?

Apa yang dilakukannya Edit 6, pada 22 Jul 2011

Itu menekan pesan "xx baris yang terpengaruh" setelah DML apa pun. Ini adalah resultset dan ketika dikirim, klien harus memprosesnya. Ini kecil, tetapi dapat diukur (lihat jawaban di bawah)

Untuk pemicu dll, klien akan menerima beberapa "xx baris yang terpengaruh" dan ini menyebabkan semua jenis kesalahan untuk beberapa ORM, MS Access, JPA dll (lihat suntingan di bawah)

Latar Belakang:

Praktik terbaik yang diterima umum (saya pikir sampai pertanyaan ini) adalah untuk digunakan SET NOCOUNT ONdalam pemicu dan prosedur tersimpan dalam SQL Server. Kami menggunakannya di mana-mana dan google cepat menunjukkan banyak MVP SQL Server yang menyetujui juga.

MSDN mengatakan ini dapat merusak .net SQLDataAdapter .

Sekarang, ini berarti bagi saya bahwa SQLDataAdapter terbatas hanya untuk pemrosesan CRUD karena mengharapkan pesan "n rows terpengaruh" agar cocok. Jadi, saya tidak bisa menggunakan:

  • JIKA ADA untuk menghindari duplikat (tidak ada baris yang terpengaruh pesan) Catatan: gunakan dengan hati-hati
  • DIMANA TIDAK ADA (lebih sedikit baris dari yang diharapkan
  • Saring pembaruan sepele (mis. Tidak ada data yang benar-benar berubah)
  • Lakukan akses tabel apa pun sebelumnya (seperti logging)
  • Sembunyikan kompleksitas atau denormalisasi
  • dll

Dalam pertanyaan, marc_s (siapa yang tahu hal-hal SQL-nya) mengatakan jangan menggunakannya. Ini berbeda dengan apa yang saya pikirkan (dan saya menganggap diri saya agak kompeten di SQL juga).

Mungkin saja saya kehilangan sesuatu (merasa bebas untuk menunjukkan yang sudah jelas), tetapi apa yang kalian pikirkan di luar sana?

Catatan: sudah bertahun-tahun sejak saya melihat kesalahan ini karena saya tidak menggunakan SQLDataAdapter saat ini.

Suntingan setelah komentar dan pertanyaan:

Edit: Lebih banyak pemikiran ...

Kami memiliki banyak klien: satu dapat menggunakan C # SQLDataAdaptor, yang lain dapat menggunakan nHibernate dari Java. Ini dapat dipengaruhi dengan berbagai cara dengan SET NOCOUNT ON.

Jika Anda menganggap procs yang disimpan sebagai metode, maka itu bentuk yang buruk (anti-pola) untuk menganggap beberapa proses internal bekerja dengan cara tertentu untuk tujuan Anda sendiri.

Sunting 2: pemicu yang memecahkan pertanyaan nHibernate , di mana SET NOCOUNT ONtidak dapat diatur

(dan tidak, ini bukan duplikat dari ini )

Sunting 3: Namun lebih banyak info, terima kasih kepada kolega MVP saya

Sunting 4: 13 Mei 2011

Istirahat Linq 2 SQL juga ketika tidak ditentukan?

Sunting 5: 14 Juni 2011

Mematahkan JPA, proc yang disimpan dengan variabel tabel: Apakah JPA 2.0 mendukung variabel tabel SQL Server?

Sunting 6: 15 Agustus 2011

Kisi data "Edit rows" SSMS memerlukan SET NOCOUNT ON: Perbarui trigger dengan GROUP BY

Sunting 7: 07 Mar 2013

Lebih detail dari @RemusRusanu:
Apakah SET NOCOUNT ON benar-benar membuat banyak perbedaan kinerja


@AlexKuznetsov: Apa yang akan menjadi pendekatan "Threadsafe"? Tentunya pembacaan yang dilakukan dalam EXISTS akan tetap termasuk transaksi yang belum dibayar?
AnthonyWJones

2
@Jeremy Seghi: maaf atas jawaban yang terlambat. Pesan (#rows terpengaruh) adalah alat klien yang ditafsirkan oleh SSMS dll: namun ada paket yang dikirim dengan informasi ini. Tentu saja, saya menyadari bagaimana @@ rowcount bekerja dll, tetapi ini bukan poin dari pertanyaan ...
gbn

1
Jangan khawatir. Secara pribadi saya setuju dengan sudut pandang Anda; Saya hanya berkomentar bahwa tidak ada korelasi langsung antara hasil konstruksi IF / WHERE EXISTS dan SET NOCOUNT. Saya mendapatkan hasil yang konsisten dari konstruksi tersebut terlepas dari NOCOUNT. Jika Anda memiliki sesuatu yang mengatakan sebaliknya, silakan kirimkan dengan cara saya.
Jeremy S

1
@Jeremy Seghi: Anda benar: SET NOCOUNT ON hanya akan menekan paket data tambahan kembali ke klien. JIKA, @@ ROWCOUNT dll semua tidak terpengaruh. Oh, dan itu merusak SQLDataAdapters ... :-)
gbn

1
@Kieren Johnstone: jika dipikir-pikir, itu adalah pertanyaan dengan kata-kata yang buruk. Saya akan memilih untuk menutup jika ini bukan pertanyaan saya ...
gbn

Jawaban:


245

Ok sekarang saya sudah melakukan penelitian, ini kesepakatannya:

Dalam protokol TDS, SET NOCOUNT ONhanya menyimpan 9-byte per kueri sementara teks "SET NOCOUNT ON" itu sendiri adalah 14 byte kekalahan. Dulu saya berpikir bahwa 123 row(s) affecteditu dikembalikan dari server dalam teks biasa dalam paket jaringan yang terpisah tetapi itu tidak terjadi. Sebenarnya struktur kecil yang disebut DONE_IN_PROCtertanam dalam respons. Ini bukan paket jaringan yang terpisah sehingga tidak ada perjalanan pulang-pergi yang sia-sia.

Saya pikir Anda dapat tetap berpegang pada perilaku penghitungan default hampir selalu tanpa khawatir tentang kinerja. Namun ada beberapa kasus, di mana menghitung jumlah baris sebelumnya akan berdampak pada kinerja, seperti kursor hanya maju. Dalam hal ini, NOCOUNT mungkin suatu keharusan. Selain itu, sama sekali tidak perlu mengikuti moto "gunakan NOCOUNT sedapat mungkin".

Berikut adalah analisis yang sangat terperinci tentang SET NOCOUNTpengaturan yang tidak penting : http://daleburnett.com/2014/01/everything-ever-wanted-know-set-nocount/


Memang. Saya telah menggunakan SET NOCOUNT ON selamanya, tetapi marc_s menunjukkan keterbatasan SQLDataAdapter dalam pertanyaan lain.
gbn

Terima kasih. Bytes atau ukuran bukan masalah bagi saya, tetapi klien harus memprosesnya. Ini ketergantungan SqlDataAdapter yang masih mengejutkan saya meskipun ...
GBN

2
Terima kasih atas jawaban anda. Saya akan menerima ini karena penyelidikan Anda, yang memicu lebih banyak info dan pekerjaan dari saya. Saya tidak setuju pada biaya overhead: itu bisa penting karena jawaban lain menunjukkan. Cheers, gbn
gbn

13
Ini bukan jumlah byte penundaan perjalanan pulang-pergi yang merupakan pembunuh kinerja
racingsnail

1
Dalam aliran pesan TDS, dan contohnya adalah ketika seseorang hanya memasukkan nilai ke dalam tabel. DONINPROC(RPC) atau DONE(BATCH) pesan dialirkan dengan rowcountdiatur ke baris yang terpengaruh, sementara done_countbendera true, terlepas jika NO_COUNTada ON. Bergantung pada implementasi lib klien dalam kasus ketika kueri memegang pernyataan SELECT atau panggilan RPC yang memilih, mungkin mengharuskan untuk menonaktifkan penghitungan ... KETIKA dinonaktifkan, baris masih dihitung untuk pernyataan pilih, tetapi flag DONE_COUNTdiatur ke false. Selalu baca apa yang disarankan klien Anda karena itu akan mengartikan token (message) stream bukan Anda
Milan Jaric

86

Butuh banyak penggalian untuk menemukan angka patokan nyata di sekitar NOCOUNT, jadi saya pikir saya akan membagikan ringkasan singkat.

  • Jika prosedur tersimpan Anda menggunakan kursor untuk melakukan banyak operasi yang sangat cepat tanpa hasil yang dikembalikan, NOCOUNT OFF dapat memakan waktu sekitar 10 kali selama AKTIF. 1 Ini adalah skenario terburuk.
  • Jika prosedur tersimpan Anda hanya melakukan operasi cepat tunggal tanpa hasil yang dikembalikan, pengaturan NOCOUNT ON mungkin menghasilkan sekitar 3% peningkatan kinerja. 2 Ini akan konsisten dengan prosedur memasukkan atau memperbarui yang khas. (Lihat komentar pada jawaban ini untuk beberapa diskusi tentang mengapa ini tidak selalu lebih cepat.)
  • Jika prosedur tersimpan Anda mengembalikan hasil (yaitu Anda PILIH sesuatu), perbedaan kinerja akan berkurang secara proporsional dengan ukuran hasil yang ditetapkan.

5
+1 untuk dampak pada kursor, ini konsisten dengan pengamatan saya
zvolkov

Poin 2 tidak akurat! Maksud saya blog yang dimaksud. Tidak pernah! DONE dan DONEPROC dan DONEINPROC dikirim dengan ukuran yang sama tanpa memperhatikan apakah NO_COUNT diatur ke ON atau OFF. RowCount masih ada sebagai ULONGLONG (64 bytes) dan flag DONE_COUNT masih ada tetapi nilai bit 0. SQL server akan menghitung jumlah baris, walaupun Anda tidak tertarik untuk membaca nilai dari token DONE. Jika Anda membaca @@ ROWCOUNT maka Anda menambahkan lebih banyak byte ke aliran token baik dalam bentuk nilai token kembali atau sebagai token baris + colmetadata lainnya!
Milan Jaric

@MilanJaric: Terima kasih telah memanggilnya. Anda membantu saya menyadari bahwa saya telah menautkan artikel yang salah. Tautan diperbarui sekarang, dan artikel tersebut membuat argumen yang meyakinkan untuk menunjukkan bahwa mungkin ada sedikit peningkatan kinerja dengan SET NOCOUNT ON. Apakah Anda pikir ada masalah dengan metode benchmark yang digunakan?
StriplingWarrior

:) masih tidak akurat tentang SET NOCOUNT MATI / HIDUP, Kesalahan adalah bahwa SP kedua tidak memiliki SET NOCOUNT OFF;dan itulah sebabnya mereka berpikir mereka tidak mendapatkan byte tambahan sebagai tanggapan. Tolok ukur yang akurat akan digunakan SET NOCOUNT ONdi SET NOCOUNT OFFprosedur tersimpan kiri dan kanan. Dengan cara ini Anda akan mendapatkan paket TDS DONEINPROC (SET NOCOUNT ...), sepuluh lagi DONEINPROC (INSERT statement), dan kemudian RETURNVALUE(@@ROWCOUNT), lalu RETURNSTATUS 0untuk sp dan akhirnya DONPROC. Kesalahan ada karena sp kedua tidak memiliki SET NOCOUNT MATI di tubuh!
Milan Jaric

Untuk mengulangi apa yang mereka temukan tetapi mereka tidak sadari adalah bahwa jika Anda memiliki 1K mengambil permintaan kursor, pertama buat satu permintaan untuk mengatur NOCOUNT ke ON atau OFF untuk koneksi dan kemudian menggunakan koneksi yang sama untuk memanggil kursor mengambil 1K kali untuk menghemat bandwidth. Keadaan koneksi aktual untuk NOCOUNT ON atau OFF tidak akan mempengaruhi bandwidth, itu hanya dapat membingungkan lib klien misalnya ADO.net atau ODBC. Jadi "jangan gunakan SET NOCOUNT <WHATEVER> jika Anda peduli tentang bandwidth" :)
Milan Jaric

77
  • Ketika SET NOCOUNT AKTIF, hitungan (menunjukkan jumlah baris yang dipengaruhi oleh pernyataan Transact-SQL) tidak dikembalikan. Saat SET NOCOUNT MATI, hitungan dikembalikan. Ini digunakan dengan pernyataan SELECT, INSERT, UPDATE, DELETE.

  • Pengaturan SET NOCOUNT diatur pada saat dijalankan atau dijalankan dan tidak pada waktu parse.

  • SET NOCOUNT ON meningkatkan kinerja prosedur tersimpan (SP).

  • Sintaks: SET NOCOUNT {ON | MATI }

Contoh SET NOCOUNT ON:

masukkan deskripsi gambar di sini

Contoh SET NOCOUNT MATI:

masukkan deskripsi gambar di sini


7
Mudah dan Cepat dimengerti dengan tangkapan layar. Kerja bagus. :)
shaijut

35

Saya kira sampai tingkat tertentu itu adalah masalah DBA vs pengembang.

Sebagai seorang pengembang, saya katakan jangan menggunakannya kecuali Anda benar-benar harus - karena menggunakannya dapat merusak kode ADO.NET Anda (seperti yang didokumentasikan oleh Microsoft).

Dan saya kira sebagai DBA, Anda akan lebih di sisi lain - menggunakannya kapan pun memungkinkan kecuali Anda benar-benar harus mencegah penggunaannya.

Juga, jika devs Anda pernah menggunakan "RecordsAffected" yang dikembalikan oleh ExecuteNonQuerypemanggilan metode ADO.NET , Anda dalam masalah jika semua orang menggunakan SET NOCOUNT ONkarena dalam kasus ini, ExecuteNonQuery akan selalu mengembalikan 0.

Juga lihat posting blog Peter Bromberg dan periksa posisinya.

Jadi itu benar-benar bermuara pada siapa yang harus menetapkan standar :-)

Marc


Dia terus tentang CRUD sederhana meskipun: data grid ia menyebutkan bisa menggunakan xml untuk mengirim beberapa baris untuk menghindari perjalanan putaran dll
gbn

Saya kira jika Anda tidak pernah menggunakan SqlDataAdapters, dan Anda tidak pernah memeriksa dan mengandalkan nomor "catatan yang terpengaruh" yang dikembalikan oleh ExecuteNonQuery (misalnya jika Anda menggunakan sesuatu seperti Linq-to-SQL atau NHibernate), maka Anda mungkin tidak memiliki masalah menggunakan SET NOCOUNT ON di semua procs yang disimpan.
marc_s

12

Jika Anda mengatakan Anda mungkin memiliki klien yang berbeda juga, ada masalah dengan ADO klasik jika SET NOCOUNT tidak diset ON.

Satu yang saya alami secara teratur: jika prosedur tersimpan mengeksekusi sejumlah pernyataan (dan dengan demikian sejumlah pesan "baris xxx terpengaruh" dikembalikan), ADO tampaknya tidak menangani ini dan melempar kesalahan "Tidak dapat mengubah properti ActiveConnection dari objek Recordset. yang memiliki objek Command sebagai sumbernya. "

Jadi saya biasanya menganjurkan pengaturan ON kecuali ada alasan yang sangat bagus untuk tidak melakukannya. Anda mungkin telah menemukan alasan yang sangat bagus yang perlu saya baca dan baca lebih lanjut.


9

Dengan risiko membuat segalanya lebih rumit, saya mendorong aturan yang sedikit berbeda dengan semua yang saya lihat di atas:

  • Selalu atur NOCOUNT ONdi bagian atas proc, sebelum Anda melakukan pekerjaan apa pun di proc, tetapi juga selalu SET NOCOUNT OFFlagi, sebelum mengembalikan semua recordset dari proc yang disimpan.

Jadi "umumnya tetap nocount aktif, kecuali ketika Anda benar-benar mengembalikan resultset". Saya tidak tahu cara apa pun untuk memecahkan kode klien apa pun, itu berarti kode klien tidak perlu tahu apa-apa tentang internal proc, dan itu tidak terlalu memberatkan.


Terima kasih. Anda bisa mendapatkan rowcount dari DataSet atau tentu saja menggunakan wadah, tetapi bisa berguna. Kami tidak dapat memiliki pemicu pada SELECT jadi ini akan aman: sebagian besar kesalahan klien disebabkan oleh pesan palsu pada perubahan data.
gbn

Masalah dengan aturan ini adalah hanya lebih sulit untuk menguji daripada "Apakah SET NOCOUNT PADA DI bagian atas proc?"; Saya bertanya-tanya apakah alat Analisis SQL seperti Sql Enlight dapat menguji hal semacam itu ... Menambahkannya ke daftar todo jangka panjang saya untuk proyek formatter SQL saya :)
Tao

5

Mengenai pemicu melanggar NHibernate, saya memiliki pengalaman itu secara langsung. Pada dasarnya, ketika NH melakukan UPDATE, ia mengharapkan sejumlah baris yang terpengaruh. Dengan menambahkan SET NOCOUNT ON ke pemicu Anda mendapatkan jumlah baris kembali ke apa yang diharapkan NH sehingga memperbaiki masalah. Jadi ya, saya pasti akan merekomendasikan mematikannya untuk pemicu jika Anda menggunakan NH.

Mengenai penggunaan dalam SP, itu masalah preferensi pribadi. Saya selalu mematikan hitungan baris, tetapi sekali lagi, tidak ada argumen yang kuat.

Pada catatan yang berbeda, Anda harus benar-benar mempertimbangkan untuk pindah dari arsitektur berbasis SP, maka Anda bahkan tidak akan memiliki pertanyaan ini.


1
Saya tidak setuju dengan pindah dari procs yang disimpan. Ini berarti kita harus memiliki SQL yang sama dalam 2 basis kode klien yang berbeda dan mempercayai coders klien kami. Kami adalah pengembang DBA. Dan maksud Anda, "SET NOCOUNT ON "?
gbn

@ KodeBlend: hanya Google untuk lebih dari yang Anda butuhkan. Namun ... stackoverflow.com/a/4040466/27535
gbn

3

Saya ingin memverifikasi diri saya bahwa 'SET NOCOUNT ON' tidak menyimpan paket jaringan atau pulang-pergi

Saya menggunakan tes SQLServer 2017 pada host lain (saya menggunakan 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 Kemudian saya melacak paket pada port 1433 dengan alat 'Wireshark': tombol 'capture filter' -> 'port 1433'

exec procNoCount

ini adalah paket respons: 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

ini adalah paket respons: 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

Pada baris 40 saya dapat melihat '07' yang merupakan jumlah 'baris yang terpengaruh'. Itu termasuk dalam paket respons. Tidak ada paket tambahan.

Namun memiliki 13 byte tambahan yang dapat disimpan, tetapi mungkin tidak sepadan dengan mengurangi nama kolom (mis. 'Mengelola Departemen' menjadi 'MD')

Jadi saya tidak melihat alasan untuk menggunakannya untuk kinerja

NAMUN Seperti yang disebutkan orang lain itu bisa memecahkan ADO.NET dan saya juga menemukan masalah menggunakan python: MSSQL2008 - Pyodbc - SQL sebelumnya bukan permintaan

Jadi mungkin kebiasaan yang baik masih ...


1
SET NOCOUNT ON;

Baris kode ini digunakan dalam SQL untuk tidak mengembalikan baris nomor yang terpengaruh dalam pelaksanaan kueri. Jika kami tidak membutuhkan jumlah baris yang terpengaruh, kami dapat menggunakan ini karena ini akan membantu menghemat penggunaan memori dan meningkatkan kecepatan pelaksanaan kueri.


2
Perhatikan bahwa @@ ROWCOUNT masih disetel. SET NOCOUNT ON menekan setiap respons ekstra yang dikirim SQL Server ke klien. Lihat jawaban yang diterima di atas tolong
gbn

1

SET NOCOUNT AKTIF; Kode di atas akan menghentikan pesan yang dihasilkan oleh mesin server sql ke jendela hasil yang digawangi setelah eksekusi perintah DML / DDL.

Kenapa kita melakukannya? Karena mesin server SQL membutuhkan sumber daya untuk mendapatkan status dan menghasilkan pesan, itu dianggap sebagai beban berlebihan ke mesin server Sql.


1

Satu tempat yang SET NOCOUNT ONbisa sangat membantu adalah tempat Anda melakukan kueri dalam satu lingkaran atau kursor. Ini dapat menambah banyak lalu lintas jaringan.

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

Mengaktifkan statistik klien di SSMS, serangkaian EXEC NoCountOndan EXEC NoCountOffmenunjukkan bahwa ada lalu lintas tambahan 390KB di NoCountOff yang satu:

statistik klien

Mungkin tidak ideal untuk melakukan kueri dalam satu lingkaran atau kursor, tetapi kita juga tidak hidup di dunia ideal :)


0

Saya tahu itu pertanyaan yang cukup lama. tetapi hanya untuk pembaruan.

Cara terbaik untuk menggunakan "SET NOCOUNT ON" adalah dengan memasangnya sebagai pernyataan pertama dalam SP Anda dan mengaturnya MATI lagi tepat sebelum pernyataan SELECT terakhir.


-1

Saya tidak tahu cara menguji SET NOCOUNT ON antara klien dan SQL, jadi saya menguji perilaku serupa untuk perintah SET lainnya "SET TINGKAT ISOLASI TRANSAKSI BACA BACA TIDAK DIKETAHUI"

Saya mengirim perintah dari koneksi saya untuk mengubah perilaku standar SQL (READ COMMITTED), dan itu diubah untuk perintah selanjutnya. Ketika saya mengubah level ISOLASI di dalam prosedur tersimpan, itu tidak mengubah perilaku koneksi untuk perintah berikutnya.

Kesimpulan saat ini,

  1. Mengubah pengaturan di dalam prosedur tersimpan tidak mengubah pengaturan default koneksi.
  2. Mengubah pengaturan dengan mengirim perintah menggunakan ADOCOnnection mengubah perilaku default.

Saya pikir ini relevan dengan perintah SET lainnya seperti "SET NOCOUNT ON"


Apakah poin 1 di atas Anda menyiratkan bahwa Anda tidak benar-benar perlu SET NOCOUNT MATI pada akhirnya karena tidak mempengaruhi lingkungan global?
funkymushroom

Saya tidak yakin apakah itu yang dimaksud dengan poin 1, tetapi dalam pengujian saya ya, ternyata lingkungan global tidak terpengaruh oleh SET NOCOUNT ON di dalam prosedur tersimpan.
Doug

Ini adalah pilihan perbandingan yang buruk, karena Level Isolasi secara eksplisit terkait dengan transaksi tertentu, jadi tidak ada alasan khusus untuk mengharapkannya konsisten dengan pengaturan sepertiNOCOUNT
IMSoP

-1

if (set no count == off)

{maka ia akan menyimpan data tentang berapa banyak catatan yang terpengaruh sehingga mengurangi kinerja} selain itu {itu tidak akan melacak catatan perubahan karenanya meningkatkan kinerja}}


-1

Kadang-kadang bahkan hal-hal paling sederhana pun dapat membuat perbedaan. Salah satu item sederhana yang harus menjadi bagian dari setiap prosedur tersimpan adalah SET NOCOUNT ON. Baris kode yang satu ini, diletakkan di bagian atas prosedur yang tersimpan mematikan pesan yang SQL Server kirim kembali ke klien setelah setiap pernyataan T-SQL dijalankan. Ini dilakukan untuk semua SELECT, INSERT, UPDATE, dan DELETEpernyataan. Memiliki informasi ini berguna ketika Anda menjalankan pernyataan T-SQL di jendela kueri, tetapi ketika prosedur yang tersimpan dijalankan tidak perlu informasi ini diteruskan kembali ke klien.

Dengan menghapus overhead tambahan ini dari jaringan, ini dapat sangat meningkatkan kinerja keseluruhan untuk database dan aplikasi Anda.

Jika Anda masih perlu mendapatkan jumlah baris yang dipengaruhi oleh pernyataan T-SQL yang mengeksekusi Anda masih bisa menggunakan @@ROWCOUNTopsi. Dengan mengeluarkan SET NOCOUNT ONfungsi ini ( @@ROWCOUNT) masih berfungsi dan masih dapat digunakan dalam prosedur tersimpan Anda untuk mengidentifikasi berapa banyak baris yang dipengaruhi oleh pernyataan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.