Perhatikan bahwa Anda dapat menentukan nolock pada basis per tabel.
Saya biasanya menggunakan nolock dalam kueri SELECT yang kompleks, tetapi hanya untuk tabel pencarian kecil yang hampir tidak pernah berubah, dan untuk data hanya tampilan. Anda tahu tabel yang mencantumkan harga untuk setengah tahun saat ini, atau pencarian id ke string dll. Hal-hal yang hanya berubah dengan pembaruan besar setelah itu server biasanya dimulai ulang secara rutin.
Ini meningkatkan kinerja secara signifikan, mengurangi kemungkinan kebuntuan di waktu tersibuk, dan yang lebih penting itu benar-benar terlihat selama saat-saat terburuk untuk kueri yang menyentuh banyak tabel (yang logis, mereka harus mendapatkan lebih sedikit kunci, dan sidetable tersebut sering digunakan hampir di mana-mana, sering menurun dari 7-8 menjadi 4 tabel yang perlu dikunci)
Tapi hati-hati menambahkannya, jangan terburu-buru, dan jangan lakukan secara rutin. Tidak akan sakit jika digunakan dengan benar, tetapi akan sangat sakit jika digunakan dengan tidak benar.
Jangan menggunakannya untuk hal-hal yang sangat kritis, hal-hal yang menghitung, dll, karena akan menjadi tidak konsisten, apa pun yang mengarah ke penulisan cepat atau lambat.
Pengoptimalan lainnya adalah ROWLOCK, yang hanya mengunci pada level baris. Ini terutama berguna saat memperbarui (atau menghapus) tabel di mana baris tidak terkait satu sama lain, seperti tabel di mana Anda hanya memasukkan catatan log (dan urutan penyisipannya tidak menjadi masalah). Jika Anda memiliki skema bahwa di suatu tempat di akhir transaksi, catatan log ditulis ke beberapa tabel, ini juga dapat mempercepatnya.
Jika basis data Anda memiliki persentase penulisan yang relatif rendah, itu mungkin tidak sepadan. Saya memiliki rasio baca:tulis di bawah 2:1.
Beberapa URL yang saya simpan saat mengerjakan ini:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/
