yoklateknik mülakat
GelişimGeçmiş

Veritabanı Pg Indexes Mülakat Soruları

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

Gerçek simülasyonu dene →

Örnek sorular

Pg IndexesZorluk 1
Sıradan bir B-tree index eşitlik, aralık, BETWEEN ve ORDER BY'ı iyi karşılar. Kolon indeksli olsa bile PostgreSQL'in seq scan'e döndüğü, B-tree'nin karşılamadığı predicate hangisidir?
  • aprice = 100
  • bprice BETWEEN 50 AND 150
  • cprice > 100
  • dtags @> '{"role": "admin"}'::jsonb✓
Açıklama:B-tree, sıralanabilir skaler değerleri tutar; bu yüzden =, <, >, BETWEEN ve aralık karşılaştırmalarını doğrudan destekler. jsonb üzerindeki @> containment operatörü ise iç içe yapıyı anlayan bir index türü ister — GIN — B-tree değil. (a)-(c) tam olarak B-tree'nin yapıldığı karşılaştırmalardır.
Pg IndexesZorluk 2
CREATE TABLE orders (
  id serial PRIMARY KEY,
  customer_id int
);

Bu ifade çalıştıktan hemen sonra — herhangi bir açık CREATE INDEX olmadan — pg_indexes orders için ne gösterir?
  • aHenüz hiçbir şey; çünkü PRIMARY KEY sadece bir constraint'tir ve index oluşturma ilk insert'e ertelenir
  • bid üzerinde, primary key'i desteklemek için otomatik oluşturulmuş orders_pkey adlı tek bir unique B-tree index✓
  • cid üzerinde non-unique bir index; çünkü primary key'in tekliği index değil trigger ile sağlanır
  • dHem id hem customer_id'yi kapsayan tek bir index; çünkü PostgreSQL varsayılan olarak deklare edilen her kolonu indeksler
Açıklama:PRIMARY KEY deklare etmek PostgreSQL'e hemen unique bir B-tree index oluşturtur; varsayılan adı <tablo>_pkey'dir. pg_indexes, CREATE TABLE biter bitmez bunu gösterir. Ne trigger vardır ne de erteleme; customer_id de sen istemedikçe indekslenmez — bu turda canlı bir orders tablosunda doğrulandı.
Pg IndexesZorluk 2
ALTER TABLE users ADD CONSTRAINT users_email_uniq UNIQUE (email);

Bu ifade depolama düzeyinde gerçekte ne yapar?
  • aemail üzerinde users_email_uniq adlı unique bir B-tree index yaratır; constraint'i sağlayan da bu index'tir✓
  • bKuralı sadece katalogda kaydeder; teklik her yazmada index kullanılmadan satır satır kontrol edilir
  • cemail üzerinde önceden bir index bulunmasını şart koşar, yoksa ifade doğrudan reddedilir
  • dNon-unique bir index yaratır ve tekrar eden değerleri reddetmek için ayrı bir check constraint'e dayanır
Açıklama:PostgreSQL'de UNIQUE constraint, arka planda unique bir index yaratılarak uygulanır — burada users_email_uniq adıyla, pg_indexes'te USING btree (email) olarak görünür. Önceden index gerektirmez; tekliği sağlayan trigger veya ayrı bir check constraint değil, doğrudan bu index'tir — bu turda pg_indexes üzerinde doğrulandı.
Pg IndexesZorluk 2
CREATE INDEX idx_orders_cust_date ON orders (customer_id, order_date);

Bir rapor SELECT * FROM orders WHERE order_date > '2024-06-01' çalıştırıyor — yalnızca ikinci kolona filtre koyarak — ve EXPLAIN bir sequential scan gösteriyor. Composite index burada neden işe yaramıyor?
  • aPostgreSQL'de composite index'ler yalnızca ORDER BY'ı hızlandırır, düz bir WHERE filtresini asla hızlandırmaz
  • border_date bir date kolonudur ve composite B-tree index'ler tarihi ilk olmayan bir key olarak saklayamaz
  • cÖnce customer_id'ye göre sıralıdır; bu filtre olmadan doğru order_date aralığına atlayamaz✓
  • dIndex yalnızca tablo belirli bir satır-sayısı eşiğini aştığında etkinleşir, o eşiğe henüz ulaşılmamış
