yoklateknik mülakat
GelişimGeçmiş

Veritabanı Query Optimization Mülakat Soruları

75 doğrulanmış Veritabanı Query Optimization mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Query OptimizationZorluk 1
SQL EXPLAIN komutu bir sorgu için öncelikle neyi gösterir?
  • aSorguyu veriye karşı gerçekten çalıştırmadan, döndüreceği satırları
  • bSorgudaki tabloların üzerinde tanımlı tüm index'lerin listesini
  • cOptimizer'ın seçtiği execution plan'ı; scan ve join yöntemleri gibi✓
  • dSorgunun en son çalıştığında geçen tam duvar-saati süresini
Açıklama:EXPLAIN, planner'ın seçtiği execution plan'ı gösterir — hangi scan'ler (sequential vs index), join yöntemleri ve sıra kullanılacak, cost ve satır tahminleriyle birlikte — gerçek satırları döndürmeden (a). Tüm index'leri listelemez (b); yalnızca planın kullandıklarını gösterir. Düz EXPLAIN tahmin yapar, çalıştırmaz; gerçek süre raporlamaz (d) — onun için EXPLAIN ANALYZE gerekir.
Query OptimizationZorluk 1
Bir sorgu execution plan'ında index scan ne anlama gelir?
  • aEngine, eşleşen satırları bulmak için tabloyu baştan sona okumak yerine bir index üzerinde ilerler✓
  • bEngine, tüm tabloyu belleğe yükler ve sonra onu satır satır tek tek arar
  • cEngine, sorguyu yanıtlamadan önce index'i yeniden kurar
  • dEngine, zamandan kazanmak için satırları rastgele fiziksel sırada döndürür
Açıklama:Index scan, eşleşen satırlara atlamak için index yapısını (tipik olarak B-tree) kullanır ve tabloyu baştan sona okumaktan kaçınır. Index'i yeniden kurmak (c) bir bakım işlemidir, sorgu yanıtlamanın parçası değil. Tüm tabloyu yükleyip taramak (b) ise tam tersi yaklaşım olan sequential scan'i tarif eder.
Query OptimizationZorluk 2
Hangi durumda sequential (full table) scan, index scan'e göre çoğu zaman daha iyi bir plandır?
  • aAşırı büyük bir tabloda tek bir satırı primary key ile bulmak
  • bUnique, yüksek seçicilikte bir email kolonundan tek kullanıcı çekmek
  • cFiltre kolonunda özel bir index bulunan büyük bir tablo
  • dKüçük bir tablo ya da satırların büyük kısmını döndüren bir sorgu✓
Açıklama:Index scan, sorgu büyük bir tablonun küçük ve seçici bir dilimine dokunduğunda kazanır. Tablo çok küçükse ya da sorgu satırların çoğunu döndürüyorsa, neredeyse her satır için index ile tablo arasında gidip gelmektense her şeyi sırayla okumak daha ucuzdur. Tek satır primary-key veya seçici email araması (a, b) index scan'in açıkça daha iyi olduğu klasik durumlardır.
Query OptimizationZorluk 1
Performansa duyarlı sorgularda SELECT * neden genelde önerilmez?
  • aSatırları her zaman yanlış sırada döndürür
  • bTüm kolonları çeker; I/O ve ağ maliyeti ekler ve index-only planları engeller✓
  • cİçinde NULL bulunan satırları sessizce eler
  • dİstemci her sonuç satırını okumayı bitirene kadar tüm tabloda exclusive lock tutar
Açıklama:SELECT * yalnızca birkaç kolon gerekse bile tüm kolonları çeker; I/O ve ağ bant genişliğini boşa harcar ve index-only scan'i (index'in tek başına sorguyu karşılaması) engeller. Satır sırasını değiştirmez (a), NULL'lu satırları elemez (c), tabloyu kilitlemez (d).
Query OptimizationZorluk 2
orders.created_at üzerinde B-tree index var ama bu sorgu yine de full scan yapıyor:
SELECT * FROM orders
WHERE EXTRACT(YEAR FROM created_at) = 2024;

Neden ve standart çözüm nedir?
  • aKolonu bir fonksiyona sarmak onu index'ten gizler; created_at üzerinde range olarak yeniden yaz✓
  • bIndex bozulmuş, sorgu kullanabilmeden önce yeniden kurulmalı
  • cEXTRACT bir WHERE clause'unun içinde kullanılamaz, planner tüm index'i sessizce yok sayar
  • dB-tree index'ler date kolonlarını desteklemez; burada hash index gerekir
Açıklama:created_at index'i ham kolon değerlerini saklar, EXTRACT(YEAR FROM created_at)'ı değil. Kolon bir fonksiyonun içine girince engine onu index'le eşleştiremez ve scan'e döner. Sargable bir range olarak yeniden yaz: created_at >= '2024-01-01' AND created_at < '2025-01-01'. Index bozuk değil (b), EXTRACT WHERE'de geçerli (c), B-tree'ler date kolonlarını sorunsuz işler (d).
Query OptimizationZorluk 2
customers.name üzerinde B-tree index var. İki sorgu:
-- Q1
SELECT * FROM customers WHERE name LIKE 'Ali%';
-- Q2
SELECT * FROM customers WHERE name LIKE '%Ali';

Hangisi index'i kullanabilir ve neden?
  • aİkisi de kullanır, çünkü ikisi de index'li kolonda LIKE operatörü kullanıyor
  • bHiçbiri kullanamaz, çünkü LIKE her zaman full table scan'e zorlar
  • cSadece Q1: bilinen bir prefix, engine'in sıralı index içinde seek yapmasını sağlar✓
  • dSadece Q2: bir string'in sonunu eşleştirmek B-tree'lerin optimize olduğu şeydir
Açıklama:B-tree isimleri sıralı tutar; sabit bir prefix ('Ali%') engine'in doğrudan o aralığa seek yapmasını sağlar. Baştaki wildcard ('%Ali') bilinen bir başlangıç noktası bırakmaz; engine her satıra bakmak zorunda kalır — index yardımcı olamaz. LIKE doğası gereği full scan değildir (b); desenin başa sabitlenip sabitlenmediğine bağlıdır.

Uzmanlığa göre

MongoDB 450MySQL 450PostgreSQL 450Redis 450

Kıdeme göre

Veritabanı JuniorVeritabanı MidVeritabanı Senior

Diğer alanlar

BackendFrontendFullstackDevOps / CloudAI EngineerMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2475 soruluk Veritabanı bankasında kendini sına.

Mülakata başla