Veritabanı Performans Optimizasyonu ve İndeksleme Stratejileri [2026]

Veritabanı Performansı Neden Kritiktir?

Bir uygulama ne kadar iyi tasarlanmış olursa olsun, veritabanı katmanındaki darboğazlar tüm sistemi yavaşlatır. Kullanıcı deneyimini doğrudan etkileyen sayfa yüklenme süreleri, API yanıt süreleri ve toplu işlem performansı gibi metrikler genellikle veritabanı performansına bağlıdır. Araştırmalar, 100 milisaniyelik ek gecikmenin dönüşüm oranlarını yüzde yediye kadar düşürebildiğini göstermektedir.

Veritabanı optimizasyonu, yalnızca büyük ölçekli sistemlerin sorunu değildir. Günlük binlerce istek alan orta ölçekli bir uygulamada bile yanlış tasarlanmış bir sorgu veya eksik bir indeks, ciddi performans sorunlarına yol açabilir. Üstelik bu sorunlar genellikle kademeli olarak ortaya çıkar: Sistem ilk aylarda sorunsuz çalışır, ancak veri hacmi büyüdükçe yanıt süreleri uzamaya başlar. Erken aşamada fark edilmeyen bir full table scan, tablodaki kayıt sayısı milyonlara ulaştığında uygulamayı tamamen kullanılamaz hale getirebilir.

Performans Sorunlarının Temel Nedenleri

Veritabanı yavaşlığının ardında genellikle birkaç tekrar eden neden bulunur:

Sorun Kategorisi	Belirtiler	Sıklık
Eksik veya yanlış indeksler	Full table scan, yüksek I/O	Çok yaygın
N+1 sorgu problemi	Binlerce küçük sorgu, yüksek latency	Yaygın
Yetersiz connection pool	Bağlantı bekleme, timeout hataları	Orta
Denormalizasyon eksikliği	Karmaşık JOIN'ler, yavaş raporlama	Orta
Kötü yazılmış sorgular	Gereksiz veri çekme, SELECT * kullanımı	Çok yaygın
Lock contention	Deadlock, uzun bekleme süreleri	Duruma bağlı

Bu sorunların büyük çoğunluğu, doğru indeksleme stratejileri ve sorgu optimizasyonu ile çözülebilir. Daha karmaşık senaryolarda ise mimari düzeyde değişiklikler -- denormalizasyon, caching katmanı veya read replica eklenmesi gibi -- gerekebilir.

İndeks Türleri ve Çalışma Prensipleri

İndeksler, veritabanının veriyi daha hızlı bulmasını sağlayan veri yapılarıdır. Bir kitabın sonundaki dizin nasıl aradığınız konuyu hızlıca bulmanızı sağlıyorsa, veritabanı indeksleri de aynı mantıkla çalışır.

B-Tree İndeks

En yaygın indeks türüdür. PostgreSQL, MySQL, Oracle ve SQL Server dahil neredeyse tüm ilişkisel veritabanlarında varsayılan indeks yapısıdır. Dengeli ağaç (balanced tree) yapısı sayesinde arama, ekleme ve silme işlemlerini O(log n) karmaşıklığında gerçekleştirir. Eşitlik sorguları, aralık sorguları (BETWEEN, >, <), sıralama (ORDER BY) ve gruplama (GROUP BY) işlemleri için uygundur. Milyonlarca kayıt içeren bir tabloda bile sadece birkaç disk okuma işlemiyle hedef veriye ulaşılabilir.

Hash İndeks

Yalnızca eşitlik karşılaştırmaları için optimize edilmiştir. Aralık sorguları desteklenmez. MongoDB gibi NoSQL veritabanlarında ve Redis gibi anahtar-değer depolarında sıklıkla kullanılır. Tam eşleşme aramaları (lookup) için B-Tree'den daha hızlıdır, ancak kullanım alanı daha sınırlıdır. O(1) ortalama erişim süresi sunar.

Bitmap İndeks

Düşük kardinaliteye sahip sütunlar (cinsiyet, durum, kategori gibi az sayıda benzersiz değer içeren alanlar) için idealdir. Veri ambarı (data warehouse) ve OLAP senaryolarında yaygın olarak tercih edilir. Her benzersiz değer için bir bit dizisi oluşturur ve bitwise operasyonlarla sorguları hızlandırır. OLTP sistemlerinde eş zamanlı yazma işlemlerinin neden olduğu kilit çekişmesi (lock contention) yüzünden genellikle önerilmez.

Covering İndeks

Sorgunun ihtiyaç duyduğu tüm sütunları indeks içinde barındırır. Tablo verisine geri dönüş (table lookup veya bookmark lookup) gerektirmediği için en hızlı okuma performansını sunar. "Index-only scan" olarak adlandırılan bu yöntem, disk I/O'sunu önemli ölçüde azaltır. Sık çalışan ve belirli sütunları sorgulayan işlemler için güçlü bir optimizasyon aracıdır.

