Cấp độ cô lập không được chấp nhận đã đọc

Đọc không cam kết là mức yếu nhất trong bốn mức cách ly giao dịch được xác định trong Tiêu chuẩn SQL (và trong sáu mức được triển khai trong SQL Server). Nó cho phép cả ba cái gọi là "hiện tượng đồng thời", đọc bẩn , số lần đọc không lặp lại và bóng ma:

Hầu hết mọi người trong cơ sở dữ liệu đều nhận thức được những hiện tượng này, ít nhất là trong phác thảo, nhưng không phải ai cũng nhận ra rằng họ không mô tả đầy đủ các đảm bảo cô lập được cung cấp; cũng như không mô tả trực quan các hành vi khác nhau mà người ta có thể mong đợi trong một triển khai cụ thể như SQL Server. Tìm hiểu thêm về điều đó sau.

Cách ly giao dịch - chữ 'I' trong ACID

Mọi lệnh SQL thực thi trong một giao dịch (rõ ràng, ngầm định hoặc tự động cam kết). Mỗi giao dịch đều có một mức cô lập liên quan, xác định mức độ cô lập của nó với các tác động của các giao dịch đồng thời khác. Khái niệm có phần kỹ thuật này có ý nghĩa quan trọng đối với cách thực thi các truy vấn và chất lượng của kết quả mà chúng tạo ra.

Hãy xem xét một truy vấn đơn giản đếm tất cả các hàng trong một bảng. Nếu truy vấn này có thể được thực thi ngay lập tức (hoặc không có sửa đổi dữ liệu đồng thời), thì chỉ có thể có một câu trả lời đúng:số hàng hiện diện vật lý trong bảng tại thời điểm đó. Trên thực tế, việc thực thi truy vấn sẽ mất một khoảng thời gian nhất định và kết quả sẽ phụ thuộc vào số hàng mà công cụ thực thi thực sự gặp khi nó đi ngang qua bất kỳ cấu trúc vật lý nào được chọn để truy cập dữ liệu.

Nếu các hàng đang được thêm vào (hoặc bị xóa khỏi) bảng bởi các giao dịch đồng thời trong khi thao tác đếm đang diễn ra, thì các kết quả khác nhau có thể nhận được tùy thuộc vào việc liệu giao dịch đếm hàng có gặp phải tất cả, một số hay không có những thay đổi đồng thời đó - mà lần lượt phụ thuộc vào mức độ cô lập của giao dịch đếm hàng.

Tùy thuộc vào mức độ cô lập, chi tiết vật lý và thời gian của các hoạt động đồng thời, giao dịch đếm của chúng tôi thậm chí có thể tạo ra kết quả không bao giờ phản ánh đúng trạng thái đã cam kết của bảng tại bất kỳ thời điểm nào trong quá trình giao dịch.

Ví dụ

Hãy xem xét một giao dịch đếm hàng bắt đầu tại thời điểm T1 và quét bảng từ đầu đến cuối (theo thứ tự khóa chỉ mục được phân cụm, để đối số). Tại thời điểm đó, có 100 hàng được cam kết trong bảng. Một thời gian sau (tại thời điểm T2), giao dịch đếm của chúng tôi đã gặp phải 50 hàng trong số đó. Đồng thời, một giao dịch đồng thời sẽ chèn hai hàng vào bảng và cam kết một thời gian ngắn sau đó tại thời điểm T3 (trước khi giao dịch đếm kết thúc). Một trong các hàng được chèn sẽ nằm trong một nửa của cấu trúc chỉ mục nhóm mà giao dịch đếm của chúng tôi đã xử lý, trong khi hàng được chèn khác nằm trong phần chưa được đếm.

Khi giao dịch đếm hàng hoàn tất, nó sẽ báo cáo 101 hàng trong trường hợp này; 100 hàng ban đầu trong bảng cộng với một hàng được chèn duy nhất gặp phải trong quá trình quét. Kết quả này trái ngược với lịch sử cam kết của bảng:có 100 hàng được cam kết tại thời điểm T1 và T2, sau đó là 102 hàng được cam kết tại thời điểm T3. Chưa bao giờ có thời điểm có 101 hàng được cam kết.

Điều đáng ngạc nhiên (có lẽ, tùy thuộc vào mức độ bạn đã suy nghĩ sâu sắc về những điều này trước đây) là kết quả này có thể xảy ra ở mức cách ly đã cam kết đọc (khóa) mặc định, và thậm chí trong điều kiện cách ly đọc lặp lại. Cả hai mức cách ly đó đều được đảm bảo chỉ đọc dữ liệu đã cam kết, nhưng chúng tôi đã thu được kết quả không đại diện cho trạng thái đã cam kết của cơ sở dữ liệu!

