Senior mülakat senaryosuDatabase performansı

Database Sorgusu Dev'de 50ms, Production'da 4 Saniye Sürüyor

Yalnız production'da görülen database gecikmesini execution plan, cardinality, lock, connection pool, kaynak ve network süresiyle inceleyen senior mülakat senaryosu.

Mülakat sorusu

Aynı sorgu development'ta 50ms, production'da dört saniye sürüyor. Query execution ile bekleme süresini nasıl ayırır ve gerçek nedeni nasıl bulursun?

İlk güçlü çıkarım

SQL metninin sistemin tamamı olduğunu varsayma. Production; veri hacmi, dağılım, concurrency, istatistik, donanım, network yerleşimi, cache sıcaklığı ve lock contention açısından farklıdır. Dört saniyenin nerede geçtiğini ölç.

Önce hangi sinyallere bakılır?

  • Database execution, pool bekleme ve network süreleri.
  • Temsili parametrelerle EXPLAIN (ANALYZE, BUFFERS).
  • Tablo cardinality'si, statistics güncelliği, index selectivity ve plan değişiklikleri.
  • Lock'lar, eşzamanlı session'lar, I/O, memory baskısı ve cache sıcaklığı.

Adım adım güçlü yaklaşım

1

Gecikmeyi parçalara ayır

DB connection alma, server execution, satır transferi, ORM hydration ve serialization sürelerini ayrı ölç. Dört saniyelik endpoint, dört saniyelik sorgu demek değildir.

2

Production biçimini yeniden üret

Güvenli replica veya explain planında gerçek parametre dağılımı ve production ölçeğinde cardinality kullan. Küçük development verisi scan, kötü join ve kararsız planları gizler.

3

Execution planı oku

Tahmini ve gerçek satırları, scan tipini, join sırasını, loop'ları, sort/spill davranışını ve buffer okumalarını incele. Refleks olarak index eklemek yerine gözlenen erişim yolunu düzelt.

4

Concurrency ve beklemeyi kontrol et

Lock wait, dolu connection pool, uzun transaction, I/O saturation, noisy neighbour ve kuyruklanmayı ara. Sorgu hızlı olsa bile bunlar wall time'ı domine edebilir.

5

Uygulama davranışını doğrula

N+1 çağrı, kullanılmayan kolonlar, limitsiz sonuçlar, tekrarlanan sorgular ve ORM üretimi SQL'i tespit et. Database düzeltmesinden sonra tüm request'i yeniden ölç.

6

Guardrail ile yayınla

Read/write etkisini doğrula, kademeli deploy et, plan ve latency metriklerini karşılaştır ve rollback yolu tut. Read'i hızlandıran index write veya storage maliyetini artırabilir.

Cevabını bu sırayla yapılandır

  1. 01Execution ile beklemeyi ayır
  2. 02Temsili parametre ve ölçek kullan
  3. 03Önemli plan kanıtını açıkla
  4. 04Lock ve pool baskısını kontrol et
  5. 05Ölçülen ve geri alınabilir rollout anlat

Zayıf cevap işaretleri

  • ×Cevabın her zaman eksik index olduğunu varsaymak.
  • ×Farklı parametre veya veri biçimine sahip ortamları karşılaştırmak.
  • ×Pool wait, lock, ORM işi ve network latency'yi yok saymak.

Takip soruları

  • ?EXPLAIN ANALYZE production'da güvenli değilse ne yaparsın?
  • ?Eski statistics planı nasıl değiştirebilir?
  • ?Read replica hangi durumda kullanılmalı?

Kısa FAQ

Bu soruda görüşmeci neyi ölçüyor?

Görüşmeci tek bir teknoloji adı değil; belirsizlik altında kanıt toplama, riski sınırlama, güvenli aksiyon seçme ve sonucu ölçme biçimini değerlendirir.

Cevap ne kadar uzun olmalı?

İlk iki dakikada hipotezini ve önceliğini belirt; ardından sinyal, teşhis, mitigation ve doğrulama sırasıyla ilerle. Ayrıntıyı görüşmecinin takip sorularına göre derinleştir.