Cơ sở dữ liệu quan hệ là một trong những hệ quản trị cơ sở dữ liệu phổ biến nhất trong thế giới lập trình. Chúng ta ai cũng có 1 lần va chạm với cơ sở dữ liệu quan hệ nhưng không phải ai cũng hiểu hết về chúng. Hôm nay tôi và bạn cùng nhau tìm hiểu về ACID. Một trong những tính chất cực kỳ quan trọng của cơ sở dữ liệu quan hệ.

Tôi biết đây lại là “một bài viết nữa về ACID” nhưng nếu bạn không học được điều gì mới sau khi đọc bài này, tôi sẽ mời bạn một ly nước.

Ok. Let's go.

ACID là viết tắt của:

Atomicity (Tính nguyên tử)
Consistency (Tính nhất quán)
Isolation (Tính độc lập)
Durability (Tính bền vững)

Atomicity – Tính nguyên tử

“Atomic” nghĩa là không thể chia nhỏ hơn nữa. Nó là một đơn vị công việc duy nhất, ví dụ:

insert into users(username, age) values ("johndoe", 29);

Đây là một công việc đơn lẻ. Hoặc là thành công, hoặc là thất bại. Không có trạng thái trung gian.

Nghe thì dễ, nhưng thế với 3 câu query bên dưới thì sao?

insert into orders(user_id, amount) values(1, 199);
insert into order_items(order_id, product_id) values(1, 1153);
insert into order_items(order_id, product_id) values(1, 792);

Điều gì xảy ra nếu câu lệnh insert cuối cùng bị lỗi? Cơ sở dữ liệu sẽ rơi vào trạng thái không nhất quán vì các thao tác này không được thực thi như một đơn vị nguyên tử.

Trong các cơ sở dữ liệu quan hệ, transaction giúp ta đạt được tính nguyên tử bằng cách “bao” các truy vấn và xử lý chúng như một đơn vị duy nhất:

start transaction;
  insert into orders(user_id, amount) values(1, 199);
  insert into order_items(order_id, product_id) values(1, 1153);
  insert into order_items(order_id, product_id) values(1, 792);
commit;

Ba truy vấn này giờ đây được coi là một khối nguyên tử.

Đúng không?

Câu trả lời là: Không. What?????

Tôi từng nghĩ rằng chỉ cần dùng start transaction là mọi thứ sẽ trở nên nguyên tử. Nhưng điều đó không đúng. Hãy thử đưa một giá trị không hợp lệ vào dòng thứ hai:

insert into order_items(order_id, product_id) values("ysdf", 1153);

Giờ hãy chạy cả ba câu lệnh trong một transaction:

Bạn có thể thấy trong log: Query OK, 1 row affected.
Dòng đầu tiên và dòng cuối cùng vẫn được thực hiện.
Dù dòng ở giữa có lỗi, nhưng hai dòng còn lại vẫn chèn dữ liệu.

Theo kinh nghiệm của tôi, nhiều lập trình viên nghĩ rằng nếu có lỗi xảy ra thì cơ sở dữ liệu sẽ tự động quay lại trạng thái ban đầu chỉ cần thêm start transaction:

start transaction;
  insert into orders(user_id, amount) values(1, 199);
  insert into order_items(order_id, product_id) values(1, 1153);
  insert into order_items(order_id, product_id) values(1, 792);
commit;

Nhưng như ta thấy – không đúng. Vậy nên hãy sửa lại truy vấn:

start transaction;

insert into orders(user_id, amount) values(1, 199);
if row_count() <= 0 then
  rollback;
  select "error while creating order";
  show errors;
end if;

set @order_id = last_insert_id();

insert into order_items(order_id, product_id) values(@order_id, 1153);
if row_count() <= 0 then
  rollback;
  select "error while creating order item";
  show errors;
end if;

insert into order_items(order_id, product_id) values(@order_id, 792);
if row_count() <= 0 then
  rollback;
  select "error while creating order item";
  show errors;
end if;

commit;
select 'done';

We just found a language that’s error handling is more annoying then Golang’s :D

Mảnh ghép còn thiếu là rollback. Nếu bạn muốn kiểm soát đầy đủ trạng thái của CSDL, bạn cần kiểm tra từng thao tác và rollback nếu cần thiết.

Thông thường, ta xử lý phần này ở code backend (laravel) thay vì trong MySQL trực tiếp, nhưng vẫn thú vị khi nhìn vào ví dụ như trên.

row_count() trả về số dòng bị ảnh hưởng bởi câu lệnh SQL trước đó – có thể là insert, update, hoặc delete.

