LIMIT dan OFFSET SQLite: Pagination dan Batasi Baris

LIMIT Membatasi Jumlah Baris

LIMIT adalah pengatur paling sederhana di SQL: klausa ini memberi tahu SQLite "berikan paling banyak sekian baris." Taruh di akhir SELECT, dan kamu akan mendapat hasil sebanyak itu, tidak lebih, dan mungkin kurang jika tabelnya tidak punya cukup baris.

CREATE TABLE books (
    id INTEGER PRIMARY KEY,
    title TEXT,
    year INTEGER
);

INSERT INTO books (title, year) VALUES
    ('The Pragmatic Programmer', 1999),
    ('Code', 1999),
    ('Refactoring', 1999),
    ('Clean Code', 2008),
    ('Designing Data-Intensive Applications', 2017);

SELECT title, year FROM books LIMIT 3;

Kamu mendapat tiga baris pertama. Tapi tiga baris yang mana, tepatnya? Di situlah masalahnya: tanpa ORDER BY, SQLite memilih urutan apa pun yang menurutnya praktis. Hari ini mungkin urutan saat baris dimasukkan; besok, setelah ada update atau perubahan index, mungkin tidak lagi. LIMIT saja sudah cukup untuk "tunjukkan contoh datanya", tapi begitu urutannya penting, kamu perlu menuliskannya secara eksplisit.

OFFSET Melewati Baris dari Depan

Pasangkan LIMIT dengan OFFSET, dan kamu bisa meminta potongan dari tengah hasil query. OFFSET k membuang k baris pertama; lalu LIMIT n mengembalikan paling banyak n baris dari sisanya.

CREATE TABLE books (
    id INTEGER PRIMARY KEY,
    title TEXT,
    year INTEGER
);

INSERT INTO books (title, year) VALUES
    ('The Pragmatic Programmer', 1999),
    ('Code', 1999),
    ('Refactoring', 1999),
    ('Clean Code', 2008),
    ('Designing Data-Intensive Applications', 2017);

SELECT title, year
FROM books
ORDER BY year, title
LIMIT 2 OFFSET 2;

Artinya "lewati dua baris, kembalikan dua berikutnya", yaitu baris ke-3 dan ke-4 dari hasil yang sudah diurutkan. Model berpikirnya: WHERE memfilter, ORDER BY mengurutkan, OFFSET melewati, LIMIT membatasi. Semuanya berjalan dengan urutan itu, dan semuanya penting.

Pagination Selalu Butuh ORDER BY

Pemakaian LIMIT dan OFFSET yang paling umum adalah pagination: membagi daftar panjang menjadi halaman-halaman, misalnya 20 baris per halaman. Halaman 1 adalah LIMIT 20 OFFSET 0, halaman 2 adalah LIMIT 20 OFFSET 20, dan seterusnya.

CREATE TABLE posts (
    id INTEGER PRIMARY KEY,
    title TEXT,
    created_at TEXT
);

INSERT INTO posts (title, created_at) VALUES
    ('First post', '2024-01-01'),
    ('Second post', '2024-01-02'),
    ('Third post', '2024-01-03'),
    ('Fourth post', '2024-01-04'),
    ('Fifth post', '2024-01-05');

-- Page 2, with 2 posts per page
SELECT id, title, created_at
FROM posts
ORDER BY created_at DESC, id DESC
LIMIT 2 OFFSET 2;

Ada dua hal yang perlu diperhatikan. Pertama, ORDER BY tidak bisa ditawar: tanpanya, "halaman 2" tidak punya arti yang pasti dan baris-baris bisa teracak setiap kali halaman dimuat. Kedua, kunci pengurutannya menyertakan id sebagai penentu saat nilainya sama. Jika dua postingan punya created_at yang sama, kamu butuh kolom unik untuk memberi keduanya urutan yang pasti. Kalau tidak, posisinya bisa bertukar dan sebuah baris bisa bocor ke halaman lain.

Patokannya: urutkan berdasarkan sesuatu yang unik, atau urutkan berdasarkan kolom pengurutanmu ditambah satu kolom unik sebagai penentu.

Bentuk Singkat: LIMIT n, m

SQLite mendukung sintaks koma yang lebih lama demi kompatibilitas dengan MySQL: LIMIT offset, count. Artinya sama dengan LIMIT count OFFSET offset, tapi urutannya terbalik dan mudah salah dibaca.