Phân tích

Mức cách ly giao dịch duy nhất cung cấp khả năng cách ly hoàn toàn khỏi các hiệu ứng đồng thời là có thể tuần tự hóa. Việc triển khai SQL Server ở mức cách ly có thể tuần tự hóa có nghĩa là một giao dịch sẽ thấy dữ liệu được cam kết mới nhất, kể từ thời điểm dữ liệu bị khóa để truy cập lần đầu tiên. Ngoài ra, tập hợp dữ liệu gặp phải trong điều kiện cách ly có thể tuần tự hóa được đảm bảo không thay đổi tư cách thành viên trước khi giao dịch kết thúc.

Ví dụ đếm hàng nêu bật khía cạnh cơ bản của lý thuyết cơ sở dữ liệu:chúng ta cần hiểu rõ về ý nghĩa của một kết quả "đúng" đối với một cơ sở dữ liệu trải qua các sửa đổi đồng thời và chúng ta cần hiểu những đánh đổi mà chúng ta đang thực hiện khi chọn một sự tách biệt thấp hơn mức có thể tuần tự hóa.

Nếu chúng ta cần chế độ xem tại thời điểm về trạng thái đã cam kết của cơ sở dữ liệu, chúng ta nên sử dụng cách ly ảnh chụp nhanh (đối với bảo đảm cấp giao dịch) hoặc đọc cách ly ảnh chụp nhanh đã cam kết (đối với đảm bảo cấp tuyên bố). Xin lưu ý rằng chế độ xem điểm trong thời gian có nghĩa là chúng ta không nhất thiết phải hoạt động trên trạng thái đã cam kết hiện tại của cơ sở dữ liệu; trên thực tế, chúng tôi có thể đang sử dụng thông tin lỗi thời. Mặt khác, nếu chúng tôi hài lòng với kết quả chỉ dựa trên dữ liệu đã cam kết (mặc dù có thể từ các thời điểm khác nhau), chúng tôi có thể chọn gắn bó với mức cách ly đã cam kết đã đọc khóa mặc định.

Để đảm bảo tạo ra kết quả (và đưa ra quyết định!) Dựa trên tập dữ liệu đã cam kết mới nhất, đối với một số lịch sử nối tiếp của các hoạt động dựa trên cơ sở dữ liệu, chúng tôi cần cách ly giao dịch có thể tuần tự hóa. Tất nhiên tùy chọn này thường đắt nhất về sử dụng tài nguyên và tính đồng thời giảm (bao gồm nguy cơ bế tắc cao).

Trong ví dụ đếm hàng, cả hai mức cách ly ảnh chụp nhanh (SI và RCSI) sẽ cho kết quả là 100 hàng, đại diện cho số hàng đã cam kết ở đầu câu lệnh (và giao dịch trong trường hợp này). Chạy truy vấn khi khóa cách ly đọc đã cam kết hoặc đọc lặp lại có thể tạo ra kết quả là 100, 101 hoặc 102 hàng - tùy thuộc vào thời gian, mức độ chi tiết của khóa, vị trí chèn hàng và phương pháp truy cập vật lý đã chọn. Trong điều kiện cách ly có thể tuần tự hóa, kết quả sẽ là 100 hoặc 102 hàng, tùy thuộc vào giao dịch nào trong số hai giao dịch đồng thời được coi là đã thực hiện trước.

Đọc không được chấp nhận tệ đến mức nào?

Đã giới thiệu cách ly đọc không cam kết là mức yếu nhất trong số các mức cách ly hiện có, bạn nên mong đợi nó cung cấp các đảm bảo cách ly thậm chí còn thấp hơn so với khóa đã cam kết đọc (mức cách ly cao nhất tiếp theo). Thật vậy, nó có; nhưng câu hỏi đặt ra là:nó tệ hơn bao nhiêu so với việc khóa cách ly đã đọc được cam kết?

Để chúng tôi bắt đầu với ngữ cảnh chính xác, đây là danh sách các hiệu ứng đồng thời chính có thể gặp phải trong mức độ cô lập đã cam kết đọc khóa đã cam kết trong SQL Server:

