PostgreSQL Sorgu Optimizasyonu: Yavaştan Milisaniye Altına | Akousa

                                    QUERY PLAN
---------------------------------------------------------------------------
 Index Scan using idx_orders_customer_id on orders  (cost=0.43..8.45 rows=1 width=128)
   Index Cond: (customer_id = 42)

                                    QUERY PLAN
---------------------------------------------------------------------------
 Index Scan using idx_orders_customer_id on orders  (cost=0.43..8.45 rows=1 width=128)
                                                    (actual time=0.021..0.023 rows=1 loops=1)
   Index Cond: (customer_id = 42)
 Planning Time: 0.085 ms
 Execution Time: 0.041 ms

                                    QUERY PLAN
---------------------------------------------------------------------------
 Hash Join  (cost=425.00..1893.25 rows=2150 width=48)
            (actual time=2.341..15.892 rows=2347 loops=1)
   Hash Cond: (o.customer_id = c.id)
   Buffers: shared hit=312 read=45
   ->  Bitmap Heap Scan on orders o  (cost=12.50..1450.75 rows=2150 width=32)
                                     (actual time=0.512..12.105 rows=2347 loops=1)
         Recheck Cond: (created_at > '2026-01-01'::date)
         Filter: (status = 'completed')
         Rows Removed by Filter: 893
         Heap Blocks: exact=189
         Buffers: shared hit=195 read=45
         ->  Bitmap Index Scan on idx_orders_created_at  (cost=0.00..11.96 rows=3043 width=0)
                                                         (actual time=0.287..0.287 rows=3240 loops=1)
               Index Cond: (created_at > '2026-01-01'::date)
               Buffers: shared hit=12
   ->  Hash  (cost=287.50..287.50 rows=10000 width=24)
             (actual time=1.753..1.753 rows=10000 loops=1)
         Buffers: shared hit=117
         ->  Seq Scan on customers c  (cost=0.00..287.50 rows=10000 width=24)
                                      (actual time=0.008..0.892 rows=10000 loops=1)
               Buffers: shared hit=117
 Planning Time: 0.215 ms
 Execution Time: 16.147 ms

Bitmap Heap Scan on orders  (cost=45.00..1250.00 rows=5000 width=128)
  Recheck Cond: (created_at > '2026-01-01')
  ->  Bitmap Index Scan on idx_orders_created_at  (cost=0.00..43.75 rows=5000 width=0)
        Index Cond: (created_at > '2026-01-01')

Bitmap Heap Scan on orders
  Recheck Cond: ((status = 'completed') AND (created_at > '2026-01-01'))
  ->  BitmapAnd
        ->  Bitmap Index Scan on idx_orders_status
              Index Cond: (status = 'completed')
        ->  Bitmap Index Scan on idx_orders_created_at
              Index Cond: (created_at > '2026-01-01')

sql

-- Sorgu: WHERE status = 'active' AND created_at > '2026-01-01' ORDER BY total DESC
 
-- İyi: eşitlik önce, sonra aralık, sonra sıralama
CREATE INDEX idx_orders_optimized ON orders (status, created_at, total);
 
-- Kötü: aralık eşitlikten önce
CREATE INDEX idx_orders_bad ON orders (created_at, status, total);

sql

-- Başka bir yaygın kalıp: soft delete'ler
CREATE INDEX idx_users_active_email ON users (email)
WHERE deleted_at IS NULL;
 
-- Sadece aktif kayıtlarda benzersiz kısıtlama
CREATE UNIQUE INDEX idx_users_unique_email ON users (email)
WHERE deleted_at IS NULL;

sql

-- JSONB kapsama sorguları
CREATE INDEX idx_products_metadata ON products USING GIN (metadata);
 
-- Şimdi bu hızlı:
SELECT * FROM products WHERE metadata @> '{"color": "red"}';
 
-- Tam metin arama
CREATE INDEX idx_articles_search ON articles USING GIN (to_tsvector('english', title || ' ' || body));

sql

-- IP aralık aramaları
CREATE INDEX idx_ip_ranges ON ip_blocks USING GiST (ip_range);
 
SELECT * FROM ip_blocks WHERE ip_range @> '192.168.1.50'::inet;
 
-- Zamansal aralıklar (zamanlama çakışmaları)
CREATE INDEX idx_bookings_period ON bookings USING GiST (
  tstzrange(start_time, end_time)
);
 
-- Örtüşen rezervasyonları bul:
SELECT * FROM bookings
WHERE tstzrange(start_time, end_time) && tstzrange('2026-03-01 10:00', '2026-03-01 12:00');

sql

-- Büyük metin sütunlarında sadece eşitlik aramaları için iyi
CREATE INDEX idx_sessions_token ON sessions USING HASH (session_token);
 
-- Bu hızlı:
SELECT * FROM sessions WHERE session_token = 'abc123def456...';
 
-- Bu hash index'i KULLANAMAZ:
SELECT * FROM sessions WHERE session_token LIKE 'abc%';

