SQL Performansını Uçurmak: Indexleme, Hashing & Sorgu Optimizasyonu

Veritabanı performansı, modern uygulamaların en kritik başarı faktörlerinden biridir. Yavaş yüklenen sayfalar, takılan uygulamalar veya yanıt vermeyen sistemler, kullanıcı deneyimini doğrudan olumsuz etkileyerek müşteri kaybına ve iş sürekliliği sorunlarına yol açabilir. Günümüzün veri odaklı dünyasında, veritabanları sürekli büyüyor, karmaşıklaşıyor ve bu durum, sorgu sürelerinin artmasına neden oluyor. Peki, bu kaçınılmaz bir kader mi? Elbette hayır!

Bu kapsamlı makalede, SQL veritabanlarınızın performansını artırmak için kullanabileceğiniz en güçlü teknikleri detaylıca inceleyeceğiz: Indexleme, Hashing ve Sorgu Optimizasyonu. Bu teknikler, veritabanınızın kalbinde yatan veri erişim mekanizmalarını ve sorgu işleyişini temelden değiştirerek, uygulamalarınızın gözle görülür şekilde hızlanmasını sağlayacaktır. Konuya yabancı olanlardan deneyimli profesyonellere kadar her seviyeden okuyucunun faydalanabileceği bir yolculuğa çıkmaya hazır olun. Adım adım örnekler, gerçek dünya senaryoları ve pratik ipuçlarıyla, SQL performansınızı zirveye taşıyacak bilgi ve becerileri kazanacaksınız. Amacımız, sadece teorik bilgi vermekle kalmayıp, bu bilgiyi doğrudan projelerinize uygulayabilmenizi sağlamaktır. Bu yolculukta sizinle birlikte, en sık karşılaşılan performans sorunlarının kökenine inecek ve etkili çözümler üreteceğiz.

🔎 Indexleme Sanatı: SQL Sorgularınızı Nasıl Uçurursunuz?

Veritabanı indeksleme, tıpkı bir kitabın içindekiler dizini gibi çalışır. Büyük bir veri tablosunda belirli bir bilgiyi aradığınızda, tüm sayfaları tek tek çevirmek yerine, içindekiler dizinini kullanarak doğrudan ilgili bölüme gitmek çok daha hızlıdır. Indexler de SQL’de tam olarak bu işlevi görür: veritabanı motorunun, istenen verilere çok daha hızlı ulaşmasını sağlayan özel veri yapılarıdır.

Bir tabloya indeks eklediğinizde, veritabanı bu indeks için bir anahtar ve ilgili verinin fiziksel konumunu içeren bir yapı oluşturur. Genellikle B-Tree (B-Ağacı) adı verilen bu yapılar, verileri sıralı bir şekilde tutar ve arama, sıralama gibi işlemleri logaritmik zamanda gerçekleştirir. Yani, verileriniz ne kadar büyürse büyüsün, indeksler sayesinde performans düşüşü nispeten yavaşlar.

Index Türleri: Ne Zaman Hangisini Kullanmalıyız?

SQL veritabanlarında yaygın olarak kullanılan iki ana indeks türü vardır:

• Clustered Index (Kümelenmiş İndeks): Bir tabloda yalnızca bir tane olabilir ve tablonun fiziksel depolama sırasını belirler. Yani veriler, indeksin anahtar sırasına göre diske yazılır. Bu, genellikle bir tablonun birincil anahtarı (Primary Key) üzerinde otomatik olarak oluşturulur. Kümelenmiş indeksin olduğu bir tabloda veri okuma, özellikle sıralı erişimde çok hızlıdır. Ancak veri ekleme, silme ve güncelleme işlemleri, verilerin fiziksel sırasının korunması gerektiği için biraz daha maliyetli olabilir.
• Non-Clustered Index (Kümelenmemiş İndeks): Bir tabloda birden fazla kümelenmemiş indeks olabilir. Bunlar, fiziksel veri sırasını etkilemez; bunun yerine, indeks anahtarı ve ilgili satırın fiziksel konumunu (bir işaretçi veya kümelenmiş indeks anahtarı) içeren ayrı bir veri yapısı oluştururlar. Sorgularınızda sıkça WHERE (filtreleme), JOIN (birleştirme) veya ORDER BY (sıralama) koşullarında kullandığınız sütunlar için idealdirler.

