Pagination แบ่งชุดผลลัพธ์ขนาดใหญ่ออกเป็นหน้าย่อย ๆ เพื่อให้คุณไม่ต้องโหลดระเบียนหลายพันรายการพร้อมกัน มันจำเป็นต่อประสิทธิภาพและการใช้งาน Django มีคลาส Paginator สำหรับ template/view และ DRF มี pagination ในตัวสำหรับ API
# ❌ loading everything — slow, memory-heavy, bad UX with thousands of rows
articles = Article.objects.all()
from django.core.paginator import Paginator
def article_list(request):
articles = Article.objects.all().order_by("-created_at") # ORDER matters for consistent pages
paginator = Paginator(articles, 20) # 20 items per page
page_number = request.GET.get("page") # ?page=2
page_obj = paginator.get_page(page_number) # the requested page
return render(request, "list.html", {"page_obj": page_obj})
<!-- in the 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 แบ่ง queryset ออกเป็นหน้า ๆ และ get_page() คืน page object พร้อมตัวช่วยนำทาง (has_next, next_page_number ฯลฯ) — สังเกตว่ามันเพิ่ม LIMIT/OFFSET ลงใน query ดังนั้นจึงดึงเพียงหน้าเดียวจากฐานข้อมูล
# global default in settings.py
REST_FRAMEWORK = {
"DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination",
"PAGE_SIZE": 20,
}
# now list endpoints are automatically paginated, returning:
# { "count": 1000, "next": "...?page=3", "previous": "...?page=1", "results": [...] }
DRF ทำ pagination ให้ list endpoint โดยอัตโนมัติเมื่อตั้งค่าแล้ว โดยคืน metadata ของหน้า (count, ลิงก์ next/previous) พร้อมกับผลลัพธ์ — client นำทางผ่าน URL ที่ให้มา
PageNumberPagination → ?page=2 (simple page numbers)
LimitOffsetPagination → ?limit=20&offset=40 (flexible offsets)
CursorPagination → opaque cursor; consistent & performant for large/changing data
(avoids OFFSET performance issues on huge datasets)
⚠️ OFFSET-based pagination (page/offset) gets SLOWER on deep pages of huge tables
(the DB must skip OFFSET rows). For very large datasets, CURSOR pagination
(keyset, using a WHERE on an indexed column) is far more efficient.
⚠️ Always ORDER BY a stable field, or pages can be inconsistent/repeat items.
pagination จำเป็นต่อการสร้างแอปพลิเคชันที่มีประสิทธิภาพและใช้งานได้จริงซึ่งจัดการปริมาณข้อมูลจริง — หากไม่มีมัน listing endpoint และหน้าที่โหลดทั้งตาราง (อาจหลายพันหรือหลายล้านแถว) จะช้า, ใช้หน่วยความจำมาก และใช้งานไม่ได้ ทั้งสร้างภาระให้ฐานข้อมูลและท่วมท้นผู้ใช้และ client
การเข้าใจ pagination เป็นความรู้เชิงปฏิบัติในชีวิตประจำวัน: Paginator ของ Django จัดการ view/template แบบดั้งเดิม (แบ่ง queryset ออกเป็นหน้าพร้อมตัวช่วยนำทาง ดึงเพียงหน้าเดียวอย่างมีประสิทธิภาพผ่าน LIMIT/OFFSET) และ pagination ในตัว ของ DRF จัดการ API (ทำ pagination ให้ list endpoint โดยอัตโนมัติพร้อม metadata และลิงก์นำทางเมื่อตั้งค่าแล้ว) — ทั้งคู่จำเป็นขึ้นอยู่กับว่าคุณสร้างหน้าที่ render จากเซิร์ฟเวอร์หรือ API
การรู้วิธีทำ pagination ในทั้งสองบริบทเป็นสิ่งจำเป็นสำหรับฟีเจอร์การแสดงรายการข้อมูลแทบทุกอย่าง
ประเด็นด้านประสิทธิภาพ มีค่าเป็นพิเศษในระดับ senior: pagination แบบ OFFSET มาตรฐานเสื่อมประสิทธิภาพในหน้าลึก ๆ ของตารางที่ใหญ่มาก (ฐานข้อมูลต้องข้ามทุกแถวที่อยู่ก่อนหน้า) ดังนั้น cursor (keyset) pagination จึงเป็นตัวเลือกที่มีประสิทธิภาพสำหรับ dataset ที่ใหญ่หรือเปลี่ยนแปลงรวดเร็ว และการ เรียงตามฟิลด์ที่เสถียร เสมอเป็นสิ่งจำเป็นเพื่อหลีกเลี่ยงผลลัพธ์ที่ไม่สอดคล้องหรือซ้ำกันข้ามหน้า
การเข้าใจทั้งกลไกพื้นฐาน (Paginator, คลาส DRF pagination) และข้อพิจารณาด้านประสิทธิภาพเหล่านี้ (OFFSET เทียบกับ cursor pagination, การเรียงที่สอดคล้อง) สำคัญต่อการสร้างแอปพลิเคชันที่ยังคงเร็วและถูกต้องเมื่อข้อมูลเติบโต — pagination เป็นความต้องการที่พบได้ทั่วไป และการทำมันให้ดี โดยเฉพาะในระดับใหญ่ เป็นทักษะเชิงปฏิบัติที่ส่งผลโดยตรงต่อประสิทธิภาพของแอปพลิเคชันและประสบการณ์ผู้ใช้