Trước khi làm việc trên Stack Overflow, tôi đã chống lại NOLOCK về nguyên tắc mà bạn có thể thực hiện SELECT với NOLOCK và nhận lại kết quả với dữ liệu có thể đã lỗi thời hoặc không nhất quán. Một yếu tố cần suy nghĩ là có bao nhiêu bản ghi có thể được chèn / cập nhật cùng lúc một quá trình khác có thể đang chọn dữ liệu từ cùng một bảng. Nếu điều này xảy ra nhiều thì có khả năng cao xảy ra deadlock trừ khi bạn sử dụng chế độ cơ sở dữ liệu như READ COMMITED SNAPSHOT .
Kể từ đó, tôi đã thay đổi quan điểm của mình về việc sử dụng NOLOCK sau khi chứng kiến cách nó có thể cải thiện SELECT hiệu suất cũng như loại bỏ các bế tắc trên SQL Server được tải lớn. Đôi khi bạn có thể không quan tâm rằng dữ liệu của bạn không được cam kết chính xác 100% và bạn cần kết quả nhanh chóng trở lại ngay cả khi chúng có thể đã lỗi thời.
Hãy tự hỏi bản thân khi nghĩ đến việc sử dụng NOLOCK :
Truy vấn của tôi có bao gồm một bảng có số lượng
INSERTcao không /UPDATEvà tôi có quan tâm nếu dữ liệu trả về từ một truy vấn có thể bị thiếu những thay đổi này tại một thời điểm nhất định không?
Nếu câu trả lời là không, hãy sử dụng NOLOCK để cải thiện hiệu suất.
NOLOCK từ khóa trong cơ sở mã cho Stack Overflow và tìm thấy 138 trường hợp, vì vậy chúng tôi sử dụng nó ở một số nơi. 
