Beberapa bulan lalu saya mulai sadar blog ini loading-nya makin lama. Awalnya tidak terlalu kentara, tapi makin ke sini makin terasa. Buka halaman depan, nunggu dua-tiga detik. Buka halaman artikel, sedikit lebih lambat lagi. Saya curiga ada sesuatu yang tidak beres.

Setelah investigasi yang lumayan makan waktu, ketemu juga biang keroknya: query MySQL yang tidak efisien. Dan proses nemuin dan benerin itu yang mau saya ceritain di sini.

Awal Mula: Curiga di Halaman yang Salah

Pertama kali saya curiga ke PHP-nya dulu. Saya pikir ada loop yang terlalu berat, atau ada fungsi yang tidak perlu dipanggil berkali-kali. Saya bongkar kode PHP, cari bagian yang kira-kira makan waktu, tapi tidak ketemu yang jelas mencurigakan.

Lalu saya coba cara sederhana untuk profiling: catat waktu sebelum dan sesudah setiap query besar pakai microtime(true). Hasilnya langsung kelihatan — ada dua query yang masing-masing butuh waktu hampir satu detik. Itu yang bikin loading lama.

Pelajaran pertama dari proses ini: jangan langsung asumsi masalahnya ada di mana. Ukur dulu, baru simpulkan.

Query Pertama: Tidak Ada Index

Query pertama yang bermasalah adalah query untuk menampilkan daftar artikel terbaru di halaman depan. Kira-kira begini querynya:

SELECT * FROM posts ORDER BY created_at DESC LIMIT 10;

Kelihatannya sederhana dan tidak ada yang salah. Tapi ternyata masalahnya ada di kolom created_at yang tidak punya index. Jadi setiap kali query ini dijalankan, MySQL harus scan seluruh tabel untuk mengurutkan datanya — bahasa teknisnya full table scan.

Waktu tabelnya masih kecil, ini tidak terasa. Tapi seiring tabel makin besar, waktu yang dibutuhkan ikut membesar.

Solusinya straightforward: tambahkan index ke kolom created_at.

ALTER TABLE posts ADD INDEX idx_created_at (created_at);

Setelah index ditambahkan, waktu eksekusi query ini turun drastis — dari hampir satu detik jadi di bawah 10 milidetik. Perbedaan yang tidak main-main.

Query Kedua: SELECT * yang Berlebihan

Query kedua yang bermasalah ada di sidebar — bagian yang menampilkan artikel populer. Query-nya pakai SELECT *, artinya semua kolom diambil meskipun yang ditampilkan di sidebar cuma judul dan slug-nya saja.

Ini kebiasaan buruk yang saya bawa sejak awal belajar — pakai SELECT * karena praktis, tidak perlu sebutkan kolom satu per satu. Memang nyaman waktu develop, tapi tidak efisien saat production. Kolom content di tabel posts isinya bisa sangat panjang — ratusan hingga ribuan karakter. Membawa data sebesar itu untuk setiap artikel populer yang ditampilkan di sidebar jelas pemborosan.

Perbaikannya: ganti SELECT * dengan hanya kolom yang benar-benar dibutuhkan.

-- Sebelum (boros)
SELECT * FROM posts WHERE views > 100 ORDER BY views DESC LIMIT 5;


-- Sesudah (efisien)

SELECT id, title, slug, views FROM posts WHERE views > 100 ORDER BY views DESC LIMIT 5;

Perubahan kecil, tapi dampaknya terasa — terutama kalau tabel-nya besar dan query ini dipanggil di setiap halaman.

Satu Hal yang Hampir Saya Lewatkan

Setelah dua perbaikan itu, loading sudah jauh lebih cepat. Tapi waktu saya cek lebih teliti, masih ada satu hal yang lumayan menguras resource: query yang dijalankan di dalam loop.

Di salah satu halaman, ada fitur yang menampilkan artikel terkait berdasarkan kategori. Cara lama saya: ambil id kategori artikel yang sedang dibuka, lalu di dalam loop tampilkan artikel-artikel lain, dan untuk setiap artikel itu query lagi untuk ambil detail kategorinya. Jadi kalau ada 5 artikel terkait, ada 5 query tambahan hanya untuk data kategori. Ini yang sering disebut masalah N+1 query.

Solusinya: gabungkan dengan JOIN dari awal supaya semua data diambil sekaligus dalam satu query, bukan satu per artikel.

Ini yang bikin saya sadar betapa banyak kebiasaan coding yang terbawa dari dulu — kebiasaan yang waktu belajar sendiri tidak ada yang mengoreksi, dan baru ketahuan bermasalah setelah aplikasinya berjalan dengan data yang lebih banyak.

Hasilnya

Setelah semua perbaikan itu diimplementasikan, saya cek loading time halaman depan: turun dari rata-rata 2,8 detik ke sekitar 0,6 detik. Signifikan. Halaman artikel juga ikut lebih responsif.

Saya tidak menggunakan tools profiling yang canggih — cukup microtime() sederhana di PHP dan EXPLAIN di MySQL untuk lihat execution plan setiap query. Alat yang sederhana, tapi cukup untuk menemukan masalah.

Kalau blog atau aplikasi PHP kamu juga mulai terasa lambat, coba cek query-querynya dulu sebelum buru-buru upgrade hosting atau tambah resource. Sering kali masalahnya ada di sana, dan solusinya tidak mahal — hanya perlu waktu untuk dicari.

Ada yang pernah mengalami masalah serupa? Atau punya tips optimasi MySQL lain yang mau dibagikan? Tulis di komentar, saya senang belajar dari pengalaman orang lain juga.