-- These two are equivalent:
SELECT * FROM books LIMIT 10 OFFSET 20;
SELECT * FROM books LIMIT 20, 10;     -- offset first, then count

Bentuk kedua memang ringkas, tapi sering menjebak orang yang mengira angka pertamanya adalah jumlah baris. Tetap pakai LIMIT n OFFSET k: lebih eksplisit dan terbaca urut dari awal sampai akhir.

OFFSET Tanpa LIMIT: Trik LIMIT -1

OFFSET tidak sah jika berdiri sendiri, karena tata bahasa SQLite mengharuskannya muncul setelah LIMIT. Lalu bagaimana cara mengatakan "lewati 10 baris pertama dan berikan semua sisanya"? Konvensinya adalah LIMIT -1, yang dibaca SQLite sebagai "tanpa batas atas."

CREATE TABLE numbers (n INTEGER);
INSERT INTO numbers (n) VALUES (1), (2), (3), (4), (5), (6), (7), (8);

-- Skip the first 3, return the rest
SELECT n FROM numbers ORDER BY n LIMIT -1 OFFSET 3;

LIMIT negatif apa pun melakukan hal yang sama, tapi -1 adalah idiom yang sudah lazim. Kamu biasanya akan melihat ini di script yang menelusuri hasil per halaman dan butuh query "berikan sisanya" untuk kelompok terakhir.

Jebakan Performa OFFSET

Ini hal yang jarang dibahas sampai kamu sendiri mengalaminya: OFFSET tidak membuat SQLite melewatkan pekerjaan, tapi hanya melewatkan output. Untuk mengembalikan baris ke-10.001 sampai ke-10.020, engine-nya tetap menelusuri sepuluh ribu baris pertama secara internal sebelum mulai mengeluarkan hasil. Offset kecil tidak terasa; offset puluhan atau ratusan ribu jadi terasa lambat.

Untuk pagination yang dalam, solusi standarnya adalah keyset pagination: alih-alih "lewati N baris", ingat kunci pengurutan dari baris terakhir lalu minta "baris setelah yang ini."

CREATE TABLE events (
    id INTEGER PRIMARY KEY,
    created_at TEXT,
    message TEXT
);

INSERT INTO events (created_at, message) VALUES
    ('2024-01-01 10:00', 'login'),
    ('2024-01-01 10:05', 'view'),
    ('2024-01-01 10:10', 'click'),
    ('2024-01-01 10:15', 'logout'),
    ('2024-01-01 10:20', 'login');

-- After receiving id=2, the next page is:
SELECT id, created_at, message
FROM events
WHERE id > 2
ORDER BY id
LIMIT 2;

Setiap halaman melakukan pencarian lewat index, bukan memindai melewati semua baris sebelumnya. Konsekuensinya: kamu tidak bisa melompat ke "halaman 47", hanya maju menelusuri data. Untuk feed infinite scroll dan cursor API, itulah yang kamu butuhkan.

Pagination berbasis OFFSET tidak masalah untuk tabel admin dan hasil query yang kecil. Untuk apa pun yang terus bertambah tanpa batas, pakai keyset pagination.

Contoh Lengkap

Semuanya digabungkan: query pagination dengan filter, pengurutan, dan penentu urutan yang pasti:

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    category TEXT,
    price REAL
);

INSERT INTO products (name, category, price) VALUES
    ('Pen', 'office', 1.50),
    ('Notebook', 'office', 4.00),
    ('Stapler', 'office', 8.00),
    ('Mug', 'kitchen', 6.00),
    ('Kettle', 'kitchen', 25.00),
    ('Toaster', 'kitchen', 30.00);

-- Page 1: cheapest 2 office items, alphabetical on price ties
SELECT name, price
FROM products
WHERE category = 'office'
ORDER BY price ASC, name ASC
LIMIT 2 OFFSET 0;

Saring hanya produk kantor, urutkan berdasarkan harga dari yang termurah dengan nama sebagai penentu saat harganya sama, lalu ambil dua yang pertama. Ganti OFFSET 0 menjadi OFFSET 2 untuk halaman 2. Query-nya pendek, tapi setiap klausanya punya peran.

Selanjutnya: DISTINCT

LIMIT mengatur berapa banyak baris yang dikembalikan; DISTINCT mengatur apakah duplikat dikembalikan atau tidak. Itulah klausa berikutnya di perangkat SELECT, dan klausa ini ternyata mudah disalahgunakan. Topik itu ada di halaman berikutnya.