Açıklama:(customer_id, order_date) üzerindeki composite B-tree, satırları önce customer_id'ye, her customer_id içinde de order_date'e göre sıralar. Baştaki kolonu atlarsan eşleşen order_date değerleri index boyunca dağınık kalır; planner bunu verimli kullanamaz ve scan'e döner — klasik 'leftmost prefix' kuralı. Satır-sayısı eşiği (d) yoktur, date tipine bağlı bir kısıtlama (b) da yoktur.
Pg IndexesZorluk 2
Aynı index, idx_orders_cust_date ON orders (customer_id, order_date). Şu sorguda EXPLAIN (ANALYZE, BUFFERS):
SELECT * FROM orders
WHERE customer_id = 42 AND order_date > '2024-06-01';

şunu üretiyor:
Bitmap Heap Scan on orders
  Recheck Cond: (customer_id = 42) AND (order_date > '2024-06-01')
  ->  Bitmap Index Scan on idx_orders_cust_date
        Index Cond: (customer_id = 42) AND (order_date > '2024-06-01')

Bu, index hakkında neyi doğrular?
  • aIndex yalnızca customer_id için kullanılıyor; order_date ise sonradan tüm tablo taranarak filtreleniyor
  • bHer iki predicate de sadece customer_id değil, index scan'in kendisinde uygulanıyor✓
  • cPostgreSQL bu tek sorgu için sessizce ikinci, geçici bir index yarattı
  • dBitmap Heap Scan adımı, index'in aslında kullanılmadığı ve tablonun sequential taranmış olduğu anlamına gelir
Açıklama:Index Cond her iki predicate'i de listeliyor; yani bitmap index scan, eşleşen satırları hem customer_id = 42 hem de order_date aralığıyla birlikte buluyor — baştaki customer_id filtresi ikinci key'in verimli kullanımını açan şeydir. Bitmap Heap Scan, bitmap'in işaret ettiği gerçek satırları getiren adımdır; index yerine geçen değil, index tarafından yönlendirilen bir adımdır; geçici bir index de yaratılmaz.
Pg IndexesZorluk 2
Bir geliştirici şu migration'ı yazıyor:
BEGIN;
CREATE INDEX CONCURRENTLY idx_orders_amount ON orders (amount);
COMMIT;

ve bu hemen bir hatayla başarısız oluyor. Ne oluyor ve neden?
  • aMigration başarılı olur ama sessizce CONCURRENTLY'i yok sayıp normal, blocking bir CREATE INDEX'e döner
  • bamount bir numeric kolonu olduğu için başarısız olur; CONCURRENTLY yalnızca integer ve text kolonları indeksleyebilir
  • cCREATE INDEX CONCURRENTLY cannot run inside a transaction block hatasıyla başarısız olur✓
  • dBaşarısız olur çünkü tüm veritabanında aynı anda yalnızca bir tane CONCURRENTLY ile kurulmuş index olabilir
Açıklama:CREATE INDEX CONCURRENTLY, uzun süreli bir write-blocking kilit almaktan kaçınmak için birbirinden ayrı birkaç iç tarama yapar ve aralarında commit eder; bu, bir BEGIN/COMMIT bloğu içinde çalışmakla uyuşmaz ve PostgreSQL tam olarak bu hata metniyle reddeder. Çözüm, ifadeyi herhangi bir açık transaction dışında, tek başına çalıştırmaktır. Veritabanı-başına böyle bir sınır (d) ya da tip kısıtlaması (b) yoktur; sessizce düşürme de (a) yapmaz — bu turda canlı çalıştırılıp hata metni okunarak doğrulandı.

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