索引（Index）：為什麼你的查詢這麼慢？
B-Tree 原理、複合索引與 EXPLAIN 實戰

-- 建立單欄索引
CREATE INDEX idx_users_email ON users(email);

-- 建立唯一索引（同時確保值不重複）
CREATE UNIQUE INDEX idx_users_email_unique ON users(email);

-- 建立複合索引（欄位順序很重要！）
CREATE INDEX idx_orders_user_status ON orders(user_id, status);

-- 建立部分索引（只對符合條件的列建索引，節省空間）
CREATE INDEX idx_orders_pending ON orders(created_at)
WHERE status = 'pending';   -- 只對待處理訂單建索引

-- 查看某張表的所有索引
SELECT indexname, indexdef FROM pg_indexes
WHERE tablename = 'orders';

-- 刪除索引
DROP INDEX idx_users_email;

-- 重建索引（修復索引膨脹，在離峰時間執行）
REINDEX INDEX idx_users_email;

-- 場景：電商訂單查詢，最常見的查詢模式是：
-- 1. 查某個使用者的特定狀態訂單（最常見）
-- 2. 查某個使用者的所有訂單
-- 3. 查特定狀態的所有訂單（較少）

-- ❌ 錯誤設計（status 在前）
CREATE INDEX idx_bad ON orders(status, user_id);
-- WHERE user_id = 1 → 無法使用此索引！

-- ✅ 正確設計（高選擇性欄位在前）
CREATE INDEX idx_orders_user_status ON orders(user_id, status);
-- WHERE user_id = 1            → 使用 user_id 部分
-- WHERE user_id = 1 AND status = 'pending' → 使用完整索引

-- 設計原則：
-- 1. 等值查詢的欄位放前面（= 而非 BETWEEN / LIKE）
-- 2. 高選擇性的欄位放前面（user_id 比 status 更有辨別力）
-- 3. ORDER BY 的欄位放最後（可利用索引排序，避免額外 Sort 步驟）

-- EXPLAIN：只看執行計畫（不實際執行）
EXPLAIN SELECT * FROM orders WHERE user_id = 1;

-- EXPLAIN ANALYZE：實際執行並回報真實時間（推薦）
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 1 AND status = 'pending';

-- 典型輸出（有索引）：
-- Index Scan using idx_orders_user_status on orders
--   (cost=0.43..8.45 rows=3 width=72) (actual time=0.05..0.07 rows=2 loops=1)
--   Index Cond: ((user_id = 1) AND (status = 'pending'))

-- 典型輸出（無索引，全表掃描）：
-- Seq Scan on orders
--   (cost=0.00..21458.00 rows=1000000 width=72) (actual time=0.05..312.4 rows=2 loops=1)
--   Filter: ((user_id = 1) AND (status = 'pending'))
--   Rows Removed by Filter: 999998