• Thiếu các hàng đã cam kết
• Các hàng gặp nhiều lần
• Gặp phải các phiên bản khác nhau của cùng một hàng trong một câu lệnh / kế hoạch truy vấn
• Dữ liệu cột được cam kết từ các thời điểm khác nhau trong cùng một hàng (ví dụ)

Tất cả các hiệu ứng đồng thời này đều là do việc triển khai khóa cam kết đọc chỉ thực hiện các khóa chia sẻ rất ngắn hạn khi đọc dữ liệu. Mức cô lập không cam kết đọc còn tiến thêm một bước nữa, bằng cách hoàn toàn không sử dụng các khóa dùng chung, dẫn đến khả năng bổ sung là "đọc bẩn".

Số lần đọc bẩn

Xin nhắc lại nhanh, "đọc bẩn" đề cập đến việc đọc dữ liệu đang được thay đổi bởi một giao dịch đồng thời khác (trong đó "thay đổi" kết hợp các thao tác chèn, cập nhật, xóa và hợp nhất). Nói một cách khác, việc đọc sai xảy ra khi một giao dịch đọc dữ liệu mà một giao dịch khác đã sửa đổi, trước khi giao dịch sửa đổi đã cam kết hoặc hủy bỏ những thay đổi đó.

Ưu điểm và Nhược điểm

Ưu điểm chính của cách ly không cam kết đọc là giảm khả năng bị chặn và khóa do các khóa không tương thích (bao gồm cả việc chặn không cần thiết do khóa leo thang) và có thể tăng hiệu suất (bằng cách tránh nhu cầu lấy và giải phóng các khóa dùng chung).

Hạn chế tiềm ẩn rõ ràng nhất của việc đọc cách ly không cam kết là (như tên cho thấy) là chúng ta có thể đọc dữ liệu không cam kết (ngay cả dữ liệu không bao giờ cam kết, trong trường hợp hoàn trả giao dịch). Trong một cơ sở dữ liệu mà việc khôi phục là tương đối hiếm, câu hỏi về việc đọc dữ liệu không được cam kết có thể được coi là một vấn đề về thời gian đơn thuần, vì dữ liệu được đề cập chắc chắn sẽ được cam kết ở một số giai đoạn và có thể là khá sớm. Chúng tôi đã thấy sự mâu thuẫn liên quan đến thời gian trong ví dụ đếm hàng (đang hoạt động ở mức cô lập cao hơn), vì vậy, người ta có thể đặt câu hỏi về mức độ lo lắng khi đọc dữ liệu "quá sớm".

Rõ ràng câu trả lời phụ thuộc vào các ưu tiên và bối cảnh của địa phương, nhưng một quyết định sáng suốt để sử dụng cách ly đọc không cam kết chắc chắn có vẻ khả thi. Có nhiều điều để suy nghĩ mặc dù. Việc triển khai SQL Server của mức cô lập không cam kết đọc bao gồm một số hành vi tinh vi mà chúng ta cần phải biết trước khi đưa ra "lựa chọn sáng suốt".

Bản quét đơn hàng phân bổ

Việc sử dụng cách ly không cam kết đọc được SQL Server coi như một tín hiệu cho thấy chúng tôi đã sẵn sàng chấp nhận những mâu thuẫn có thể phát sinh do kết quả của quá trình quét theo thứ tự cấp phát.

Thông thường, công cụ lưu trữ chỉ có thể chọn quét theo thứ tự phân bổ nếu dữ liệu cơ bản được đảm bảo không thay đổi trong quá trình quét (ví dụ:vì cơ sở dữ liệu ở chế độ chỉ đọc hoặc một gợi ý khóa bảng đã được chỉ định). Tuy nhiên, khi sử dụng tính năng cô lập không cam kết đọc, công cụ lưu trữ vẫn có thể chọn quét theo thứ tự phân bổ ngay cả khi dữ liệu cơ bản có thể bị sửa đổi bởi các giao dịch đồng thời.

Trong những trường hợp này, quá trình quét theo thứ tự phân bổ có thể bỏ sót hoàn toàn một số dữ liệu đã cam kết hoặc gặp phải dữ liệu đã cam kết khác nhiều lần. Nhấn mạnh vào việc thiếu hoặc đếm hai lần cam kết dữ liệu (không đọc dữ liệu không được cam kết) vì vậy nó không phải là trường hợp "đọc bẩn" như vậy. Quyết định thiết kế này (để cho phép quét theo thứ tự phân bổ trong chế độ cô lập không cam kết đã đọc) được một số người coi là khá gây tranh cãi.

