Web Uygulamaları için MySQL Performans İyileştirme ve İndeksleme Teknikleri

Web uygulamalarında veri katmanı genellikle performans darboğazlarının kaynağıdır. MySQL yaygın olarak tercih edilse de, yanlış indeksleme, kötü sorgu tasarımı veya hatalı şema kararları uygulamanın hızını ve ölçeklenebilirliğini olumsuz etkiler. Bu makalede, çalışan yazılımcılar için pratik, uygulanabilir MySQL performans iyileştirme tekniklerini ve modern geçiş alternatiflerini ele alacağım.

Neden İndeksleme Önemli? Temel İlkeler

İndeksler, veritabanındaki satırları arama maliyetini düşürür. Doğru tanımlanmış bir indeks, tam tablo taramalarını (full table scan) engeller ve özellikle WHERE, JOIN, ORDER BY ve GROUP BY operasyonlarında sorgu süresini dramatik şekilde azaltır. Ancak indeksler diskte yer kaplar ve yazma işlemlerinin maliyetini artırır; bu yüzden her sütuna indeks koymak doğru değildir.

İndeks seçiminde dikkat edilmesi gerekenler: seçicilik (selectivity), sütun kombinasyonları ve sorgu desenleri. Yüksek seçiciliğe sahip sütunlar (çok sayıda farklı değer içeriyorsa) indeks için daha uygundur. Ayrıca birden fazla sütun içeren (composite) indeksler, sorguların başında kullanılan sütun sıralamasına bağlı çalışır; bu nedenle indeksleri sorgu kalıplarınıza göre tasarlayınız.

İndeks Türleri ve Ne Zaman Kullanılır

MySQL'te sık kullanılan indeks türleri B-Tree (varsayılan), Hash (Memory/Innodb özel durumlarda) ve FULLTEXT'tir. B-Tree; eşleşmeler, aralık sorguları ve sıralamalar için uygundur. FULLTEXT büyük metin aramalarında kullanışlıdır fakat doğal dil veya boolean modlarında farklı davranır. Hash indeksler ise yalnızca eşleme (equality) sorgularında hızlıdır fakat aralık sorgularında kullanılamaz.

Aşağıda örnek bir composite indeks oluşturma örneği yer alıyor. Diyelim ki kullanıcı sorgularınız genelde WHERE user_id = ? AND status = ? kalıbında; bu durumda birleştirilmiş indeks faydalıdır:

CREATE INDEX idx_user_status ON orders (user_id, status);

Ancak eğer sorgular genelde önce status sonra user_id şeklindeyse, indeks sırası tersine çevrilmelidir. Composite indeksin ilk sütunu sorguda sık kullanılan ve selektif olan sütun olmalıdır.

Sorgu İncelemesi: EXPLAIN ve Profiling

Bir sorgunun neden yavaş olduğunu anlamanın en etkili yolu EXPLAIN komutunu kullanmaktır. EXPLAIN, sorgunun hangi indeksleri kullandığını, tahmini satır sayısını ve bir JOIN planı varsa birleşme sırasını gösterir. Her zaman EXPLAIN çıktısını sorgu ile birlikte değerlendiriniz.

Basit bir örnek ile başlayalım. Aşağıdaki sorgu verimsiz bir şekilde tam tablo taraması yapıyor olabilir:

EXPLAIN SELECT * FROM orders WHERE created_at > '2024-01-01' AND status = 'paid';

EXPLAIN sonucu full table scan (type = ALL) gösteriyorsa, uygun bir indeks oluşturmak gerekir. Tarih aralığı ve status beraber kullanılıyorsa composite indeks şu şekilde eklenebilir:

CREATE INDEX idx_created_status ON orders (status, created_at);

Ayrıca MySQL'in slow_query_log fonksiyonunu açıp yavaş sorguları toplamak ve pt-query-digest gibi araçlarla analiz etmek, gerçek kullanımda hangi sorguların optimizasyona ihtiyaç duyduğunu belirlemede etkilidir.

Şema Tasarımı, Normalizasyon ve Denormalizasyon

İyi bir şema tasarımı uzun vadede performansı belirler. Normalizasyon veri tutarlılığı sağlar ancak çok sayıda JOIN gerektiren sorgular performansı düşürebilir. Web uygulamalarında sıkça kullanılan pattern, kritik sorgular için kontrollü denormalizasyondur: sık erişilen verilere kısmi tekrar ekleyerek JOIN sayısını azaltabilirsiniz.