İndeks Türü	En İyi Kullanım Alanı	Aralık Sorgusu	Yazma Maliyeti
B-Tree	Genel amaçlı sorgular	Destekler	Orta
Hash	Tam eşleşme aramaları	Desteklemez	Düşük
Bitmap	Düşük kardinalite, OLAP	Destekler	Yüksek
Covering	Sık çalışan spesifik sorgular	B-Tree bazlı ise destekler	Yüksek

İndeks Tasarım Stratejileri

Doğru indeks tasarımı, rastgele indeks eklemekten çok daha etkilidir. Her eklenen indeks yazma işlemlerini yavaşlatır ve disk alanı tüketir. Bu nedenle indeks stratejisi, sorgu desenlerinin dikkatli analiziyle belirlenmelidir.

Selectivity (Seçicilik)

Bir sütundaki benzersiz değer oranı ne kadar yüksekse, o sütundaki indeks o kadar etkili olur. Seçicilik formülü: benzersiz değer sayısı / toplam satır sayısı. Bir kullanıcı tablosundaki e-posta sütunu 1.0'a yakın seçiciliğe sahipken (her e-posta benzersiz), boolean tipindeki aktiflik sütunu 0.000002 gibi çok düşük bir seçiciliğe sahip olabilir. Veritabanı optimize edicisi, düşük seçiciliğe sahip sütunlardaki indeksi genellikle yok sayar ve doğrudan tablo taramasını tercih eder.

Composite Index Sıralaması

Birden fazla sütun içeren bileşik indekslerde sütun sırası kritik öneme sahiptir. Genel kural olarak, WHERE koşulunda eşitlik ile filtrelenen sütunlar önce, aralık sorgusu yapılan sütunlar sonra yer almalıdır. Örneğin, WHERE status = 'active' AND created_at > '2026-01-01' sorgusu için (status, created_at) sıralaması doğru tercihtir. Ters sıralama durumunda indeks tam verimle kullanılamaz. Bileşik indeksin en soldaki sütununu (leftmost prefix) içermeyen sorgular ise indeksten faydalanamaz.

Partial (Kısmi) İndeks

Tablonun yalnızca belirli bir alt kümesini indeksleyen yapılardır. Büyük tablolarda, sorguların yalnızca belirli koşullara uyan satırlara yöneldiği durumlarda hem depolama hem de yazma maliyetinden tasarruf sağlar. Siparişler tablosunda yalnızca aktif siparişleri indekslemek, milyonlarca arşivlenmiş kaydı indeks dışında bırakarak indeks boyutunu dramatik ölçüde küçültür.

Sorgu Optimizasyonu ve Execution Plan Okuma

Performans sorunlarını teşhis etmenin en güvenilir yolu, execution plan (çalışma planı) analizidir. Veritabanı motorunun bir sorguyu nasıl çalıştıracağını gösteren bu planlar, darboğazları tespit etmek için birincil araçtır. EXPLAIN (PostgreSQL, MySQL) veya SET STATISTICS IO ON (SQL Server) komutları ile erişilebilir. Dikkat edilmesi gereken başlıca unsurlar:

• Seq Scan / Full Table Scan: Tüm tablonun tarandığını gösterir. Küçük tablolarda kabul edilebilir, büyük tablolarda ciddi bir performans sorunudur.
• Index Scan / Index Seek: İndeks kullanıldığını gösterir. Genellikle tercih edilen erişim yöntemidir.
• Nested Loop / Hash Join / Merge Join: Tabloların birleştirilme yöntemidir. Küçük tablolarla nested loop verimlidir; büyük tablolarda hash join veya merge join tercih edilir.
• Sort: Sıralama işleminin bellekte (in-memory) mi yoksa diskte (on-disk) mi yapıldığını kontrol etmek önemlidir. Disk sıralaması ciddi yavaşlamaya neden olur.
• Estimated vs Actual Rows: Tahmini satır sayısı ile gerçek satır sayısı arasındaki büyük fark, veritabanı istatistiklerinin güncel olmadığını ve ANALYZE/UPDATE STATISTICS çalıştırılması gerektiğini gösterir.

Sorgu optimizasyonunda sık yapılan hatalar arasında SELECT * kullanımı, gereksiz alt sorgular (subquery yerine JOIN kullanılabilir), WHERE koşulunda sütuna fonksiyon uygulamak (indeksin devre dışı kalmasına neden olur) ve LIKE aramasında başa yüzde karakteri koymak (LIKE '%arama') sayılabilir.

N+1 Sorgu Problemi ve Çözüm Yöntemleri

