Buffer pool veritabanının çalışma masası gibidir
InnoDB buffer pool, sık kullanılan veri ve indeks sayfalarının bellekte tutulduğu yerdir. Çalışma masanız küçükse sürekli dolaptan dosya alıp geri koyarsınız; MySQL’de bunun karşılığı daha fazla disk okumasıdır.
Ama çalışma masasını büyütmek her zaman çözüm değildir. Eğer sorgu yanlış indeks yüzünden milyonlarca satır geziyorsa, daha büyük buffer pool yalnızca daha büyük bir sorunu bellekte tutar.
Bellek baskısını okumak için birkaç temel sinyal
MySQL performans teşhisinde tek bir metrik yoktur. Buffer pool okuma isteği, diskten okuma, dirty page ve kullanılabilir sayfa bilgileri birlikte okunur. Amaç, sistem gerçekten diskten mi besleniyor yoksa sorgu planı mı fazla veri okuyor anlamaktır.
InnoDB buffer pool sinyalleri
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages%'; SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
İndeks yoksa RAM konuşması erken başlar
Bir sorgu doğru indeksi kullanmıyorsa buffer pool ne kadar büyük olursa olsun gereksiz veri dolaşır. EXPLAIN çıktısında rows çok yüksekse, filtered düşükse veya type=ALL görünüyorsa önce sorgu planını düzeltmek gerekir.
Planı okumak ve composite index düşünmek
EXPLAIN SELECT id, customer_id, created_at FROM orders WHERE tenant_id = ? AND status = 'paid' AND created_at >= NOW() - INTERVAL 30 DAY ORDER BY created_at DESC LIMIT 100; CREATE INDEX idx_orders_tenant_status_created ON orders (tenant_id, status, created_at DESC);
RAM artırma kararı nasıl daha sağlıklı verilir?
Eğer kritik sorgular doğru indeksleri kullanıyor, bağlantı sayısı kontrol altında, disk okuma hâlâ yüksek ve working set mevcut belleğe sığmıyorsa buffer pool büyütmek anlamlıdır. Ama bu kararı sorgu düzeltmesinden önce verirseniz, pahalı bir rahatlama satın alabilirsiniz.
TürkDB tarafında tier değişikliği kapasiteyi artırabilir; fakat iyi sıra hâlâ aynıdır: önce sorgu ve indeks, sonra pool ve zaman aşımı, en son kaynak büyütme.