索引
一個**索引（index）**就像一本書後面的索引：它讓資料庫直接跳到匹配的行，而不必掃描每一行。沒有索引，查詢會隨著資料增長而變慢——在 100 行時還好，在 1,000,000 行時就痛苦了。
沒有索引，資料庫會逐行依次檢查；有了索引，它就直接跳到匹配項——就像書的索引把你送到正確的頁碼，而不必從頭讀到尾：
NO INDEX (Seq Scan) WITH INDEX (Index Scan)
逐行讀取每一 row 直接跳到匹配項
┌─────────────────────┐ ┌─────────────┐
│ row 1 ✗ │ │ INDEX │
│ row 2 ✗ │ │ author_id │
│ row 3 ✓ 匹配 │ ◀──────┐ │ ──┬── │
│ row 4 ✗ │ │ └─────┼───────┘
│ ... (1,000,000) │ │ ▼
│ row N ✓ 匹配 │ └──▶ rows 3, 998 ✓
└─────────────────────┘ 只需幾跳，而非百萬次
實用的指導：
- 為你頻繁篩選或連線的列建立索引（例如
author_id、email）。 - 主鍵會自動建立索引。
- 不要給所有東西都建索引——每個索引都會加速讀取，但會拖慢寫入並佔用空間。
- 當你看到一個慢查詢時再新增索引，而不是預先給每一列都加。
弄清楚某個索引到底有沒有用的誠實辦法，是去問資料庫，而不是去猜。每個 引擎都有 EXPLAIN（在 Postgres 裡是 EXPLAIN ANALYZE），它會展示它將採用的計劃：
EXPLAIN ANALYZE
SELECT * FROM posts WHERE author_id = '...';
如果在一張大表上輸出說 Seq Scan，那就是資料庫在讀取每一行——一個索引會有幫助的訊號。加上一個之後，它應該切換為 Index Scan。這是一個很適合交給 AI 的任務：把慢查詢和 EXPLAIN 的輸出貼上去，問該加哪個索引以及為什麼。你通過理解答案來保持掌控，而不是靠背索引理論。