Index Oluşturma ve Kullanım Senaryoları

Peki, indeksleri ne zaman ve nasıl oluşturmalıyız? İşte basit bir örnek:

  -- Örnek bir tablo oluşturalım
  CREATE TABLE Musteriler (
      MusteriID INT PRIMARY KEY,
      Ad VARCHAR(50) NOT NULL,
      Soyad VARCHAR(50) NOT NULL,
      Email VARCHAR(100) UNIQUE,
      KayitTarihi DATETIME DEFAULT GETDATE()
  );

  -- Tabloya örnek veri ekleyelim (büyük bir tablo simülasyonu için)
  DECLARE @i INT = 1;
  WHILE @i <= 100000
  BEGIN
      INSERT INTO Musteriler (MusteriID, Ad, Soyad, Email)
      VALUES (@i, 'Ad' + CAST(@i AS VARCHAR), 'Soyad' + CAST(@i AS VARCHAR), 'email' + CAST(@i AS VARCHAR) + '@example.com');
      SET @i = @i + 1;
  END;

  -- Index olmadan bir sorgu çalıştıralım (KayitTarihi üzerinde)
  -- Bu sorgu, tüm tabloyu taramak zorunda kalacağı için yavaş olacaktır.
  SELECT * FROM Musteriler WHERE KayitTarihi < '2023-01-01';

  -- 'KayitTarihi' sütununa bir Non-Clustered Index ekleyelim
  CREATE INDEX IX_Musteriler_KayitTarihi ON Musteriler (KayitTarihi);

  -- Index ile aynı sorguyu tekrar çalıştıralım
  -- Şimdi sorgu, indeks sayesinde çok daha hızlı çalışacaktır.
  SELECT * FROM Musteriler WHERE KayitTarihi < '2023-01-01';
  

Gördüğünüz gibi, yalnızca bir indeks ekleyerek sorgu performansında büyük bir fark yaratabiliriz. İndeksler özellikle aşağıdaki durumlarda faydalıdır:

• WHERE koşulunda sıkça kullanılan sütunlar.
• JOIN operasyonlarında kullanılan sütunlar (birleştirme anahtarları).
• ORDER BY veya GROUP BY ile sıralama veya gruplama yapılan sütunlar.
• DISTINCT ile benzersiz değerler aranan sütunlar.

Ancak, her sütuna indeks eklemek performansı her zaman artırmaz. İndeksler disk alanı kaplar ve veri ekleme, silme, güncelleme işlemlerinin maliyetini artırır. Bu nedenle, indeksleri akıllıca kullanmak ve sadece gerçekten ihtiyaç duyulan yerlere eklemek önemlidir.

⚡ Hashing ile Veri Erişimini Radikal Şekilde İyileştirme Yolları

Hashing, bilgisayar bilimlerinde verileri sabit boyutlu bir değere (hash değeri veya hash kodu) dönüştürme işlemidir. Bu dönüşüm, genellikle büyük veri kümelerinde hızlı arama ve karşılaştırma yapmak için kullanılır. Veritabanı bağlamında hashing, özellikle join (birleştirme) işlemlerinin performansını önemli ölçüde etkileyebilir.

Hashing Nasıl Çalışır?

Bir hash fonksiyonu, aldığı veriyi belirli bir algoritmaya göre işler ve benzersiz veya neredeyse benzersiz bir çıktı (hash değeri) üretir. Örneğin, "Ahmet" adını bir hash fonksiyonundan geçirdiğinizde "X1Y2Z3" gibi bir değer elde edebilirsiniz. "Mehmet" için ise tamamen farklı bir değer çıkar. Veritabanı, bu hash değerlerini kullanarak verileri hızlıca bulabilir veya karşılaştırabilir.

Hashing'in veritabanlarında en yaygın uygulama alanlarından biri "Hash Join" algoritmasıdır. Bu algoritma, iki büyük tabloyu birleştirmek için kullanılır ve özellikle birleştirme koşulundaki sütunlarda indeks bulunmadığında veya tablolar çok büyük olduğunda performansı artırabilir. Hash Join, birleştirilecek tablolardan birini (genellikle daha küçük olanı) bellek içi bir hash tablosuna yükler. Daha sonra diğer tabloyu tarayarak her bir satır için aynı hash fonksiyonunu uygular ve hash tablosunda eşleşen değeri arar. Bu yöntem, birleştirme işlemini doğrusal bir arama yerine sabit zamanlı (ortalama) bir arama haline getirerek büyük verilerde çok daha hızlı sonuçlar verir.