Sau mỗi lần insert, ta kiểm tra row_count(). Nếu nhỏ hơn hoặc bằng 0, ta rollback.

Giờ đây, ba câu lệnh trên thực sự trở thành một khối nguyên tử – hoặc tất cả thành công, hoặc không có gì xảy ra. Giúp bảo vệ trạng thái cơ sở dữ liệu.

Tất nhiên, phần lớn thời gian chúng ta xử lý trong code, ví dụ trong laravel:

public function store(Request $request, OrderService $orderService) 
{
  $order = DB::transaction(function () {
    $order = $orderService->create(
        $request->user(), 
        $request->amount,
    );

    foreach ($request->items as $item) {
      $orderSerivce->addItem($order, $item);
    }

    return $order;
  });

  return OrderResource::make($order);
}

Vậy là xong – một hàm store nguyên tử. Nếu có Exception xảy ra, CSDL sẽ được khôi phục về trạng thái ban đầu.

Consistency – Tính nhất quán

Thực sự với mình tính nhất quán là một khái niệm hơi rắc rối ^^

Nó có nghĩa là cơ sở dữ liệu chuyển từ một trạng thái hợp lệ này sang trạng thái hợp lệ khác sau khi thực hiện một transaction.

Câu hỏi đặt ra là: “Trạng thái hợp lệ” là gì và làm sao cơ sở dữ liệu có thể đảm bảo điều đó?

Khóa ngoại (Foreign keys)
1. Một trong những khái niệm cơ bản nhất của cơ sở dữ liệu quan hệ là khóa ngoại. Hãy sử dụng chúng.
  Chúng đảm bảo rằng chỉ các giá trị hợp lệ mới được chèn vào cột khóa ngoại. Điều này áp đặt trạng thái hợp lệ trong ngữ cảnh quan hệ giữa các bảng.
Unique constraints
1. Đây cũng là một khái niệm rất quan trọng trong cơ sở dữ liệu quan hệ.
  Nó đảm bảo rằng bạn không bị trùng lặp dữ liệu trong những trường hợp không được phép.
  Theo kinh nghiệm của tôi, nhiều người không tận dụng đủ chỉ mục duy nhất dạng kết hợp nhiều cột (composite unique index).
  Ví dụ, hãy nhìn vào bảng post_likes như trong hình bạn cung cấp
  Cột user_id và post_id nên là một chỉ mục duy nhất kết hợp, vì một người dùng chỉ được thích một bài viết duy nhất một lần:
```
create unique index `user_id_post_id_idx` on `post_likes` (`user_id`, `post_id`);
```
Data types and modifiers
1. Rõ ràng là bạn không thể chèn chuỗi vào cột kiểu số nguyên – và đó là một điều tốt.
  Nhưng quan trọng hơn, ta có thể dùng các modifier như unsigned để đảm bảo dữ liệu hợp lệ ở mức cơ sở dữ liệu.
  - unsigned có thể được dùng để đảm bảo các quy tắc nghiệp vụ cơ bản, ví dụ cột balance luôn là số dương, ngay cả khi có lỗi trong hệ thống.
  - varchar(100) – Giới hạn độ dài cột giúp đảm bảo tính toàn vẹn dữ liệu, ngay cả khi phần kiểm tra ở phía backend cho phép giá trị không hợp lệ.
  - NOT NULL đảm bảo bạn không để trống những cột bắt buộc.
  - Các giá trị mặc định hợp lý cũng rất hữu ích. Ví dụ, khi bạn có cột status, bạn nên thêm giá trị mặc định:
```
create table orders (
  id bigint unsigned primary key,
  status varchar(32) default 'pending',
  created_at timestamp default current_timestamp
);
```
CHECK constraints
1. Phần này thuộc vùng “xám” – không hẳn đúng, không hẳn sai. Bạn có thể dùng MySQL để viết như sau:
```
create table employees (
  id bigint unsigned primary key,
  name varchar(100) not null,
  email varchar(100) check (email LIKE '%@%.%'),
  age smallint check (age between 18 and 65),
  salary decimal(10,2) unsigned,
  department_id int check (department_id in (select id from departments)),
  hire_date date check (hire_date > '2000-01-01')
);
```
  Bạn có thể viết các quy tắc kiểm tra (validation rules) bằng từ khóa check (nếu dùng MySQL 8).
  Tuy nhiên, đây là phần “ẩn” – các lập trình viên thường không đọc định nghĩa bảng để xem các ràng buộc này.
  Họ không kỳ vọng là CSDL sẽ kiểm tra định dạng email, v.v. (một ý tương tự cũng áp dụng cho trigger, nên tôi không nhắc đến trong bài này).
  Dù vậy, vẫn có trường hợp hữu ích cho check.
  Ví dụ, nếu ứng dụng của bạn theo dõi số dư tài khoản – nó có thể âm, nhưng không được nhỏ hơn -10.000.
  Đây là một quy tắc nghiệp vụ quan trọng, vậy nên bạn có thể viết:
