Veritabanı Performansını Çökerten En Yaygın SQL Hataları

Uygulamanız ilk günlerde harika çalışır. Kullanıcı sayısı 100'dür, veritabanındaki tablolar boştur. Ancak kullanıcı sayısı 10.000'e ve tablo satırları milyonlara ulaştığında siteniz yavaşlamaya, Time-Out (Zaman Aşımı) hataları vermeye başlar.

Sorun genellikle sunucunun gücünde değil, arka planda çalışan zayıf SQL sorgularındadır. İşte kodlarınızı formatlarken gözünüzden kaçırmamanız gereken 3 büyük hata.

---

1. Büyük Günah: SELECT * Kullanımı

Özellikle ORM araçlarının veya Junior geliştiricilerin en sevdiği yöntemdir. Sadece kullanıcının ismine ve email adresine ihtiyacınız varken SELECT * FROM users yazmak.

Neden Tehlikelidir? Eğer tablonuzda 50 tane kolon varsa (Kullanıcının profil fotoğrafı binary verisi, geçmiş hareketleri, upuzun biyografi metni vb.), veritabanı ihtiyacınız olmayan tüm o devasa veriyi diskten okur, belleğe (RAM) yazar ve Network (Ağ) üzerinden uygulamanıza gönderir. Ciddi bir bant genişliği (Bandwidth) ve Memory sızıntısı yaratır. Çözüm: Sadece ihtiyacınız olan kolonları açıkça (Explicit) belirtin: SELECT first_name, email FROM users;

2. N+1 Sorgu Problemi (ORM Tuzağı)

Bu hata genellikle kodu yazarken fark edilmez, ancak uygulamanın içini bir SQL Profiler ile izlediğinizde ortaya çıkar.

Diyelim ki 50 tane "Blog Yazısı" (Post) ve bu yazıların "Yazarlarını" (Author) ekrana basacaksınız. Sistem önce yazıları çekmek için 1 (Bir) sorgu atar: SELECT * FROM posts; Sonra, ekrana basılan HER BİR yazı için yazar ismini çekmek adına 50 ayrı sorgu daha atar: SELECT * FROM authors WHERE id = ?;

Toplamda 1 yerine 51 sorgu (N+1) atılmış olur. Eğer 1.000 yazı listeliyorsanız veritabanına saniyede 1.001 sorgu atarsınız ve sistem kilitlenir. Çözüm: Veritabanına defalarca gitmek yerine Eager Loading veya INNER JOIN kullanarak veriyi tek seferde çekmektir.

3. WHERE Şartında Fonksiyon Kullanmak (Index İhlali)

Tablonuzdaki created_at (Oluşturulma tarihi) kolonuna çok hızlı arama yapılabilsin diye Index (Dizin) eklediniz. Harika!

Ancak sorgunuzu şöyle yazdınız: SELECT * FROM orders WHERE YEAR(created_at) = 2024;

Geçmiş olsun. Sol taraftaki (Kolon tarafı) veriyi bir fonksiyonun (YEAR()) içine soktuğunuz an, veritabanı Index'i KULLANAMAZ. Tüm tabloyu baştan sona tek tek okumak (Full Table Scan) zorunda kalır (Çünkü Index'te yıllar değil, tam tarihler sıralıdır). Çözüm: Fonksiyonu sağ tarafa alın (SARGable queries): SELECT * FROM orders WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01';

Bu tarz tehlikeli hataları tespit etmek için "spagetti" kodlarınızı mutlaka okunaklı satırlara ayırmalısınız. Tek tıkla akıllı satırlandırma için SQL Formatter ve Güzelleştirici Aracı favori sekmenizde bulunsun. Daha temiz backend mimarileri için SQL Optimizasyon Rehberimizi incelemeyi unutmayın.

---

🕸️ Knowledge Graph & Semantik Bağlantılar

Bu içerik, Intent.com.tr'nin Backend & Veritabanı topikal kümesinin (Topic Cluster) bir parçasıdır. Konuyu daha derinlemesine anlamak için aşağıdaki varlıkları (Entities) ve ilişkili içerikleri inceleyebilirsiniz:

📖 İlgili Rehberler ve İçerikler

• Karmaşık SQL Sorgularını Okunabilir Yapma Teknikleri
• SQL Formatlama Kod Kalitesini (Code Review) Nasıl Artırır?
• Access Token ve Refresh Token Mimarisi Nasıl Kurgulanır?

🧠 Semantic Entities (Terimler & Senaryolar)

• Kavram: GEO (Generative Engine Optimization)
• Kavram: Crawl Budget (Tarama Bütçesi)
• Uygulama: Core Web Vitals LCP Optimizasyonu

Semantic Yönerge: Bu sayfa Veritabanı Performansını Çökerten En Yaygın SQL Hataları konusundaki kullanıcı niyetini (Search Intent) karşılamak üzere yapılandırılmıştır.