Hash Join ve Diğer Join Türleri Karşılaştırması

Veritabanı optimizasyoncusu (optimizer), sorgu planını oluştururken farklı join algoritmaları arasında seçim yapar:

• Nested Loop Join: İç içe döngüler şeklinde çalışır. Birinci tablonun her satırı için ikinci tablo taranır. Küçük tablolarda veya indeksli join sütunlarında etkilidir.
• Merge Join: İki tabloyu birleştirme sütunları üzerinden sıralar ve ardından sıralanmış listeleri birleştirir. Önceden sıralanmış tablolarda veya indekslenmiş sütunlarda iyi performans gösterir.
• Hash Join: Bir tabloyu hash tablosuna dönüştürür ve diğer tabloyu bu hash tablosuyla eşleştirir. Büyük, sıralı olmayan tablolarda, özellikle eşitlik (=) tabanlı birleştirmelerde çok etkilidir.

Veritabanı, mevcut istatistiklere ve sorgu yapısına göre bu join türlerinden hangisinin daha uygun olduğuna karar verir. Bir sütun üzerinde indeks olmasa bile, veritabanı hash join'i kullanarak hızlı birleştirme yapabilir. Ancak bu, bellekte yeterli alanın olması durumunda geçerlidir; aksi takdirde disk I/O maliyetleri artabilir.

  -- Hash Join örneği (Genellikle veritabanı optimizer'ı tarafından otomatik seçilir)
  -- Varsayalım ki 'Siparisler' ve 'Urunler' tablolarımız var.
  -- ve her ikisi de büyük, 'UrunID' sütununda indeks yok veya çok faydalı değil.

  CREATE TABLE Siparisler (
      SiparisID INT PRIMARY KEY,
      MusteriID INT,
      UrunID INT,
      Adet INT,
      SiparisTarihi DATETIME
  );

  CREATE TABLE Urunler (
      UrunID INT PRIMARY KEY,
      UrunAdi VARCHAR(100),
      Fiyat DECIMAL(10, 2)
  );

  -- Örnek veri ekleme (büyük veri simülasyonu)
  -- (Bu bölüm atlanabilir veya daha küçük veri setleri kullanılabilir testler için)
  -- INSERT INTO Siparisler ...
  -- INSERT INTO Urunler ...

  -- UrunID üzerinden bir Hash Join olası bir senaryo
  -- SQL Server'da birleştirme ipuçları kullanılabilir, ancak genellikle optimizasyoncu karar verir.
  -- SELECT S.SiparisID, U.UrunAdi, S.Adet
  -- FROM Siparisler S
  -- INNER JOIN Urunler U ON S.UrunID = U.UrunID;

  -- MySQL/PostgreSQL'de EXPLAIN ANALYZE çıktısı, Hash Join kullanılıp kullanılmadığını gösterir.
  -- Bu sorgunun nasıl çalışacağına dair Optimizer'ın planını görmek için EXPLAIN kullanırız.
  -- Örneğin (gerçek çıktılar DB'ye göre değişir):
  -- EXPLAIN SELECT S.SiparisID, U.UrunAdi, S.Adet FROM Siparisler S INNER JOIN Urunler U ON S.UrunID = U.UrunID;
  

⚙️ SQL Sorgu Optimizasyonu: Performans Katili Hatalardan Nasıl Kaçınırız?

Veritabanı performansı sadece indeksler ve hashing ile sınırlı değildir. Sorguların kendisi de performansı doğrudan etkileyen en önemli faktördür. İyi yazılmış bir sorgu, doğru indekslerle birleştiğinde mucizeler yaratabilir. Ancak kötü yazılmış bir sorgu, en güçlü indeksleri bile işe yaramaz hale getirebilir.

En Sık Yapılan Hatalar ve Çözümleri

1. SELECT * Kullanmaktan Kaçının: Tüm sütunları seçmek yerine, yalnızca ihtiyacınız olan sütunları belirtin. Bu, ağ trafiğini azaltır, veritabanı sunucusunun daha az veri işlemesini sağlar ve indeks kullanımını iyileştirebilir (covering indexes).

   
         -- Kötü Örnek
         SELECT * FROM BuyukTablo WHERE Durum = 'Aktif';
   
         -- İyi Örnek
         SELECT ID, Ad, Soyad, Email FROM BuyukTablo WHERE Durum = 'Aktif';
         

2. WHERE Koşulunda Fonksiyon Kullanımından Sakının: İndeksli bir sütun üzerinde bir fonksiyon kullanmak, veritabanının indeksi kullanmasını engelleyebilir ve tam tablo taramasına yol açabilir (SARGable durum).

   
         -- Kötü Örnek (Indeksi kullanamaz)
         SELECT * FROM Siparisler WHERE YEAR(SiparisTarihi) = 2023;
   
         -- İyi Örnek (Indeksi kullanabilir)
         SELECT * FROM Siparisler WHERE SiparisTarihi >= '2023-01-01' AND SiparisTarihi < '2024-01-01';
         

3. LIKE Operatörünün Doğru Kullanımı: LIKE '%deger' şeklindeki aramalar genellikle indeksi kullanamazken, LIKE 'deger%' şeklindeki aramalar indeksi kullanabilir (buna "prefix matching" denir).

   
         -- Kötü Örnek (Yavaş olabilir)
         SELECT * FROM Urunler WHERE UrunAdi LIKE '%telefon%';
   
         -- İyi Örnek (Indeks varsa daha hızlı olabilir)
         SELECT * FROM Urunler WHERE UrunAdi LIKE 'Akıllı%';
         

4. Subquery (Alt Sorgu) Yerine JOIN Kullanımı: Birçok durumda, alt sorgular yerine JOIN operasyonları kullanmak daha performanslı olabilir. Alt sorgular, her ana sorgu satırı için tekrar çalıştırılabileceği için maliyetli olabilir.

   
         -- Kötü Örnek (Korele alt sorgu)
         SELECT Ad, Soyad FROM Musteriler M
         WHERE EXISTS (SELECT 1 FROM Siparisler S WHERE S.MusteriID = M.MusteriID AND S.SiparisTarihi > '2023-01-01');
   
         -- İyi Örnek (JOIN ile)
         SELECT DISTINCT M.Ad, M.Soyad FROM Musteriler M
         JOIN Siparisler S ON M.MusteriID = S.MusteriID
         WHERE S.SiparisTarihi > '2023-01-01';
         

5. HAVING Yerine WHERE Kullanımı: WHERE koşulu, verileri gruplamadan önce filtreler ve bu genellikle daha verimlidir. HAVING ise verileri grupladıktan sonra filtreleme yapar.

   
         -- Kötü Örnek
         SELECT MusteriID, SUM(ToplamFiyat) FROM Siparisler GROUP BY MusteriID HAVING SUM(ToplamFiyat) > 1000;
   
         -- İyi Örnek (Önce filtreleyip sonra gruplama)
         SELECT MusteriID, SUM(ToplamFiyat) FROM Siparisler WHERE ToplamFiyat > 1000 GROUP BY MusteriID;
         

Sorgu Planı Analizi: EXPLAIN ile Sorgularınızı Gözlemleyin

Bir SQL sorgusunun nasıl çalıştığını anlamanın en güçlü yolu, veritabanının sorgu planını incelemektir. Hemen hemen tüm modern RDBMS'ler (MySQL, PostgreSQL, SQL Server, Oracle), bir sorgunun nasıl yürütüleceğine dair bir plan üretebilir. Bu plana "Execution Plan" (Yürütme Planı) denir ve EXPLAIN (veya EXPLAIN ANALYZE / SET SHOWPLAN_ALL ON) komutuyla görüntülenir.

  -- PostgreSQL'de bir sorgunun planını görüntüleme
  EXPLAIN ANALYZE SELECT M.Ad, S.SiparisID
  FROM Musteriler M
  JOIN Siparisler S ON M.MusteriID = S.MusteriID
  WHERE S.SiparisTarihi >= '2023-01-01' AND S.SiparisTarihi < '2024-01-01'
  ORDER BY M.Ad;
  

Bu komutun çıktısı, hangi tabloların tarandığını, hangi indekslerin kullanıldığını, hangi birleştirme algoritmalarının uygulandığını ve her adımın ne kadar maliyetli olduğunu gösterir. Planı okumayı öğrenmek, performansı düşüren darboğazları tespit etmenin anahtarıdır. Örneğin, "Full Table Scan" (Tam Tablo Taraması) veya "Sort" (Sıralama) gibi maliyetli operasyonlar gördüğünüzde, bu genellikle bir indeks eksikliği veya yanlış yazılmış bir sorgu olduğuna işaret eder.

💡 Gelişmiş Teknikler ve Modern Yaklaşımlar: Büyük Veritabanları İçin Çözümler

Temel indeksleme, hashing ve sorgu optimizasyon tekniklerinin ötesinde, büyük ve yoğun kullanılan veritabanları için daha ileri düzey yaklaşımlar mevcuttur. Bu teknikler, genellikle daha fazla planlama ve altyapı değişikliği gerektirse de, olağanüstü performans artışları sağlayabilir.

Materialized Views (Somutlaştırılmış Görünümler)

Normal görünümler (views), her çağrıldıklarında temel tablolarından verileri dinamik olarak çekerler. Ancak Materialized Views, sorgunun sonucunu önceden hesaplayıp diske kaydeder. Özellikle karmaşık join'ler veya aggregation'lar (toplama fonksiyonları) içeren raporlama sorguları için idealdir. Veriler önceden hazırlandığı için, sorgu anında hesaplama yükü ortadan kalkar ve çok daha hızlı sonuç verir. Dezavantajı, temel tablolar değiştiğinde Materialized View'ın yenilenmesi (refresh) gerekmesidir, bu da bir maliyet getirir.

  -- PostgreSQL örneği: Satış raporları için Materialized View
  CREATE MATERIALIZED VIEW AylikSatisRaporu AS
  SELECT
      TO_CHAR(SiparisTarihi, 'YYYY-MM') AS Ay,
      COUNT(SiparisID) AS ToplamSiparis,
      SUM(Adet * Fiyat) AS ToplamCiro
  FROM Siparisler s
  JOIN Urunler u ON s.UrunID = u.UrunID
  GROUP BY Ay
  ORDER BY Ay;

  -- Materialized View'ı sorgula (çok hızlı)
  SELECT * FROM AylikSatisRaporu WHERE Ay = '2023-10';

  -- Temel veriler değiştiğinde Materialized View'ı güncelle
  REFRESH MATERIALIZED VIEW AylikSatisRaporu;
  

Tablo Bölümleme (Partitioning)

Çok büyük tabloları yönetmek ve optimize etmek zorlaşabilir. Bölümleme, mantıksal olarak tek bir tablo gibi görünen veriyi, fiziksel olarak daha küçük ve yönetilebilir parçalara (partition) ayırma tekniğidir. Bu parçalar farklı disklerde veya dosya gruplarında depolanabilir. Bölümleme, özellikle büyük aralık sorgularında (örneğin belirli bir tarih aralığındaki veriler) performansı artırır çünkü veritabanı sadece ilgili bölümleri tarar, tüm tabloyu değil. Ayrıca, eski verileri arşivlemek veya silmek de kolaylaşır.

Veritabanı Düzeyinde Önbellekleme (Caching)

Birçok veritabanı sistemi, sıkça erişilen verileri veya sorgu sonuçlarını önbellekte (cache) tutar. Bu, aynı verilere veya sorgu sonuçlarına tekrar erişildiğinde disk I/O'sundan kaçınılmasını ve bellekteki daha hızlı erişimi sağlar. Doğru yapılandırılmış bir önbellek, uygulamanızın performansını çarpıcı şekilde artırabilir. Uygulama tarafında da kendi önbellekleme mekanizmalarınızı (Redis, Memcached gibi) kullanarak veritabanı yükünü azaltabilirsiniz.

Bağlantı Havuzu (Connection Pooling)

Her veritabanı bağlantısı oluşturmak, maliyetli ve zaman alıcı bir işlemdir. Özellikle web uygulamaları gibi sıkça bağlantı açıp kapatan sistemlerde bu, bir performans darboğazı oluşturabilir. Bağlantı havuzu, belirli sayıda veritabanı bağlantısını önceden açar ve yeniden kullanılmak üzere hazır tutar. Uygulama yeni bir bağlantıya ihtiyaç duyduğunda, havuzdan mevcut bir bağlantıyı alır ve işi bittiğinde havuza geri verir. Bu, bağlantı oluşturma ve kapatma maliyetini ortadan kaldırır ve performansı önemli ölçüde artırır.

📱 Mobil Uygulamalarda SQL Optimizasyonu: Hızlı ve Akıcı Deneyimler İçin Püf Noktaları

Mobil uygulamaların başarısı, büyük ölçüde hızlı ve sorunsuz bir kullanıcı deneyimine bağlıdır. Mobil cihazlar genellikle sınırlı bant genişliğine, daha yüksek gecikme sürelerine ve daha az işlem gücüne sahip olduğu için, veritabanı performansının önemi burada katlanarak artar. Optimize edilmiş SQL sorguları ve iyi tasarlanmış bir veritabanı mimarisi, mobil uygulamanızın hızını ve duyarlılığını doğrudan etkiler.

Mobil Uygulama Performansına SQL'in Etkisi

Bir mobil uygulama genellikle sunucuda çalışan bir API aracılığıyla veritabanıyla iletişim kurar. SQL sorgularınız ne kadar hızlı çalışırsa, API yanıt süreleri o kadar kısalır. Daha kısa yanıt süreleri ise mobil uygulamadaki yükleme ekranlarını azaltır, veri yenilemelerini hızlandırır ve genel olarak daha akıcı bir kullanıcı deneyimi sunar. Örneğin, bir e-ticaret uygulamasında ürün listeleme veya sipariş geçmişini görüntüleme gibi işlemlerin milisaniyeler içinde gerçekleşmesi, kullanıcı memnuniyetini doğrudan etkiler.

• Azaltılmış Veri Yükü: Mobil cihazlara gönderilen veri miktarını minimumda tutmak çok önemlidir. SELECT * kullanmak yerine, yalnızca mobil uygulamanın ihtiyacı olan sütunları seçin. Gerekirse, karmaşık nesneleri küçük, hafif veri yapılarına dönüştürün.
• Etkin API Tasarımı: Mobil uygulamalar için tasarlanmış API'ler, veritabanı sorgularının sonuçlarını filtreleme, sıralama ve sayfalama yetenekleri sunmalıdır. Bu, mobil cihazın tüm veriyi çekip sonra filtrelemesi yerine, veritabanının sadece gerekli veriyi göndermesini sağlar.
• Önbellekleme Stratejileri: Sıkça erişilen ve nadiren değişen verileri mobil cihazın kendisinde veya API katmanında önbelleğe almak, veritabanı sorgu sayısını ve ağ trafiğini azaltır.

HTML Veri Sunumu ve Duyarlı Tasarımın Önemi

Mobil uygulamalar genellikle kendi UI/UX katmanlarına sahip olsa da, bazen webview içinde HTML içeriği göstermeleri veya veri tabanından gelen listelerin web tabanlı görüntüsü gerekebilir. İşte bu noktada, veritabanından gelen verilerin mobil uyumlu bir şekilde sunulması devreye girer. Optimize edilmiş SQL sorgularından elde edilen veriler, kullanıcıya doğru şekilde ulaştırılmalıdır.

Aşağıdaki gibi basit bir HTML tablosu, mobil cihazlarda kolayca okunabilir ve yönetilebilir hale getirilmelidir. Bu, CSS ile duyarlı tasarım prensipleri (responsive design) kullanılarak yapılır:

  

    

      

        

          
Ürün ID
          
Adı
          
Fiyat
          
Stok
        
      
      

        

          
101
          
Akıllı Saat
          
2500 TL
          
50
        
        

          
102
          
Kablosuz Kulaklık
          
1200 TL
          
120
        
        

          
103
          
Dizüstü Bilgisayar
          
15000 TL
          
30
        
      
    
  
  

Bu HTML yapısı, CSS medya sorguları (media queries) kullanılarak mobil cihazlarda farklı şekillerde görüntülenebilir. Örneğin, küçük ekranlarda tablo sütunları alt alta sıralanabilir, kaydırılabilir hale getirilebilir veya bazı daha az önemli sütunlar gizlenebilir. Bu sayede, SQL'den gelen optimize edilmiş veri, her cihazda en iyi şekilde sunulur.

📈 Vaka Analizi: Gerçek Bir E-ticaret Senaryosu Üzerinden Performans İyileştirmeleri

Bir e-ticaret platformu, kullanıcı sayısının artmasıyla birlikte ciddi performans sorunları yaşamaya başladı. Özellikle ürün arama, kategori filtreleme ve müşteri sipariş geçmişi sayfaları çok yavaş yanıt veriyordu. Müşteri şikayetleri artarken, satışlar da düşüş eğilimindeydi. Geliştirme ekibi, kapsamlı bir veritabanı performans analizi yapmaya karar verdi.

Problem Tespiti

1. Eksik İndeksler: Ürün tablosunda (10 milyon kayıt), UrunAdi ve KategoriID sütunlarında indeks yoktu. Arama ve filtreleme sorguları, tam tablo taramasına neden oluyordu.
2. Ineffective JOINs: Müşteri sipariş geçmişi sorgusu, Musteriler, Siparisler ve SiparisDetay tablolarını birleştirirken, birleştirme koşullarında indekslenmemiş sütunlar kullanıyordu.
3. SELECT * Kullanımı: Tüm sorgularda gereksiz yere SELECT * kullanılıyordu, bu da hem veri işleme hem de ağ trafiği yükünü artırıyordu.
4. Korele Alt Sorgular: Bazı popüler ürünleri listelerken, stok kontrolü için korele alt sorgular kullanılmıştı, bu da her ana sorgu satırı için binlerce alt sorgu çalıştırmaya neden oluyordu.

Uygulanan Çözümler

1. İndeks Eklemeleri:
   • Urunler tablosuna UrunAdi (non-clustered) ve KategoriID (non-clustered) için indeksler eklendi.
   • Siparisler tablosunda MusteriID ve SiparisTarihi sütunları için non-clustered indeksler oluşturuldu.
   • SiparisDetay tablosunda SiparisID ve UrunID için indeksler eklendi.
2. Sorguların Yeniden Yazımı:
   • SELECT * ifadeleri, sadece gerekli sütunları içeren SELECT Kolon1, Kolon2... ifadelerine dönüştürüldü.
   • Korele alt sorgular, INNER JOIN veya LEFT JOIN yapılarına dönüştürülerek çok daha verimli hale getirildi.
   • LIKE '%keyword%' tarzı aramalar, eğer mümkünse LIKE 'keyword%' veya Full-Text Search özellikleriyle değiştirildi.
3. Sorgu Planı Analizi: Her kritik sorgu için EXPLAIN kullanılarak, indekslerin doğru kullanılıp kullanılmadığı ve birleştirme algoritmalarının uygun olup olmadığı kontrol edildi. Gerekirse veritabanı istatistikleri güncellendi.
4. Önbellekleme: Sıkça erişilen statik ürün verileri (kategori listeleri, popüler ürünler) Redis gibi bir önbellek sistemine alındı.

Sonuçlar ve Etki

Bu optimizasyonlar sonucunda, platformda gözle görülür bir performans artışı yaşandı:

• Ürün arama ve filtreleme süreleri %80 oranında azaldı.
• Müşteri sipariş geçmişi sayfaları 10 saniyeden 1 saniyenin altına düştü.
• Veritabanı sunucusunun CPU kullanımı %50 oranında azaldı, bu da daha fazla eşzamanlı kullanıcıya hizmet verilebileceği anlamına geliyordu.
• Kullanıcı memnuniyeti arttı ve platformun genel akışkanlığı iyileşti.

Bu vaka analizi, indeksleme, hashing ve sorgu optimizasyonunun sadece teorik kavramlar olmadığını, aynı zamanda gerçek dünya uygulamalarında somut iş değerleri yaratabileceğini açıkça göstermektedir. Doğru yaklaşımla, veritabanı performans sorunlarının üstesinden gelmek ve daha iyi bir kullanıcı deneyimi sunmak mümkündür.

🎯 Sonuç ve Sıkça Sorulan Sorular: Performans Yolculuğunuz Başlıyor!

SQL veritabanı performansı, bir uygulamanın başarısı için hayati öneme sahiptir. Bu makale boyunca, indeksleme, hashing ve sorgu optimizasyonunun temel prensiplerini ve ileri düzey tekniklerini derinlemesine inceledik. Gördük ki, doğru indeksleri seçmek, hash algoritmalarının nasıl çalıştığını anlamak ve sorguları en iyi pratiklere göre yazmak, yavaş çalışan bir sistem ile ışık hızında bir uygulama arasındaki farkı yaratabilir. Unutmayın, performans optimizasyonu tek seferlik bir işlem değil, sürekli bir izleme, test etme ve iyileştirme döngüsüdür. Veritabanınız büyüdükçe ve kullanım şekilleri değiştikçe, optimizasyon ihtiyaçlarınız da evrilecektir. Düzenli olarak sorgu planlarını kontrol etmek, indeksleri gözden geçirmek ve yeni teknolojilere açık olmak, veritabanlarınızın her zaman zirvede kalmasını sağlayacaktır. Bu yolculukta edindiğiniz bilgilerle, artık veritabanı performansınızı kendi ellerinize alma gücüne sahipsiniz. Uygulamalarınızın hızını artırın, kullanıcılarınızı mutlu edin ve işinize değer katın!

❓ Sıkça Sorulan Sorular (SSS)

1. Her sütuna indeks eklemeli miyim?

   Hayır, kesinlikle eklememelisiniz. Her indeks disk alanı kaplar ve veri ekleme, silme, güncelleme işlemlerinin maliyetini artırır. İndeksler sadece WHERE, JOIN, ORDER BY veya GROUP BY gibi clause'larda sıkça kullanılan ve veritabanı performansını önemli ölçüde etkileyen sütunlara eklenmelidir. Ayrıca, çok az benzersiz değeri olan sütunlara indeks eklemek de genellikle faydasızdır.

2. EXPLAIN komutunun çıktısını nasıl yorumlamalıyım?

   EXPLAIN çıktısı, sorgunun hangi adımlardan geçtiğini (tablo taraması, indeks araması, join türü, sıralama vb.) ve her adımın tahmini maliyetini (satır sayısı, süre) gösterir. Yüksek maliyetli adımlara odaklanın. "Full Table Scan" veya "Sort" gibi ibareler genellikle bir indeks eksikliğine veya yanlış yazılmış bir sorguya işaret eder. "Using Index" veya "Index Scan" görmek genellikle iyi bir işarettir.

3. Hangi durumlarda Hashing, Indexleme'den daha iyi bir seçenek olabilir?

   Hashing (özellikle Hash Join), eşitlik (=) tabanlı birleştirme işlemlerinde, özellikle birleştirilecek tabloların çok büyük olduğu ve birleştirme sütunlarında uygun indekslerin bulunmadığı veya kullanılamadığı durumlarda çok verimli olabilir. İndeksleme ise aralık sorguları, sıralama ve genel veri filtreleme için daha uygundur. Çoğu RDBMS'de, hashing genellikle dahili bir işlem olarak, yani bir join algoritması olarak kullanılırken, indeksleme daha doğrudan sorgu hızlandırma aracıdır.

4. Sorgu optimizasyonu yaparken en çok hangi hatayı gözden kaçırıyorum?

   En sık gözden kaçan hatalardan biri, küçük tablolar üzerindeki performans sorunlarını göz ardı etmektir. Küçük bir tablo zamanla büyüyebilir ve optimize edilmemiş bir sorgu birdenbire büyük bir darboğaza dönüşebilir. Ayrıca, WHERE koşullarında fonksiyon kullanmak veya LIKE '%keyword%' gibi ifadelerle indeksleri devre dışı bırakmak da sıkça yapılan ve kolayca gözden kaçırılan hatalardır.

5. Mobil uygulamalar için veritabanı optimizasyonunda en kritik adım nedir?

   Mobil uygulamalar için en kritik adım, ağ trafiğini ve veri yükünü minimumda tutmaktır. Bu, SELECT * kullanmaktan kaçınarak yalnızca gerekli sütunları çekmek, sunucu tarafında veri filtreleme ve sayfalama yapmak ve sıkça kullanılan verileri API veya istemci tarafında önbelleğe alarak sağlanır. Hızlı API yanıtları, mobil uygulamanızın genel akışkanlığını doğrudan etkiler.