```
balance int not null check (balance >= -10000)
```
  Lưu ý: đây không nên là lớp validation duy nhất, mà chỉ là tuyến phòng thủ cuối cùng. Thường thì chúng ta đã validate chặt chẽ ở tầng ứng dụng bao gồm cả FE và Backend( ví dụ Laravel)
  Lúc đầu tôi nói tính nhất quán là phức tạp – là bởi vì nó tồn tại trên hai tầng:
  - Tầng cơ sở dữ liệu (Database)
  - Tầng ứng dụng (Application)
  CSDL có thể giúp bạn bằng các tính năng trên, nhưng bạn vẫn cần xử lý ít nhất các điều sau ở tầng ứng dụng.
  Những điều cần ghi nhớ để đảm bảo Consistency
  - Validate dữ liệu cẩn thận
  - Xử lý lỗi hợp lý
  - Sử dụng transaction khi cần thiết
  - Sử dụng cơ chế khóa (lock) – optimistic hoặc pessimistic
  - Ghi log (audit log), hoặc event stream / event sourcing
  - Sao lưu hệ thống thường xuyên (database, redis, file upload, .env)
  - Kiểm tra dữ liệu và quy tắc nghiệp vụ
  - Nếu có trạng thái chuyển đổi → dùng state machine
  - Nếu bạn tính toán (như công thức tài chính) → phải kiểm tra biến đầu vào
  - API nên idempotent – gọi lại nhiều lần không thay đổi kết quả
  - Nếu có migration lớn, đừng xóa bảng ngay – chỉ cần đổi tên (ví dụ: orders_backup)
    → Nếu release thành công rồi hãy xóa hẳn
  - Bạn có thể viết job chạy định kỳ để kiểm tra tính toàn vẹn (ví dụ check số dư)
  - Nếu bạn dùng cache, luôn đặt TTL (Time To Live) mặc định. Redis sẽ tự xóa key khi TTL hết hạn.
    => Danh sách còn dài, nhưng bắt đầu rời khỏi phạm vi của cơ sở dữ liệu nên mình không đề cập ở đây.
    Vẫn còn nhiều kỹ thuật khác như defensive programming để bảo vệ bạn khỏi những loại lỗi như vậy.

Isolation – Tính cô lập

Chuyện gì sẽ xảy ra nếu hai client truy cập cùng một bản ghi trong DB cùng lúc và cả hai cùng sửa nó theo cách riêng?

Hãy cùng xem ví dụ “huyền thoại” – counter. Có một bảng trong DB chứa giá trị counter ban đầu là 10.
Hai người dùng (User 1 và User 2) cùng lúc cố gắng cập nhật giá trị này.

Biểu đồ trên: Race condition xảy ra

User 1 đọc counter = 10, tính ra new counter = 11
User 2 cũng đọc counter = 10, cũng tính new counter = 11
Cả hai cùng ghi đè lên nhau → counter cuối cùng là 11

👉 Nhưng đúng ra kết quả phải là 12.

Đây là lỗi race condition kinh điển. Và đây không chỉ là vấn đề của database - bạn có thể gặp tượng trong goroutines nếu không dùng mutex.

Vậy thì rốt cuộc chuyện gì đã xảy ra trong ví dụ trên.

Để trả lời câu hỏi trên ta cần làm rõ 3 khái niệm sau:

Dirty Reads

Xảy ra khi một transaction đọc dữ liệu mà transaction khác chưa commit. (Trong ngữ cảnh này thì transaction, user, client đều đề cập đến cùng 1 thứ).
Đây chính là lỗi ở ví dụ rollback ở trên.

Cách phòng tránh: buộc transaction khác phải đợi đến khi commit hoặc rollback xong.

Đây là chính xác là điều đã xả ra ở ví dụ trên. Khi User 2 đọc counter trong DB trả về kết quả là 10 nhưng transaction của User 1 vẫn chưa commit.

Chúng ta có thể ngăn chặn Dirty Reads bằng cách buộc transaction khác phải đợi đến khi commit hoặc rollback xong:

