Pagination yang melibatkan tabel berukuran besar sering kali menjadi titik lemah utama dalam aplikasi CodeIgniter 4. Untuk mengatasi kelambanan ini, artikel ini langsung menunjukkan langkah praktis: gunakan profiler/EXPLAIN untuk mengidentifikasi query bermasalah, petakan pertumbuhan data, evaluasi indexing (komposit vs partial), dan pindah ke pagination keyset ketika offset menjadi tidak efisien.

Setiap langkah menyertakan contoh query, metrik sebelum dan sesudah optimasi, serta tip monitoring untuk mendeteksi regresi saat data bertumbuh. Fokusnya bukan sekadar teori, tapi apa yang bisa Anda implementasikan dalam projek CodeIgniter Anda hari ini.

Mengidentifikasi Query Pagination Lambat

Mulailah dengan alat profiling bawaan CodeIgniter 4 atau debug toolbar untuk merekam waktu eksekusi query. Di controller, aktifkan profiler sebelum mengeluarkan hasil pagination:

DEBUG_ENABLE => true pada app/Config/Toolbar.php
$pager => $model->paginate(20);

Lalu, di toolbar Anda akan melihat query yang paling lambat. Untuk analisis lebih rinci, jalankan EXPLAIN terhadap query tersebut di MySQL/PostgreSQL. Contoh query:

SELECT id, nama, created_at FROM aktivitas ORDER BY created_at DESC LIMIT 20 OFFSET 40000;

EXPLAIN menunjukkan apakah terjadi full table scan atau indeks tidak digunakan. Catat kolom yang digunakan di WHERE/ORDER dan ukuran tabel saat ini («misal ~10 juta baris»).

Pemetaan Pertumbuhan Data dan Dampaknya

Setiap pagination offset cenderung melambat seiring pertumbuhan data. Hitung laju penambahan baris dalam periode tertentu (misal per minggu) dengan query seperti:

SELECT DATE(created_at) AS hari, COUNT(*) AS jumlah FROM aktivitas GROUP BY hari ORDER BY hari DESC LIMIT 7;

Data ini membantu menentukan kapan pengindeksan perlu disesuaikan dan kapan perlu peralihan strategi pagination. Jika volume tumbuh 50K baris per minggu dan query sekarang sudah menyentuh offset di atas 40K, maka angka tersebut menjadi batas kesiapan.

Menguji Index Komposit vs Partial

Berdasarkan EXPLAIN, tentukan kolom mana yang mempengaruhi ORDER BY dan WHERE. Misal query menggunakan created_at dan status. Coba indeks komposit:

ALTER TABLE aktivitas ADD INDEX idx_status_created (status, created_at DESC);

Versi MySQL mendukung indeks dengan urutan DESC; PostgreSQL juga mendukung. Jika sebagian besar query hanya memfilter subset (contoh status = 'aktif'), pertimbangkan partial index (PostgreSQL) atau filtered index (SQL Server) seperti:

CREATE INDEX idx_aktif_created ON aktivitas (created_at DESC) WHERE status = 'aktif';

Bandingkan waktu query dengan EXPLAIN ANALYZE atau profil CodeIgniter: sebelum optimasi bisa 3 detik, setelah indeks komposit 400 ms—perlu dicatat dalam logging.

Berpindah ke Pagination Keyset atau Cursor

Offset pagination berjalan lambat karena database masih memindai semua baris sebelumnya. Keyset pagination menggunakan nilai terakhir dari halaman sebelumnya untuk mengambil data selanjutnya tanpa OFFSET:

$lastCreatedAt = $this->request->getGet('after');
$query = $builder->orderBy('created_at', 'DESC')
               ->limit(20);
if ($lastCreatedAt) {
    $query->where('created_at <', $lastCreatedAt);
}
$data = $query->get()->getResult();

Pada contoh ini, Anda hanya memerlukan indeks pada created_at (dan status jika ada filter tambahan), dan query tetap konsisten walaupun dataset tumbuh drastis. Pastikan front-end menyimpan nilai cursor terakhir dan menanganinya saat pengguna menekan “Next”.

Monitoring dan Menghindari Regresi

Setelah mengimplementasikan optimasi, pantau terus query di log produksi. Tambahkan metric sederhana seperti rata-rata waktu query per endpoint pagination dalam Prometheus atau App Insights. Setiap perubahan schema harus diuji ulang: gunakan data staging dengan ukuran mendekati produksi, lalu bandingkan metrik waktu dan rows scanned di EXPLAIN.

Tips menghindari regresi:

  • Automasi pengujian performa dengan script yang menjalankan pagination target dan memeriksa limit waktu.
  • Gunakan migration untuk indeks baru sehingga rollback jelas.
  • Catat metrik baseline sebelum dan sesudah: misal throughput 26 halaman/detik dan latency 3s menjadi 150 halaman/detik dan latency 350 ms.

Ringkasan

Profiling query pagination lambat menyimpan banyak waktu pengembang. Dengan memetakan pertumbuhan data, mencoba indeks komposit atau partial, serta beralih ke pagination keyset saat offset tidak lagi efisien, Anda mempertahankan pengalaman pengguna meski tabel terus membesar. Lengkapi dengan monitoring dan migration terstruktur untuk menjaga performa berkelanjutan.