N+1 problemi, veritabanı performans sorunlarının en yaygın ve sinsi olanlarından biridir. Bir ana sorgu (1) çalıştırıldıktan sonra, dönen her satır için ayrı bir sorgu (N) daha çalıştırılmasıyla ortaya çıkar. 100 siparişi listeleyip her siparişin müşteri bilgisini ayrı sorguyla çekmek, toplamda 101 veritabanı çağrısına neden olur. Ağ gecikmesi olan ortamlarda bu sorun yanıt süresini saniyeler mertebesine çıkarabilir. Çözüm yöntemleri: JOIN ile tek sorguda veri çekmek, IN clause ile toplu sorgulama yapmak (WHERE customer_id IN (1, 2, 3, ...)) ve ORM seviyesinde eager loading kullanmak. Doğru yaklaşım, 101 sorguyu tek bir sorguya indirgeyebilir.

ORM Performans Tuzakları

ORM araçları (Hibernate, Entity Framework, Django ORM, ActiveRecord, Sequelize) geliştirme hızını artırır, ancak dikkatli kullanılmadığında performans sorunlarına zemin hazırlar.

Lazy Loading vs Eager Loading vs Batch Fetching

Lazy loading, varsayılan olarak ilişkili verileri yüklemez ve erişildiğinde ayrı sorgu atar. N+1 probleminin başlıca kaynağıdır. Geliştirme sırasında az veriyle sorunsuz çalışır, veri arttıkça performans dramatik biçimde düşer. Eager loading ise ilişkili verileri ana sorguyla birlikte yükler. N+1 problemini çözer, ancak her zaman ihtiyaç duyulmayan verilerin de yüklenmesine neden olabilir. Hangi ilişkilerin eager, hangilerinin lazy yükleneceği bilinçli bir tasarım kararı olmalıdır.

Batch fetching, her iki yaklaşım arasında bir orta yol sunar. İlişkili verileri belirli bir grup boyutuyla (batch size) toplu olarak yükler ve N+1 sorgu sayısını N/batch_size + 1'e düşürür. Ayrıca ORM'lerin ürettiği SQL'i düzenli olarak log'layarak kontrol etmek, beklenmeyen sorguları erken aşamada tespit etmeyi sağlar.

Connection Pool Yönetimi ve Boyutlandırma

Her veritabanı bağlantısının açılması TCP handshake, kimlik doğrulama ve oturum başlatma gibi maliyetli adımları içerir. Connection pool (HikariCP, PgBouncer, c3p0), önceden açılmış bağlantıları yeniden kullanarak bu maliyeti ortadan kaldırır. Doğru pool boyutunu belirlemek için yaygın formül: Pool boyutu = (CPU cekirdek sayisi x 2) + disk sayisi. 4 cekirdekli bir sunucuda tek SSD ile ideal pool boyutu yaklaşık 9 olur. Bu rakam şaşırtıcı derecede düşük görünse de, araştırmalar aşırı büyük pool boyutlarının aslında performansı düşürdüğünü göstermektedir. Her bağlantı bellek tüketir, context switching maliyeti yaratır ve veritabanı tarafında işlem yönetimi yükünü artırır. Pool yapılandırmasında min idle, max pool size, connection timeout ve idle timeout parametreleri dikkatle ayarlanmalıdır.

Slow Query Log Analizi ve Monitoring

Yavaş sorguları tespit etmek, optimizasyonun ilk adımıdır. Hemen hemen tüm veritabanı sistemleri, belirli bir eşik süresinin üzerinde çalışan sorguları kaydetme imkanı sunar. Etkili bir analiz süreci şu adımları içerir:

1. Eşik belirleme: Başlangıç olarak 1 saniye makul bir eşiktir. Sistem olgunlaştıkça 500ms, hatta 100ms'ye düşürülebilir.
2. Sıklık analizi: En yavaş sorgu yerine, toplamda en çok zaman harcanan sorgu önceliklendirilmelidir. 50ms'de çalışan ama saniyede 1000 kez çağrılan bir sorgu, 5 saniyede çalışan ama günde bir kez çağrılan sorgudan daha kritiktir.
3. Execution plan inceleme: Tespit edilen sorguların çalışma planları analiz edilmelidir.
4. İndeks önerisi: Eksik indeksler oluşturulmalı, gereksiz ve kullanılmayan indeksler kaldırılmalıdır.
5. Doğrulama: Yapılan değişikliklerin etkisi, production benzeri veri hacmiyle ölçülmelidir.

Veritabanı Profiling Araçları

Her veritabanı ekosistemi kendi profiling araçlarını sunar. Doğru araçları kullanmak, sorunları hızlıca tespit etmeyi sağlar.