Đường màu đỏ biểu thị khoảng thời gian User 2 phải đợi đến khi User 1 commit hoặc rollback các thay đổi của mình.

Trước đó, Giá trị counter được update lên 11 bởi User. Và giá trị hiện tại của counter vẫn là 12 như bình thường.

Non-repeatable Reads

Xảy ra khi cùng một transaction, bạn đọc cùng một dòng 2 lần nhưng kết quả khác nhau.

Trong ví dụ trên:

User 1 thực hiện hai câu lệnh SELECT trong cùng một transaction.
Lần đầu, dữ liệu trả về là 10.
Trong lúc đó, User 2 cập nhật dòng dữ liệu đó thành 11 và COMMIT.
Lần hai, User 1 tiếp tục đọc dòng dữ liệu và nhận được giá trị mới là 11.

Trên thực tế, nếu User 1 thực thi cả hai truy vấn trong cùng một transaction, thì hiện tượng này không nên xảy ra trong hầu hết các cấu hình cơ sở dữ liệu.

Một lần nữa, trong trường hợp này User 2 nên bị khóa (blocked) cho đến khi User 1 commit transaction của mình.

Phantom Reads

Phantom read gần giống với non-repeatable read, chỉ khác nhau ở một điểm duy nhất:

Non-repeatable reads liên quan đến việc thay đổi các row đã tồn tại – ví dụ như một giá trị đếm bị cập nhật.
Phantom reads thì liên quan đến việc thêm hoặc xóa các hàng phù hợp với điều kiện của truy vấn ban đầu.

Vì vậy, phantom read cũng gây ra kết quả khác nhau giữa các lần truy vấn trong cùng một transaction, nhưng không phải do dữ liệu hiện có bị thay đổi, mà là do có bản ghi mới được thêm vào hoặc bị xóa đi.

Ví dụ:

User 1: select count(*) from accounts where balance > 10; -- Returns 5
User 2: insert into accounts (balance) VALUES (11);
User 2: commit;
User 1: select count(*) from accounts where balance > 10; -- Returns 6

Ở đây, cùng một truy vấn trong một transaction, nhưng lại trả về kết quả khác nhau. Không phải vì dữ liệu cũ bị chỉnh sửa, mà do có bản ghi mới được thêm vào thỏa mãn điều kiện truy vấn.

Tóm lại:

Dirty reads : liên quan đến dữ liệu chưa được commit
Non-repeatable reads: liên quan đến các row đã tồn tại bị thay đổi
Phantom reads: liên quan đến việc thêm/xóa các row phù hợp với điều kiện truy vấn

Giải pháp?

Tôi bắt đầu có một câu hỏi:

Trong các tình huống trên, hệ thống nên xử lý như thế nào?

Và câu trả lời là:

Hầu như bất cứ điều gì cũng có thể xảy ra, tùy thuộc vào mức độ cô lập transaction (isolation level) mà MySQL đang sử dụng.

MySQL hỗ trợ 4 cấp độ isolation, mỗi cấp độ có cách hành xử riêng biệt đối với các vấn đề cạnh tranh (concurrency) như đã đề cập:

Read uncommitted
Read committed
Repeatable read
Serializeable

Các mức độ Isolation trong MySQL:

Read committed
Đây là cấp độ cách ly thấp nhất. Transaction có thể đọc dữ liệu chưa được commit từ các transaction khác.

