Phân trang chia một tập kết quả lớn thành các trang rời rạc, để bạn không load hàng nghìn bản ghi cùng lúc. Nó thiết yếu cho hiệu năng và khả năng sử dụng. Django cung cấp một class Paginator cho template/view, và DRF cung cấp phân trang tích hợp cho API.
# ❌ load mọi thứ — chậm, nặng bộ nhớ, UX tệ với hàng nghìn hàng
articles = Article.objects.()
from django.core.paginator import Paginator
def article_list(request):
articles = Article.objects.all().order_by("-created_at") # THỨ TỰ quan trọng để các trang nhất quán
paginator = Paginator(articles, 20) # 20 mục mỗi trang
page_number = request.GET.get("page") # ?page=2
page_obj = paginator.get_page(page_number) # trang được yêu cầu
return render(request, "list.html", {"page_obj": page_obj})
<!-- trong template -->
{% for article in page_obj %}
<h2>{{ article.title }}</h2>
{% endfor %}
{% if page_obj.has_previous %}<a href="?page={{ page_obj.previous_page_number }}">Prev</a>{% endif %}
Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }}
{% if page_obj.has_next %}<a href="?page={{ page_obj.next_page_number }}">Next</a>{% endif %}
Paginator cắt một queryset thành các trang và get_page() trả về một đối tượng trang với các helper điều hướng (has_next, next_page_number, v.v.) — lưu ý nó thêm LIMIT/OFFSET vào truy vấn, nên chỉ một trang được lấy từ database.
# mặc định toàn cục trong settings.py
REST_FRAMEWORK = {
"DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination",
"PAGE_SIZE": 20,
}
# giờ các endpoint list được tự động phân trang, trả về:
# { "count": 1000, "next": "...?page=3", "previous": "...?page=1", "results": [...] }
DRF phân trang các endpoint list tự động một khi được cấu hình, trả về metadata trang (count, link next/previous) kèm theo kết quả — client điều hướng qua các URL được cung cấp.
PageNumberPagination → ?page=2 (số trang đơn giản)
LimitOffsetPagination → ?limit=20&offset=40 (offset linh hoạt)
CursorPagination → cursor mờ; nhất quán & hiệu năng cao cho dữ liệu lớn/thay đổi
(tránh vấn đề hiệu năng OFFSET trên tập dữ liệu khổng lồ)
⚠️ Phân trang dựa trên OFFSET (page/offset) CHẬM DẦN ở các trang sâu của bảng khổng lồ
(DB phải bỏ qua OFFSET hàng). Cho tập dữ liệu rất lớn, CURSOR pagination
(keyset, dùng WHERE trên một cột có index) hiệu quả hơn nhiều.
⚠️ Luôn ORDER BY một field ổn định, nếu không các trang có thể không nhất quán/lặp item.
Phân trang là thiết yếu để xây dựng các ứng dụng hiệu năng cao, dễ sử dụng xử lý khối lượng dữ liệu thực — nếu không có nó, các endpoint list và trang load toàn bộ bảng (có thể hàng nghìn hoặc hàng triệu hàng) trở nên chậm, tốn bộ nhớ, và không dùng được, vừa gây căng thẳng database vừa quá tải user và client.
Hiểu phân trang là kiến thức thực tế hàng ngày: Paginator của Django xử lý view/template truyền thống (cắt queryset thành các trang với các helper điều hướng, lấy hiệu quả chỉ một trang qua LIMIT/OFFSET), và phân trang tích hợp của DRF xử lý API (tự động phân trang các endpoint list với metadata và link điều hướng một khi được cấu hình) — cả hai đều cần tùy theo bạn xây dựng trang render phía server hay API.
Biết cách hiện thực phân trang trong cả hai bối cảnh là cần thiết cho gần như mọi tính năng liệt kê dữ liệu. Sắc thái hiệu năng đặc biệt là kiến thức cấp senior có giá trị: phân trang dựa trên OFFSET tiêu chuẩn suy thoái ở các trang sâu của bảng rất lớn (database phải bỏ qua tất cả các hàng đứng trước), nên cursor (keyset) pagination là lựa chọn hiệu quả cho tập dữ liệu khổng lồ hoặc thay đổi nhanh, và luôn sắp xếp theo một field ổn định là cần thiết để tránh kết quả không nhất quán hoặc trùng lặp xuyên các trang.
Hiểu cả cơ chế cơ bản (Paginator, các class phân trang DRF) lẫn các cân nhắc hiệu năng này (OFFSET so với cursor pagination, sắp xếp nhất quán) là quan trọng để xây dựng các ứng dụng vẫn nhanh và đúng khi dữ liệu tăng — phân trang là một yêu cầu phổ biến, và làm tốt nó, đặc biệt ở quy mô lớn, là một kỹ năng thực tế ảnh hưởng trực tiếp đến hiệu năng ứng dụng và trải nghiệm người dùng.