Örnek: bir kullanıcının sık erişilen profil bilgilerini ayrı bir cache tablosunda veya kullanıcı tablosunda saklamak, her sayfa isteğinde profil için ek JOIN yapılmasını engeller. Ancak denormalizasyon ek karmaşıklık getirir; veri tutarlılığı için güncelleme işlemlerinde ekstra dikkat gerekebilir. Transaction ve trigger kullanımı ile tutarlılık sağlanabilir ama performans maliyetleri değerlendirilmelidir.

Partitioning, Caching ve Yatay Ölçekleme

Büyük tablolar için partitioning, sorgu performansını ve yönetimi iyileştirebilir. Örneğin zaman bazlı verileri tarihe göre partition edip eski verileri kolayca arşivleyebilirsiniz. Ancak partitioning her durumda çözüm değildir; sorgu desenleriniz partition key ile uyumlu olmalıdır.

Uygulama seviyesinde cache (Redis, Memcached) kullanımı, veritabanı yükünü azaltmanın en etkili yollarından biridir. Sık sorgulanan ama az değişen verileri cache'e koyarak veritabanına yapılan istek sayısını düşürebilirsiniz. Ayrıca okuma ağırlıklı yüklerde read-replica olan bir mimari ile yatay ölçeklemek, yazma işlemleri sınırlıysa iyi bir yaklaşımdır.

Geçiş ve Modern Alternatifler

MySQL iyi desteklenen, olgun bir veritabanıdır fakat bazı senaryolarda farklı ihtiyaçlar için alternatifler daha uygun olabilir. Örneğin yoğun analitik sorgular veya güçlü ilişkisel bütünlük gerektiren uygulamalarda PostgreSQL daha zengin özellik seti (JSONB, gelişmiş indeksleme, gelişmiş sorgu optimizasyonları) sunar. MariaDB ise MySQL ile uyumluluğu korurken bazı performans ve özellik avantajları sağlayabilir.

Geçiş planlarken dikkat edilmesi gerekenler: SQL uyumluluğu, saklı prosedürler/triggers, karakter setleri ve indeksleme stratejileri. Geçiş genelde adım adım yapılmalı; önce test ortamında uyumluluk ve performans ölçümleri yapılmalı, ardından read-replica veya paralel çalıştırma ile canlıya alım planlanmalıdır. Bu süreçte uygulama kodunda sorgu kalıplarını ve ORM kullanımını gözden geçirmek de önemlidir.

Sık Sorulan Sorular

1) Hangi sütunlara indeks koymalıyım?

Öncelikle WHERE, JOIN, ORDER BY ve GROUP BY içinde sık kullanılan sütunlar indeks adayıdır. Yüksek seçiciliğe sahip sütunlar genelde daha etkilidir. Ancak yazma yoğunluğu yüksek tablolarda her indeks yazma maliyetini artıracağı için, sadece sorgu performansını ölçerek ve EXPLAIN çıktılarına bakarak karar verin.

2) Composite indeks mi yoksa çoklu tek sütun indeksi mi daha iyi?

Composite indeks, sorgunun aynı sırada kullandığı birden fazla sütun varsa tek bir indeksle daha verimli çalışır. Çoklu tek sütun indeksler, MySQL bazı durumlarda index merge yapabilir ama genelde composite indeks daha hızlıdır. İndeksin sütun sırasının sorgu kalıbıyla uyumlu olduğundan emin olun.

3) ORM kullandığımda performansı nasıl koruyabilirim?

ORM katmanı bazen gereksiz JOIN veya N+1 sorgulara yol açar. Bu nedenle ORM'in ürettiği sorguları düzenli olarak izleyin ve gerektiğinde custom SQL veya eager loading kullanın. Ayrıca sık kullanılan sorguları cache'e almak ve sorgu loglarını incelemek önemlidir.

Sonuç

MySQL performansını iyileştirmek, doğru indeksleme, sorgu inceleme ve şema tasarımı kombinasyonuyla mümkün. EXPLAIN kullanımı, slow query log analizi ve uygulama tarafı cache stratejileri günlük operasyonlarda en çok fark yaratan adımlardır. Geçiş ihtiyacı doğduğunda PostgreSQL veya MariaDB gibi alternatifler değerlendirilmelidir; ancak planlı ve test edilmiş bir geçiş stratejisi şarttır.

Eğitim bağlantısı: [Eğitim bağlantısı eklenecek]