Như chúng ta đã biết, READ UNCOMMITTED là mức cô lập thấp nhất trong đó những thứ như đọc bẩn và đọc ảo có thể tích lũy. Khi nào là thời điểm tốt nhất để sử dụng mức cô lập này và vì lý do gì nó có thể được sử dụng?
Thật ra tôi đã đọc câu trả lời trước đây, nhưng tôi không thể hiểu nó hoàn toàn vì không có đủ ví dụ.
Câu trả lời:
Tôi sử dụng READ_UNCOMMITTED(hoặc NOLOCK) khi truy vấn cơ sở dữ liệu sản xuất từ SSMS nhưng không thường xuyên từ mã ứng dụng. Thực tiễn này (cùng với gợi ý truy vấn MAXDOP 1) giúp đảm bảo các truy vấn ngẫu nhiên để phân tích dữ liệu và khắc phục sự cố không ảnh hưởng đến khối lượng công việc sản xuất, với sự hiểu biết kết quả có thể không chính xác.
Đáng buồn thay, tôi thấy READ_UNCOMMITTED/ NOLOCKđược sử dụng rộng rãi trong mã sản xuất để tránh bị chặn với chi phí toàn vẹn dữ liệu. Giải pháp thích hợp là mức cô lập phiên bản hàng ( SNAPSHOThoặc READ_COMMITTEDvới READ_COMMITTED_SNAPSHOTtùy chọn cơ sở dữ liệu ON) và / hoặc chú ý đến điều chỉnh truy vấn và chỉ mục.
Gần đây tôi đã xem lại một mã trong đó thay đổi duy nhất là xóa NOLOCKvì đôi khi nó trả về kết quả sai. Loại bỏ NOLOCKlà một điều tốt nhưng, biết rằng các hàng bị bỏ lỡ hoặc trùng lặp thường xảy ra trong quá trình quét thứ tự phân bổ của các bảng lớn, tôi cũng đề nghị tái cấu trúc để sử dụng một UNION ALLkỹ thuật để thúc đẩy sử dụng chỉ mục hiệu quả. Truy vấn hiện chạy trong vài mili giây với kết quả chính xác, tốt nhất trong tất cả các thế giới.
Tôi nghĩ rằng nó ổn trong một số trường hợp, miễn là bạn chấp nhận hậu quả và không có lựa chọn nào khác.
Đối với các tùy chọn khác, tôi sẽ hướng mọi người tới việc sử dụng Đọc cách ly Snapshot (RCSI) cho các ứng dụng mới hoặc SNAPSHOT ISOLATION (SI) cho các ứng dụng cũ hơn, nơi bạn không thể dễ dàng kiểm tra toàn bộ cơ sở mã cho các điều kiện chạy đua với RCSI.
Tuy nhiên, những thứ đó có thể không phù hợp. Bạn có thể cần dành thêm thời gian yêu thương và chăm sóc tempdb và đảm bảo không ai rời khỏi giao dịch mở khiến cửa hàng phiên bản (và tempdb) phát triển và lấp đầy đĩa.
Nếu bạn không có DBA hoặc ai đó có nhiệm vụ giám sát và quản lý Máy chủ SQL của bạn, các tùy chọn đó có thể rất nguy hiểm. Tổng quát hơn, không phải ai cũng có toàn quyền kiểm soát mã đến máy chủ của mình, nơi họ có thể thay đổi chuỗi kết nối hoặc mã để yêu cầu SI cho các truy vấn có vấn đề.
Ngoài ra, hầu hết mọi người không gặp vấn đề về khóa với toàn bộ ứng dụng của họ . Họ có vấn đề với những thứ như báo cáo về dữ liệu OLTP. Nếu bạn có thể chấp nhận sự đánh đổi của NOLOCK / RU để đổi lấy những báo cáo không bị chặn bởi các nhà văn, hãy thực hiện nó.
Chỉ cần chắc chắn rằng bạn hiểu điều đó có nghĩa là gì. Điều đó không có nghĩa là truy vấn của bạn không có bất kỳ khóa nào, điều đó có nghĩa là nó không tôn trọng các khóa được lấy bởi các truy vấn khác.
Và tất nhiên, nếu vấn đề của bạn là khóa nhà văn / nhà văn, tùy chọn duy nhất sẽ giúp là SI, nhưng sẽ cần một lượng công việc đáng kinh ngạc của nhà phát triển để thực hiện đúng cách xử lý lỗi, v.v.
IMHO trường hợp sử dụng hợp lệ duy nhất cho READ UNCOMMITTED trên một hệ thống hiện đại là khi gỡ lỗi một phiên từ phiên khác trong quá trình phát triển, vì vậy bạn có thể thấy nó đang làm gì trong khi ví dụ như một Proc được lưu trữ vẫn đang chạy. Nó thường sẽ không bao giờ được sử dụng trong một hệ thống sản xuất. Có thể có một số hiệu suất nhỏ đạt được nhưng về lâu dài nó sẽ không bao giờ có giá trị.
Chúng tôi sử dụng nó trong chăm sóc sức khỏe tất cả các thời gian.
Thật đáng ngạc nhiên khi các hàng dữ liệu riêng lẻ thay đổi truy vấn giữa và tỷ lệ đọc / ghi giống như 10.000 / 1 - và hầu hết chúng là các phần chèn, không phải là cập nhật. Ví dụ: khi giao diện phòng thí nghiệm ghi kết quả phòng thí nghiệm của bệnh nhân vào cơ sở dữ liệu, các giá trị đó sẽ không bao giờ thay đổi.
Khi dữ liệu không thay đổi, nó thay đổi một hàng tại một thời điểm. Không ai cập nhật toàn bộ các cột (ngoại trừ một DBA, khi chúng gây rối rất tệ).
Mặt khác, chúng tôi chạy một loạt các truy vấn để quét những thứ như bệnh nhân quay trở lại ER trong 72 giờ hoặc ít hơn, điều này hoàn toàn làm hỏng các bảng.
Trong 10 năm chăm sóc sức khỏe SQL, tôi chưa bao giờ thấy a Rollback Transaction. Tôi muốn vào và ra mà không làm gián đoạn trải nghiệm người dùng cuối. Nếu có nguy cơ cao làm chậm cơ sở dữ liệu OLTP và nguy cơ nhận dữ liệu xấu thấp, tôi sẽ NOLOCK.
Chúng ta có nên sử dụng nó? Co le không. Nói chung, tôi sẽ không nói rằng nhiều cơ sở dữ liệu ứng dụng mà tôi đã làm việc được thiết kế tốt. Họ thường bị nghẹt thở với đầy đủ các kiểu chống.
READ_UNCOMMITTED/NOLOCKlà một lựa chọn tốt khi độ chính xác của dữ liệu không thực sự là mục tiêu chính. Đôi khi khi tổng số gần đúng là tất cả những gì được yêu cầu. Ví dụ: Có các thủ tục được lưu trữ được sử dụng cho các bảng INSERT hoặc UPDATE. Đôi khi số lượng hồ sơ được cập nhật hoặc chèn vào là rất lớn (Hàng ngàn hồ sơ). Trong các lần chạy thủ tục được lưu trữ này, chúng ta có thể chạy một truy vấn chọn đơn giản vớiNOLOCK bảng đích theo định kỳ để xem liệu nó có tiến triển thuận lợi không (Đối với truy vấn cập nhật, nếu bạn có cột thay đổi trạng thái cho các bản ghi được cập nhật, chúng tôi có thể sử dụng cột đó để chạy group bytruy vấn với NOLOCKđể tìm xem số lượng thay đổi trạng thái liên tục thay đổi).
Xin lưu ý rằng READ UNCOMMITTED giới thiệu các vấn đề nhất quán bổ sung, không chỉ đọc bẩn. Tùy thuộc vào phương thức truy cập, bạn có thể bỏ lỡ các hàng hoặc thậm chí đọc cùng một hàng nhiều lần. Nếu bạn quan tâm đến các chi tiết, hãy đọc bài viết của Itzik Ben-Gan