InnoDB isolation level và MVCC: chọn READ COMMITTED hay REPEATABLE READ cho web application thế nào?

Chào bạn Minh Tâm, Isolation level không phải nút “nhanh hơn/an toàn hơn” chung cho mọi ứng dụng. Nó quyết định những quan sát mà transaction được phép thấy và cách database phối hợp concurrent read/write. InnoDB dùng MVCC để hỗ trợ consistent read, nhưng transaction dài vẫn khiến hệ thống phải giữ/khôi phục phiên bản cũ lâu hơn. Cách chọn nên bắt đầu từ invariant nghiệp vụ và truy vấn thực: 1. Liệt kê use case cần snapshot nhất quán trong một transaction, use case nào chỉ cần dữ liệu mới nhất chấp nhận được và use case nào phải khóa để tránh ghi đè/oversell. 2. Giữ transaction ngắn, không chờ HTTP/email/user input khi transaction đang mở. Đây thường là cải thiện quan trọng hơn đổi isolation level. 3. Với thao tác cần serialize/giữ invariants, dùng điều kiện update nguyên tử hoặc locking read có chủ đích; không hy vọng isolation mặc định tự sửa race condition do application read-then-write. 4. Kiểm thử concurrency bằng nhiều request thật, theo dõi lock wait/deadlock và xác minh kết quả cuối cùng chứ không chỉ xem từng request có trả 200 hay không. 5. Nếu thay isolation level, thực hiện theo phạm vi nhỏ, đo lại và document behavior được chấp nhận; đừng đổi global chỉ để xử lý một endpoint. Deadlock vẫn có thể xuất hiện trong các write transaction. Application cần xử lý retry có giới hạn cho lỗi transient/idempotent, đồng thời dùng log để cải thiện thứ tự lock và transaction scope. Tham khảo: MySQL InnoDB multi-versioning, transaction management và deadlocks documentation.

Tôi hiểu nỗi đau khi chứng kiến hai request cập nhật/đọc xung đột ngay trên cùng một bản ghi. Trong các ứng dụng web điển hình, bạn thường gặp hai mẫu chính: * **Giao dịch ngắn** – một request lấy dữ liệu, xử lý một chút và ghi lại. Với những giao dịch này, READ COMMITTED thường là lựa chọn tối ưu: bạn tránh được phần lớn lock đi kèm REPEATABLE READ, trong khi vẫn đảm bảo bạn đọc dữ liệu đã được cam kết, và bạn chấp nhận khả năng kết quả có thể thay đổi nếu cùng một bản ghi được ghi trong cùng một phiên (non‑repeatable read) – điều này hiếm khi gây ra vấn đề nghiêm trọng. * **Giao dịch dài / batch job** – xử lý nhiều bước, cần tính nhất quán trên nhiều bảng. Ở đây REPEATABLE READ bảo vệ bạn khỏi các lần đọc lại bị thay đổi trong cùng một phiên, nhưng bạn phải đánh đổi bằng việc khóa nhiều hơn. Nếu hầu hết các request của bạn đều là CRUD độc lập, hãy thử chuyển sang READ COMMITTED trước, theo dõi tình trạng “đọc lại” và hiệu năng. Khi nào thì bạn gặp phải các trường hợp ngoại lệ khiến bạn cần tính nhất quán lặp lại?

Tôi hiểu nỗi đau khi phải quyết định giữa REPEATABLE READ và READ COMMITTED cho ứng dụng web. REPEATABLE READ bảo vệ bạn khỏi hiện tượng non‑repeatable read (cùng một truy vấn có thể thấy các phiên bản khác nhau trong cùng một giao dịch dài) và đảm bảo tính nhất quán cho các báo cáo, nhưng nó cũng giữ khóa trên các hàng đã đọc lâu hơn, điều này có thể gây ra hiện tượng deadlock trong các tác vụ cập nhật-đọc song song. READ COMMITTED nới lỏng điều này – bạn chỉ nhìn thấy dữ liệu đã được cam kết và giải phóng khóa sau khi hoàn tất quá trình quét, giúp giảm xung đột và cải thiện khả năng mở rộng, mặc dù bạn phải chấp nhận khả năng một truy vấn có thể thấy các thay đổi trong các lần thực hiện tiếp theo. Đối với hầu hết các thao tác CRUD thông thường, READ COMMITTED là lựa chọn