İndeks eklemek işleri yavaşlattığında

Günlük rakamları tutan tablonun tek bir anahtarı var: sayaç ve tarih birlikte. Koddaki beş yer bu tabloya farklı bir soru soruyor — “bu sayaç zaman içinde” değil, “bu tarihlerdeki tüm sayaçlar”. Ana sayfadaki galeri, Sıralamalar sayfası, site haritası, 90 günlük bir grafik ve durum rakamları. Tarih sütununda indeks olmadan bunların her biri 114.113 satırın tamamını okuyor.

Bu indeksi eklemek galeriyi on kat hızlandırıyor. Ama eklenmedi. Kararı veren ölçüm aşağıda.

Bir sorgu çok hızlandı

Galeri, bugün etkin olan sayaçları istiyor. Tarih sütununda indeks yokken tablonun tamamını tarıyor; indeks varken tek bir tarihe bakıp 443 satır okuyor. 61,5 milisaniye 6,1 milisaniyeye indi. Bu hiç de belirsiz bir sonuç değil; ölçülen tek şey bu olsaydı, indeks şu an veritabanında olurdu.

İki sorgu yavaşladı

Site haritası on dört günlük veri istiyor ve %19 yavaşladı. Durum rakamları bir yıllık veri istiyor ve %10 yavaşladı. İki durumda da sorgu planlayıcı birincil anahtardan yeni indekse geçti ve daha kötü bir seçim yaptı.

Anlamaya değer kısım burası, çünkü bu, planlayıcıdaki bir hata değil. Bir aralığı ikincil bir indeks üzerinden okumak, eşleşen satırları indekste bulup ardından her birini tablodan getirmek demek. Dar bir dilim için bu kârlı bir alışveriş. On üç aylık verinin on dört günü için ise bu hâlâ tek tek getirilen çok sayıda satır demek ve tablonun düz taranması — yani disklerin ve önbelleklerin sevdiği biçimde, fiziksel sırasıyla okunması — bundan daha hızlı. Planlayıcı bunu bilmiyor. Bir aralık ve bir indeks görüyor ve indeksi seçiyor.

“Bu indeksi yalnızca galeri için kullan” demenin bir yolu yok. Bir indeks, o sütuna dokunan her sorgunun kullanımına açıktır ve planlayıcı, tahminleri nerede gerektiğini söylüyorsa onu orada kullanır. İndeks eklemek, yalnızca hedeflenen sorguyu değil, o tablodaki her sorguyu değiştirmek demektir.

Toplamda: hiçbir şey

Beşinin toplamında 555 milisaniye, 524 milisaniye oldu. 1,1× oranında bir iyileşme; bu sayfaları zaten önbellekten sunan küçük bir sunucuda bu, şema değişikliğine değmez.

90 günlük grafik %9 iyileşmiş gibi görünüyor. Bu sayılmadı ve nedenini söylemeye değer. Her sorgu üç kez ölçüldü: indeks olmadan, indeksle, sonra yine indeks olmadan. İndekssiz ikinci ölçüm birincinin yakınına düşmüyorsa, farkın nedeni değişiklik değil, makinedir. 90 günlük grafikte indekssiz iki ölçüm arasında %13,8 fark vardı — iddia edilen etkiden fazla. Yani o satır hiçbir şey ölçmüyor ve hiçbir şey olarak raporlanıyor.

Nasıl ölçüldü ve bu neden önemli

Canlı tabloda değil. Betik tabloyu kopyalıyor, kopya üzerinde çalışıyor ve sonunda kopyayı siliyor. Ne olacağını görmek için çalışan sistemdeki bir tabloya indeks eklemek, her sürpriz için yalnızca bir kez işe yarar.

Sorgular gerçek sorgular; sayaç tablosuyla birleştirme de dâhil, doğrudan koddan alındı. Bu testin önceki bir sürümü, sorgunun basitleştirilmiş bir benzerini kullanmış ve çok daha heyecan verici bir yanıt üretmişti: yirmi kat daha hızlı. Basitleştirilmiş sorgu, gerçekte hiçbir şeyin çalıştırdığı bir sorgu değildi.

Başka türlü ölçülseydi

Bu iş olağan yoldan ölçülseydi — yavaş gibi gelen sorguyu al, öncesinde ve sonrasında süresini ölç — yanıt “on kat hızlı, yayına al” olurdu. İndeks eklenir, galeri hızlanır, site haritası ile durum sayfası yavaşlar ve kimse ikisi arasında bağ kurmazdı, çünkü o sayfalara bakan kimse yoktu.

İşin genel hâli bu. Ortak altyapıda yapılan bir değişiklik, ona yol açan durum üzerinden değerlendirilemez. Soru “bu, baktığım şeye yardım ediyor mu” değil, “buna başka ne dokunuyor ve ona ne oluyor” sorusudur.

İşe yarayabilecek bir sürüm var: iki sütunu birden taşıyan, tarihin önde olduğu bir indeks; böylece galeri, tabloya geri dönmeden yalnızca indeksten yanıtlanabilir. Böyle bir indeks, geniş aralıklarda planlayıcıyı ayartmayabilir de. Bu ölçülmedi, dolayısıyla bir öneri değil — kopya üzerinde denenecek bir sonraki şey.