Hiệu Năng Phân Trang: OFFSET vs Keyset Cursor Pagination

TL;DR: OFFSET N LIMIT 20 có độ phức tạp $O(N)$ vì database phải quét tuần tự và bỏ qua $N$ dòng trước khi trả về kết quả; trang thứ 1.000 sẽ chậm hơn trang đầu tiên tới hàng nghìn lần. Keyset (Cursor-based) pagination tận dụng B-tree index seek để nhảy thẳng tới vị trí dữ liệu với độ phức tạp $O(\log N)$ không đổi bất kể độ sâu. Kiểu trả về Slice<T> giúp loại bỏ câu lệnh COUNT(*) tiết kiệm 50% thời gian nhưng vẫn chịu chi phí của OFFSET scan.

Vì sao phân trang OFFSET bị chậm tuyến tính ở các trang sâu?

Hãy quan sát câu lệnh SQL phân trang truyền thống:

SELECT * FROM activities
ORDER BY created_at DESC
LIMIT 20 OFFSET 20000;

Cơ chế thực thi bên dưới của PostgreSQL / MySQL:

1. Duyệt qua chỉ mục created_at từ đầu.
2. Đếm và loại bỏ đúng 20.000 dòng dữ liệu đầu tiên.
3. Đọc 20 dòng kế tiếp (từ dòng 20.001 đến 20.020).
4. Trả kết quả về cho ứng dụng.

Database phải tiêu tốn tài nguyên I/O để chạm vào 20.020 bản ghi chỉ để lấy ra đúng 20 bản ghi! Kể cả khi cột created_at có index, database vẫn phải duyệt qua 20.000 mục chỉ mục. Độ phức tạp là $O(N)$ tỉ lệ thuận với giá trị OFFSET.

Keyset Cursor Pagination giải quyết bài toán hiệu năng ra sao?

Thay vì yêu cầu database "bỏ qua 20.000 dòng", Keyset Pagination đưa ra điều kiện: "Lấy 20 bản ghi tiếp theo nằm sau bản ghi cuối cùng của trang trước".

Cú pháp Composite Cursor

@Query("""
    SELECT a FROM Activity a
    WHERE a.createdAt < :cursorCreatedAt
       OR (a.createdAt = :cursorCreatedAt AND a.id < :cursorId)
    ORDER BY a.createdAt DESC, a.id DESC
""")
List<Activity> findNextPage(
    @Param("cursorCreatedAt") Instant cursorCreatedAt,
    @Param("cursorId") Long cursorId,
    Pageable limit
);

Câu lệnh SQL phát sinh tương ứng:

SELECT * FROM activities
WHERE created_at < '2026-05-01 10:00:00'
   OR (created_at = '2026-05-01 10:00:00' AND id < 5000)
ORDER BY created_at DESC, id DESC
LIMIT 20;

Database thực hiện thao tác B-tree Index Seek để nhảy trực tiếp tới vị trí con trỏ (cursorCreatedAt, cursorId) trong thời gian $O(\log N)$, sau đó đọc đúng 20 dòng tiếp theo.

Kiểu trả về Slice loại bỏ câu lệnh COUNT(*) như thế nào?

Khi sử dụng Page<T>, hệ thống luôn phát thêm một câu lệnh SELECT COUNT(*) tốn kém. Nếu giao diện chỉ cần nút "Xem thêm" hoặc Infinite Scroll trên thiết bị di động, Slice<T> là lựa chọn thay thế hoàn hảo.

// Chi phat sinh duy nhat 1 cau lenh SQL: LIMIT 21 OFFSET N
Slice<Activity> findByCategory(String category, Pageable pageable);

Hibernate thực hiện cơ chế tối ưu bằng cách truy vấn size + 1 dòng (ví dụ lấy 21 dòng cho trang kích thước 20):

• Nếu database trả về đủ 21 dòng: Phương thức hasNext() trả về true, dòng thứ 21 bị gọt bỏ khỏi danh sách trả về.
• Nếu database trả về $\le 20$ dòng: Phương thức hasNext() trả về false.

Cảnh báo: Slice<T> chỉ loại bỏ chi phí của COUNT(*). Nếu người dùng cuộn tới trang quá sâu (OFFSET 500000), câu lệnh data query của Slice vẫn bị chậm như bình thường.

Bảng so sánh 3 chiến lược phân trang dữ liệu

Những cạm bẫy phổ biến cần tránh là gì?

1. Cho phép OFFSET sâu không giới hạn: Không chặn tham số page, khiến crawler web quét tới ?page=50000 làm sập database connection pool.
2. Cursor không duy nhất (thiếu Tie-Breaker): Chỉ dùng createdAt làm cursor mà không kèm id. Khi có nhiều dòng cùng timestamp, các bản ghi sẽ bị bỏ sót âm thầm.
3. Thiếu Composite Index cho Keyset: Viết câu lệnh seek nhưng không tạo chỉ mục trên cặp (createdAt, id), dẫn tới việc database phải full-table scan.

Tự kiểm tra kiến thức

Bài tiếp theo: Tổng Kết Module 05: Repository & Queries