Ketika menambahkan indeks justru memperlambat

Tabel angka harian memiliki satu kunci: penghitung dan tanggal sekaligus. Lima tempat dalam kode mengajukan pertanyaan yang berbeda kepadanya — bukan “penghitung ini dari waktu ke waktu”, melainkan “semua penghitung pada tanggal-tanggal ini”. Galeri beranda, daftar teratas, sitemap, diagram 90 hari, dan angka status. Tanpa indeks pada kolom tanggal, masing-masing membaca seluruh 114.113 baris.

Menambahkan indeks itu membuat galeri sepuluh kali lebih cepat. Indeks itu tidak ditambahkan. Inilah pengukuran yang memutuskannya.

Satu kueri menjadi jauh lebih cepat

Galeri meminta penghitung yang aktif hari ini. Tanpa indeks pada tanggal, kueri itu memindai seluruh tabel; dengan indeks, kueri itu mencari satu tanggal dan membaca 443 baris. 61,5 milidetik menjadi 6,1. Itu bukan hasil yang samar, dan seandainya hanya itu yang diukur, indeks itu kini sudah ada di basis data.

Dua kueri menjadi lebih lambat

Sitemap meminta empat belas hari dan menjadi 19% lebih lambat. Angka status meminta satu tahun dan menjadi 10% lebih lambat. Dalam kedua kasus, perencana kueri beralih dari kunci primer ke indeks baru dan membuat pilihan yang lebih buruk.

Inilah bagian yang layak dipahami, karena ini bukan bug pada perencana. Membaca sebuah rentang melalui indeks sekunder berarti menemukan baris yang cocok di indeks lalu mengambil masing-masing dari tabel. Untuk irisan yang sempit, itu sangat menguntungkan. Untuk empat belas hari dari tiga belas bulan, jumlah baris yang diambil satu per satu masih banyak, dan pemindaian langsung atas tabel — membacanya dalam urutan fisik, yang disukai disk dan cache — mengalahkannya. Perencana tidak mengetahui hal itu. Ia melihat sebuah rentang dan sebuah indeks, lalu memakainya.

Tidak ada cara untuk mengatakan “gunakan indeks ini hanya untuk galeri.” Indeks tersedia bagi setiap kueri yang menyentuh kolom tersebut, dan perencana akan menggunakannya di mana pun perkiraannya menyatakan demikian. Menambahkan indeks adalah perubahan pada setiap kueri terhadap tabel itu, bukan hanya pada kueri yang dituju.

Secara keseluruhan: tidak ada apa-apa

Di seluruh lima kueri, 555 milidetik menjadi 524. Peningkatan 1,1×, yang pada server kecil yang toh menyajikan halaman-halaman ini dari cache tidak sepadan dengan perubahan skema.

Diagram 90 hari tampak membaik sebesar 9%. Angka itu tidak dihitung, dan alasannya layak disebutkan. Setiap kueri diukur dalam tiga putaran: tanpa indeks, dengan indeks, lalu tanpa indeks lagi. Jika putaran kedua tanpa indeks tidak mendarat di dekat putaran pertama, perbedaannya berasal dari mesin, bukan dari perubahan. Untuk diagram 90 hari, kedua putaran tanpa indeks berbeda 13,8% — lebih besar daripada efek yang diklaim. Jadi baris itu tidak mengukur apa pun, dan dilaporkan sebagai tidak ada apa-apa.

Bagaimana ini diukur, dan mengapa itu penting

Bukan pada tabel yang sedang dipakai. Skripnya menyalin tabel itu, bekerja pada salinannya, dan menghapus salinan itu di akhir. Menambahkan indeks ke tabel produksi demi melihat apa yang terjadi hanya berhasil sekali per kejutan.

Kuerinya adalah kueri yang sebenarnya, diambil dari kode, termasuk join ke tabel penghitung. Versi awal dari uji ini memakai pengganti yang disederhanakan dan menghasilkan jawaban yang jauh lebih menggairahkan: dua puluh kali lebih cepat. Kueri yang disederhanakan itu bukan kueri yang benar-benar dijalankan oleh apa pun.

Angka yang akan diperoleh

Seandainya ini diukur dengan cara biasa — ambil kueri yang terasa lambat, ukur waktunya sebelum dan sesudah — jawabannya akan berupa “sepuluh kali lebih cepat, terapkan”. Indeksnya akan masuk, galeri akan menjadi lebih cepat, sitemap dan halaman status akan menjadi lebih lambat, dan tidak ada yang akan menghubungkan keduanya, karena tidak ada yang mengamati keduanya.

Itulah bentuk umumnya. Perubahan pada infrastruktur bersama tidak dapat dinilai berdasarkan kasus yang memicunya. Pertanyaannya bukan “apakah ini membantu hal yang sedang saya lihat”, melainkan “apa lagi yang menyentuh ini, dan apa yang terjadi padanya”.

Ada versi yang mungkin berhasil: indeks yang memuat kedua kolom, tanggal lebih dulu, sehingga galeri dapat dijawab dari indeks saja tanpa kembali ke tabel. Indeks itu mungkin juga tidak menggoda perencana pada rentang yang lebih lebar. Hal itu belum diukur, jadi ini bukan rekomendasi — ini hal berikutnya yang akan dicoba pada salinan.