Như một lời cảnh báo trước, tôi nên rõ ràng rằng rủi ro tổng quát hơn về việc thiếu hoặc đếm kép các hàng đã cam kết không bị giới hạn khi đọc cách ly không cam kết. Chắc chắn có thể thấy các hiệu ứng tương tự khi khóa đọc cam kết và đọc lặp lại (như chúng ta đã thấy trước đó) nhưng điều này xảy ra thông qua một cơ chế khác. Thiếu các hàng đã cam kết hoặc gặp phải chúng nhiều lần do quá trình quét theo thứ tự phân bổ đối với việc thay đổi dữ liệu dành riêng cho việc sử dụng cách ly đọc không cam kết.

Đọc dữ liệu "hỏng"

Các kết quả dường như thách thức logic (và thậm chí kiểm tra các ràng buộc!) Có thể xảy ra khi khóa cô lập đã đọc cam kết (một lần nữa, hãy xem bài viết này của Craig Freedman để biết một số ví dụ). Tóm lại, điểm mấu chốt là khóa đã cam kết đọc có thể xem dữ liệu đã cam kết từ các điểm khác nhau trong thời gian - ngay cả đối với một hàng, ví dụ:nếu kế hoạch truy vấn sử dụng các kỹ thuật như giao điểm chỉ mục.

Những kết quả này có thể không mong đợi, nhưng chúng hoàn toàn phù hợp với đảm bảo chỉ đọc dữ liệu đã cam kết. Không có gì tránh khỏi thực tế là đảm bảo tính nhất quán của dữ liệu cao hơn đòi hỏi mức độ cách ly cao hơn.

Những ví dụ đó thậm chí có thể khá sốc, nếu bạn chưa nhìn thấy chúng trước đây. Tất nhiên, các kết quả tương tự cũng có thể xảy ra khi đọc cách ly không cam kết, nhưng việc cho phép đọc bẩn sẽ bổ sung thêm một khía cạnh:kết quả có thể bao gồm dữ liệu đã cam kết và không cam kết từ các thời điểm khác nhau, ngay cả đối với cùng một hàng.

Đi xa hơn, thậm chí có thể cho một giao dịch không cam kết đã đọc đọc một giá trị cột đơn lẻ ở trạng thái hỗn hợp của dữ liệu được cam kết và không được cam kết. Điều này có thể xảy ra khi đọc giá trị LOB (ví dụ:xml hoặc bất kỳ loại 'tối đa' nào) nếu giá trị được lưu trữ trên nhiều trang dữ liệu. Một lần đọc không cam kết có thể gặp phải dữ liệu được cam kết hoặc không được cam kết từ các thời điểm khác nhau trên các trang khác nhau, dẫn đến giá trị cột đơn cuối cùng là hỗn hợp các giá trị!

Để lấy một ví dụ, hãy xem xét một cột varchar (tối đa) ban đầu chứa 10.000 ký tự 'x'. Một giao dịch đồng thời cập nhật giá trị này thành 10.000 ký tự 'y'. Một giao dịch không cam kết đã đọc có thể đọc các ký tự 'x' từ một trang của LOB và các ký tự 'y' từ một trang khác, dẫn đến giá trị đọc cuối cùng chứa hỗn hợp các ký tự 'x' và 'y'. Khó có thể lập luận rằng điều này không thể hiện việc đọc dữ liệu "bị hỏng".

Bản trình diễn

Tạo một bảng được phân nhóm với một hàng dữ liệu LOB:

CREATE TABLE dbo.Test
(
    RowID integer PRIMARY KEY,
    LOB varchar(max) NOT NULL,
);
 
INSERT dbo.Test
    (RowID, LOB)
VALUES
    (1, REPLICATE(CONVERT(varchar(max), 'X'), 16100));

Trong một phiên riêng biệt, hãy chạy tập lệnh sau để đọc giá trị LOB khi đọc cách ly không cam kết:

-- Run this in session 2
SET NOCOUNT ON;
 
DECLARE 
    @ValueRead varchar(max) = '',
    @AllXs varchar(max) = REPLICATE(CONVERT(varchar(max), 'X'), 16100),
    @AllYs varchar(max) = REPLICATE(CONVERT(varchar(max), 'Y'), 16100);
 
WHILE 1 = 1
BEGIN
    SELECT @ValueRead = T.LOB
    FROM dbo.Test AS T WITH (READUNCOMMITTED)
    WHERE T.RowID = 1;
 
    IF @ValueRead NOT IN (@AllXs, @AllYs)
    BEGIN
    	PRINT LEFT(@ValueRead, 8000);
        PRINT RIGHT(@ValueRead, 8000);
        BREAK;
    END