Cho phép xảy ra:
- Dirty reads
- Non-repeatable reads
- Phantom reads
Không ngăn chặn được bất kỳ vấn đề nào các vấn đề nêu phía trên. Nói cách khác: mọi thứ đều có thể xảy ra với database của bạn.
Chỉ nên dùng nếu bạn thật sự có lý do hợp lý và rõ ràng.
Read committed
Đây là một cấp độ cô lập nghiêm ngặt hơn so với Read uncommitted.
Nó ngăn chặn:
- Dirty reads (Đọc bẩn) – mỗi câu lệnh SELECT chỉ nhìn thấy dữ liệu đã được commit trước khi truy vấn bắt đầu.
Tuy nhiên, nó vẫn cho phép xảy ra:
- Non-repeatable reads (Đọc không lặp lại)
- Phantom reads (Đọc bóng ma)
Đây cũng là một mức độ nguy hiểm, và bạn không nên sử dụng trừ khi bạn thật sự có lý do chính đáng.
Repeatable read – Mặc định trong MYSQL
Đây là mức độ cô lập nghiêm ngặt hơn nữa và cũng là mặc định trong MySQL.
Nó ngăn chặn:
- Dirty reads
- Non-repeatable reads
Tuy nhiên, nó vẫn cho phép:
- Phantom reads
Tại sao cấu hình mặc định lại vẫn cho phép phantom reads?
Theo những gì tôi biết, đây là sự đánh đổi giữa tính nhất quán (consistency) và hiệu năng (performance).
Tôi không rõ chi tiết chính xác trong cách MySQL triển khai, nhưng theo hiểu biết tốt nhất của tôi, cơ chế Repeatable Read hoạt động như sau:
- Khi một truy vấn đọc dữ liệu trong transaction, MySQL sẽ khóa các dòng dữ liệu đã được chọn.
- Tuy nhiên, truy vấn thường đọc từ index, và không khóa các dòng nằm giữa các dòng đã chọn. Điều này gọi là “gap (khoảng trống)”.
- Những “gap” này không bị khóa, vì vậy các transaction khác vẫn có thể chèn thêm bản ghi mới vào khoảng này, nếu bản ghi đó thỏa mãn điều kiện truy vấn.
- MySQL cũng sử dụng cơ chế snapshot (ảnh chụp dữ liệu tại thời điểm transaction bắt đầu). Điều này khá phức tạp.
Lưu ý: Đây chỉ là mô tả đơn giản, tôi không khuyến khích bạn trích dẫn tuyệt đối về phần này.
Serializable
Đây là mức độ cách ly nghiêm ngặt nhất.
Nó ngăn chặn tất cả:
- Dirty reads
- Non-repeatable reads
- Phantom reads
Đây là mức độ đảm bảo tính nhất quán cao nhất, nhưng đổi lại hiệu năng sẽ thấp hơn nhiều.
Một số trường hợp đặc biệt nên sử dụng mức này vì giá trị của tính chính xác cao hơn chi phí hiệu năng, ví dụ:
- Hệ thống y tế – nơi độ chính xác dữ liệu có thể ảnh hưởng đến tính mạng con người.
- Ứng dụng tài chính – ngân hàng, hệ thống transaction, xử lý thanh toán. Mọi transaction phải chính xác và đồng nhất.
- Hệ thống đặt chỗ – không được để xảy ra tình trạng đặt trùng, overbooking.
Cách thay đổi Isolation Level trong MySQL
Bạn có thể thay đổi cấp độ cô lập trong transaction của phiên hiện tại bằng lệnh:
```
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
```
Ngoài READ COMMITTED, bạn có thể thay bằng:
READ UNCOMMITTED, REPEATABLE READ, hoặc SERIALIZABLE tùy theo nhu cầu cụ thể của ứng dụng.

Tôi để ảnh ở đây để các bạn so sánh và tổng kết nhé.

Durability (Tính bền vững)

Durability đảm bảo rằng một khi transaction đã được commit, tất cả thay đổi của nó sẽ được lưu lại vĩnh viễn và không bị mất ngay cả khi hệ thống gặp sự cố (ví dụ mất điện, crash máy chủ…).

Trong môi trường không phân tán (ví dụ như khi bạn chạy tiến trình MySQL thông thường), điều này có nghĩa là dữ liệu của bạn sẽ được ghi xuống đĩa (disk).

Ngoài ra, hầu hết các hệ quản trị cơ sở dữ liệu hiện đại đều sử dụng một cơ chế gọi là Write-Ahead Log (WAL) để ngăn chặn mất mát dữ liệu khi hệ thống gặp sự cố.

Nguyên tắc cốt lõi của WAL là:

Mọi thay đổi phải được ghi vào một file log trước, rồi mới áp dụng lên cơ sở dữ liệu thực tế.

File log này được lưu trữ trên đĩa và sẽ được sử dụng để khôi phục dữ liệu trong trường hợp hệ thống gặp sự cố.

Các hệ quản trị cơ sở dữ liệu như:

SQLite
MySQL
Redis (thông qua cơ chế append-only log)
PostgreSQL

…đều triển khai cơ chế WAL theo cách riêng của mình.

Một điểm thú vị khác của WAL là nó còn giúp cải thiện hiệu năng:

Vì mọi thay đổi được ghi vào file log thay vì ghi trực tiếp vào file bảng (table file – nơi lưu trữ dữ liệu thực của bạn), nên hệ thống không cần cập nhật file bảng mỗi lần có thao tác, từ đó giảm số lần ghi đĩa trực tiếp và tăng hiệu suất tổng thể.

Understanding ACID

Lucnv

Bài viết liên quan

Dependency Injection trong Laravel Closure Commands

Bình luận (...)