sql

-- Kullanılmayan index'leri bul
SELECT
  schemaname, tablename, indexname,
  idx_scan,
  pg_size_pretty(pg_relation_size(indexrelid)) AS index_size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
  AND indexrelid NOT IN (
    SELECT conindid FROM pg_constraint
    WHERE contype IN ('p', 'u')  -- birincil anahtar ve benzersiz kısıtlamaları hariç tut
  )
ORDER BY pg_relation_size(indexrelid) DESC;

sql

-- Tekrarlanan index'leri bul (aynı sütunlar, aynı sıra)
SELECT
  a.indexrelid::regclass AS index1,
  b.indexrelid::regclass AS index2,
  a.indrelid::regclass AS table_name
FROM pg_index a
JOIN pg_index b ON a.indrelid = b.indrelid
  AND a.indexrelid < b.indexrelid
  AND a.indkey = b.indkey;

python

# Python / SQLAlchemy — klasik tuzak
orders = session.query(Order).filter_by(status='pending').all()
 
for order in orders:
    # Bu, HER sipariş için ayrı bir sorgu tetikler
    print(f"Customer: {order.customer.name}")

sql

-- Sorgu 1: Tüm bekleyen siparişleri al
SELECT * FROM orders WHERE status = 'pending';
 
-- Sorgu 2: Sipariş 1 için müşteriyi al
SELECT * FROM customers WHERE id = 101;
 
-- Sorgu 3: Sipariş 2 için müşteriyi al
SELECT * FROM customers WHERE id = 102;
 
-- ...Sorgu 502: Sipariş 500 için müşteriyi al
SELECT * FROM customers WHERE id = 600;

python

# SQLAlchemy — joinedload aynı sorguda müşterileri getirir
from sqlalchemy.orm import joinedload
 
orders = (
    session.query(Order)
    .options(joinedload(Order.customer))
    .filter_by(status='pending')
    .all()
)

sql

-- EXISTS — ilk eşleşmede durur, varlık kontrolü için harika
SELECT * FROM orders o
WHERE EXISTS (
  SELECT 1 FROM returns r WHERE r.order_id = o.id
);
 
-- IN alt sorgu ile — önce tam sonuç setini oluşturur
SELECT * FROM orders
WHERE id IN (SELECT order_id FROM returns);
 
-- JOIN — returns'te sipariş başına birden fazla satır varsa tekrarlar üretebilir
SELECT DISTINCT o.* FROM orders o
JOIN returns r ON r.order_id = o.id;

sql

-- Sayfa 1: hızlı
SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 0;
 
-- Sayfa 500: yavaş — PostgreSQL 9.980 satırı tarayıp atmalı
SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 9980;

sql

-- Yavaş: ilişkili alt sorgu satır başına bir kez çalışır
SELECT
  o.*,
  (SELECT COUNT(*) FROM order_items i WHERE i.order_id = o.id) AS item_count
FROM orders o
WHERE o.status = 'completed';
 
-- Hızlı: DISTINCT ON (PostgreSQL'e özgü, son derece kullanışlı)
SELECT DISTINCT ON (user_id) *
FROM notifications
ORDER BY user_id, created_at DESC;

PostgreSQL Sorgu Optimizasyonu: Yavaştan Milisaniye Altına

Hata Ayıklama Zihniyeti: Tahmin Etme, Ölç

EXPLAIN — Plan

EXPLAIN ANALYZE — Gerçek

EXPLAIN (ANALYZE, BUFFERS) — Tam Resim

Gerçekten Kullandığım EXPLAIN Seçenekleri

Sorgu Planlarını Bir Dedektif Gibi Okumak

Seq Scan — Tam Tablo Taraması

Index Scan — Hedefli Arama

Index Only Scan — Kutsal Kase

Bitmap Scan — Orta Yol

Kötü Tahminleri Tespit Etme

Index Stratejisi: Doğru İş İçin Doğru Index

B-tree — Varsayılan İş Atı

INCLUDE ile Kapsayan Index'ler

Kısmi Index'ler — Sadece Önemli Olanı Indexle

GIN Index'leri — Tam Metin Arama ve JSONB

GiST Index'leri — Geometrik ve Aralık Tipleri

Hash Index'leri — Niş Ama Kullanışlı

Index'ler Ne Zaman Zarar Verir

N+1 Sorgu Problemi

N+1 Neye Benzer

Çözüm: Eager Loading veya JOIN'ler

Yaygın Sorgu Yeniden Yazımları

EXISTS vs IN vs JOIN

OFFSET ile Sayfalama Yerine Keyset Sayfalama

Window Fonksiyonları vs Alt Sorgular

Pratik Kontrol Listesi

Son Düşünceler

İlgili Yazılar

How to Compress Images Without Losing Quality: The Complete 2026 Guide

2026'da Modern Kimlik Doğrulama: JWT, Session, OAuth ve Passkey