END;

Trong phiên đầu tiên, hãy chạy tập lệnh này để ghi các giá trị xen kẽ vào cột LOB:

-- Run this in session 1
SET NOCOUNT ON;
 
DECLARE 
    @AllXs varchar(max) = REPLICATE(CONVERT(varchar(max), 'X'), 16100),
    @AllYs varchar(max) = REPLICATE(CONVERT(varchar(max), 'Y'), 16100);
 
WHILE 1 = 1
BEGIN
    UPDATE dbo.Test
    SET LOB = @AllYs
    WHERE RowID = 1;
 
    UPDATE dbo.Test
    SET LOB = @AllXs
    WHERE RowID = 1;
END;

Sau một thời gian ngắn, tập lệnh trong phiên hai sẽ kết thúc, sau khi đọc trạng thái hỗn hợp cho giá trị LOB, ví dụ:

Vấn đề cụ thể này chỉ giới hạn ở các lần đọc các giá trị cột LOB trải rộng trên nhiều trang, không phải do bất kỳ đảm bảo nào được cung cấp bởi mức cách ly, mà vì SQL Server sử dụng chốt cấp trang để đảm bảo tính toàn vẹn vật lý. Một tác dụng phụ của chi tiết triển khai này là nó ngăn việc đọc dữ liệu "bị hỏng" đó nếu dữ liệu cho một thao tác đọc duy nhất xảy ra nằm trên một trang.

Tùy thuộc vào phiên bản SQL Server bạn có, nếu dữ liệu "trạng thái hỗn hợp" được đọc cho cột xml, bạn sẽ gặp lỗi do kết quả xml có thể không đúng định dạng, không có lỗi nào hoặc lỗi không xác định cụ thể 601 , "không thể tiếp tục quét bằng NOLOCK do di chuyển dữ liệu." Việc đọc dữ liệu trạng thái hỗn hợp cho các loại LOB khác thường không dẫn đến thông báo lỗi; ứng dụng hoặc truy vấn tiêu thụ không có cách nào để biết nó vừa trải qua kiểu đọc bẩn tồi tệ nhất. Để hoàn thành phân tích, hàng trạng thái hỗn hợp không LOB được đọc do kết quả của giao điểm chỉ mục không bao giờ được báo cáo là lỗi.

Thông báo ở đây là nếu bạn sử dụng cách ly đọc không cam kết, bạn chấp nhận rằng các lần đọc bẩn bao gồm khả năng đọc các giá trị LOB trạng thái hỗn hợp "bị hỏng".

Gợi ý NOLOCK

Tôi cho rằng không có cuộc thảo luận nào về mức độ cô lập không cam kết đã đọc sẽ hoàn tất nếu không ít nhất đề cập đến gợi ý bảng này (bị lạm dụng rộng rãi và bị hiểu nhầm). Bản thân gợi ý chỉ là một từ đồng nghĩa của gợi ý bảng READUNCOMMITTED. Nó thực hiện chính xác cùng một chức năng:đối tượng mà nó được áp dụng được truy cập bằng cách sử dụng đọc ngữ nghĩa cách ly không cam kết (mặc dù có một ngoại lệ).

Theo như tên "NOLOCK" có liên quan, nó chỉ đơn giản có nghĩa là không có khóa chia sẻ nào được thực hiện khi đọc dữ liệu . Các khóa khác (độ ổn định của lược đồ, khóa dành riêng cho việc sửa đổi dữ liệu, v.v.) vẫn được sử dụng như bình thường.

Nói chung, các gợi ý NOLOCK sẽ phổ biến như các gợi ý bảng mức cô lập cho mỗi đối tượng khác như SERIALIZABLE và READCOMMITTEDLOCK. Điều đó có nghĩa là:không phổ biến chút nào và chỉ được sử dụng khi không có giải pháp thay thế tốt, mục đích được xác định rõ ràng và hoàn chỉnh hiểu biết về hậu quả.