Veritabanı	Yerleşik Araçlar	Harici Araçlar
PostgreSQL	pg_stat_statements, EXPLAIN ANALYZE	pganalyze, pgBadger
MySQL	Performance Schema, EXPLAIN	Percona Toolkit, MySQL Workbench
MongoDB	Database Profiler, explain()	MongoDB Compass, mtools
SQL Server	Query Store, Execution Plans	SolarWinds DPA, SentryOne

pg_stat_statements gibi uzantılar, tüm sorguların istatistiklerini (toplam süre, çağrılma sayısı, ortalama süre, satır sayısı) toplar ve en maliyetli sorguların tespitini kolaylaştırır. Bu araçların production ortamında aktif tutulması, performans regresyonlarını erken yakalamak açısından kritiktir.

Denormalizasyon Ne Zaman Gerekli?

Normalizasyon veri bütünlüğünü korur ve tekrarı önler, ancak bazı durumlarda performans kazanımı için kontrollü denormalizasyon gerekebilir. Denormalizasyonun gerekli olduğu durumlar: sık çalışan ve birden fazla tabloyu birleştiren raporlama sorguları, okuma yoğun sistemlerde JOIN maliyetinin kabul edilemez düzeyde olması ve gerçek zamanlı dashboard'lar için düşük gecikme gerekliliği. Ancak riskleri -- veri tutarsızlığı, artan yazma maliyeti ve bakım karmaşıklığı -- göz ardı edilmemelidir. Denormalize edilen verilerin güncellenmesi için trigger, uygulama katmanı senkronizasyonu veya event-driven güncelleme mekanizmaları gerekir.

Materialized View Kullanımı

Materialized view, bir sorgunun sonucunu fiziksel olarak saklayan yapılardır. Normal view'dan farklı olarak, sorgu her çağrıda yeniden çalıştırılmaz; önceden hesaplanmış sonuç döndürülür. Karmaşık aggregate sorguları, çok tablolu JOIN'ler ve raporlama sorguları için ideal bir çözümdür. Dezavantajı, verinin güncelliğinin yenileme (refresh) stratejisine bağlı olmasıdır. Periyodik yenileme (her 5 dakika, her saat) veya artımlı yenileme (incremental refresh) seçenekleri kullanım senaryosuna göre değerlendirilmelidir. Materialized view, denormalizasyonun yapısal risklerini azaltır: kaynak tablolardaki veri bütünlüğü korunurken, okuma performansı denormalize yapıya yakın seviyeye çıkarılabilir.

Veritabanı Monitoring ve Alerting

Proaktif izleme, sorunları kullanıcılar fark etmeden yakalamayı sağlar. Modern veritabanı monitoring altyapısı genellikle üç katmandan oluşur.

Metrik toplama (Prometheus, Datadog): Bağlantı sayısı, sorgu süresi, cache hit oranı, disk I/O, replikasyon gecikmesi, tablo boyutları ve kilit bekleme süreleri gibi metriklerin düzenli olarak toplanması. Prometheus ile postgres_exporter veya mysqld_exporter kullanılarak bu metrikler kolayca elde edilebilir.

Görselleştirme (Grafana): Toplanan metriklerin anlamlı dashboard'larda sunulması. Zaman serisi grafikleri, trend analizi ve karşılaştırmalı görünümler performans değişimlerini görünür kılar. Deployment sonrası before/after karşılaştırmaları özellikle değerlidir.

Alerting: Kritik eşiklerin aşılması durumunda ekibin bilgilendirilmesi. Bağlantı havuzunun yüzde 80 doluluk oranına ulaşması, ortalama sorgu süresinin belirlenen eşiği aşması veya replikasyon gecikmesinin artması gibi durumlar alarm tetiklemelidir. İzlenmesi gereken temel metrikler: query throughput (saniyedeki sorgu sayısı), query latency (p50, p95, p99 yüzdelikleri), connection utilization, cache hit ratio (yüzde 99 üzeri hedeflenmeli), replication lag ve disk I/O wait.

Sonuc

Veritabanı performans optimizasyonu, tek seferlik bir görev değil sürekli bir süreçtir. Doğru indeksleme stratejileri ve sorgu optimizasyonu ile çoğu performans sorunu çözülebilir. N+1 problemi ve ORM tuzaklarına karşı farkındalık, uygulama katmanındaki sorunları önler. Connection pool yönetimi ve monitoring altyapısı ise sistemin sağlıklı kalmasını garanti eder.

Smart Maple olarak Ankara merkezli yazılım projelerimizde, veritabanı performansını başlangıçtan itibaren tasarım sürecinin ayrılmaz bir parçası olarak ele alıyoruz. Doğru temeller atıldığında, ölçeklendirme sürecinde karşılaşılan sorunlar büyük ölçüde azalır ve uygulama güvenilir bir şekilde büyüyebilir.