Một ví dụ về việc sử dụng hợp pháp NOLOCK (hoặc READUNCOMMITTED) là khi truy cập DMV hoặc các chế độ xem hệ thống khác, trong đó mức cách ly cao hơn có thể gây ra tranh cãi không mong muốn về cấu trúc dữ liệu không phải của người dùng. Một ví dụ về trường hợp cạnh khác có thể là nơi truy vấn cần truy cập một phần quan trọng của bảng lớn, được đảm bảo không bao giờ gặp phải các thay đổi dữ liệu trong khi truy vấn gợi ý đang thực thi. Thay vào đó, cần phải có lý do chính đáng để không sử dụng snapshot hoặc đọc snapshot đã cam kết cách ly và việc tăng hiệu suất dự kiến ​​sẽ cần phải được kiểm tra, xác thực và so sánh với, chẳng hạn như sử dụng một gợi ý khóa bảng chia sẻ duy nhất.

Cách sử dụng NOLOCK ít được mong muốn nhất là cách không may lại phổ biến nhất:áp dụng nó cho mọi đối tượng trong một truy vấn như một loại công tắc kỳ diệu nhanh hơn. Với ý chí tốt nhất trên thế giới, không có cách nào tốt hơn để làm cho mã SQL Server trông rất nghiệp dư. Nếu bạn cần đọc cách ly không cam kết một cách hợp pháp cho một truy vấn, khối mã hoặc mô-đun, có lẽ tốt hơn là nên đặt mức cách ly phiên một cách thích hợp và cung cấp các nhận xét để biện minh cho hành động.

Lời kết

Đọc không cam kết là một lựa chọn hợp pháp cho mức cô lập giao dịch, nhưng nó cần phải là một lựa chọn sáng suốt. Xin nhắc lại, đây là một số hiện tượng đồng thời có thể xảy ra trong SQL Server mặc định khóa đọc được cam kết cách ly:

• Thiếu các hàng đã cam kết trước đó
• Gặp phải các hàng đã cam kết nhiều lần
• Các phiên bản đã cam kết khác nhau của cùng một hàng gặp phải trong một câu lệnh / kế hoạch truy vấn
• Dữ liệu được cam kết từ các thời điểm khác nhau trong cùng một hàng (nhưng các cột khác nhau)
• Các lần đọc dữ liệu đã cam kết dường như mâu thuẫn với các ràng buộc đã bật và đã kiểm tra

Tùy thuộc vào quan điểm của bạn, đó có thể là một danh sách khá gây sốc về những mâu thuẫn có thể xảy ra đối với mức cô lập mặc định. Đối với danh sách đó, hãy đọc thêm phần cô lập không cam kết:

• Lần đọc bẩn (gặp phải dữ liệu chưa và có thể không bao giờ được cam kết)
• Các hàng chứa hỗn hợp dữ liệu đã cam kết và chưa cam kết
• Các hàng bị thiếu / trùng lặp do quét theo thứ tự phân bổ
• Các giá trị LOB riêng lẻ (một cột) ở trạng thái hỗn hợp ("bị hỏng")
• Lỗi 601 - "không thể tiếp tục quét bằng NOLOCK do di chuyển dữ liệu" (ví dụ).

Nếu mối quan tâm giao dịch chính của bạn là về tác dụng phụ của việc khóa cách ly cam kết đọc - chặn, khóa chi phí, giảm đồng thời do khóa leo thang, v.v. - bạn có thể được phục vụ tốt hơn bởi cấp độ cách ly phân tích phiên bản hàng như cách ly ảnh chụp nhanh đã cam kết đọc (RCSI) hoặc cách ly ảnh chụp nhanh (SI). Tuy nhiên, những thứ này không miễn phí và các bản cập nhật theo RCSI nói riêng có một số hành vi phản trực giác.

Đối với các tình huống yêu cầu mức độ đảm bảo nhất quán cao nhất, có thể tuần tự hóa vẫn là lựa chọn an toàn duy nhất. Đối với các hoạt động quan trọng về hiệu suất trên dữ liệu chỉ đọc (ví dụ:cơ sở dữ liệu lớn chỉ đọc hiệu quả giữa các cửa sổ ETL), việc đặt cơ sở dữ liệu thành READ_ONLY rõ ràng cũng có thể là một lựa chọn tốt (khóa chia sẻ không được thực hiện khi cơ sở dữ liệu chỉ đọc và không có nguy cơ mâu thuẫn).

Cũng sẽ có một số lượng tương đối nhỏ các ứng dụng mà việc đọc cách ly không cam kết là lựa chọn phù hợp. Các ứng dụng này cần hài lòng với kết quả gần đúng và khả năng đôi khi không nhất quán, dường như không hợp lệ (về mặt ràng buộc) hoặc dữ liệu "được cho là bị hỏng". Nếu dữ liệu thay đổi tương đối không thường xuyên, nguy cơ xảy ra những mâu thuẫn này cũng thấp hơn.