-- 沒有索引：資料庫要掃描整張表，一行一行找
SELECT * FROM users WHERE email = '[email protected]';
-- 如果有 100 萬筆，最差要看 100 萬次

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

-- 有索引後：同樣的查詢，資料庫直接「翻目錄」找到位置
SELECT * FROM users WHERE email = '[email protected]';
-- 不管有幾百萬筆，幾乎瞬間找到
Code language: JavaScript (javascript)

-- 每次 INSERT，資料庫要做兩件事：
-- 1. 寫入資料到 users 表
-- 2. 更新 idx_users_email 索引
INSERT INTO users (name, email) VALUES ('Bob', '[email protected]');

-- 索引越多，寫入越慢
-- 如果你對 5 個欄位都建了索引，每次 INSERT 要更新 5 個索引
Code language: JavaScript (javascript)

建索引的好時機：
- WHERE 子句常用的欄位（如 email、user_id）
- JOIN 的欄位
- ORDER BY 的欄位

不需要索引的情況：
- 很少查詢的欄位
- 經常大量 INSERT 的表（索引拖慢寫入）
- 資料量本身就很小的表（全掃也很快）

                 ┌──── Replica 1 ◄── 讀取請求
                 │     (完整副本)
寫入請求 ──► Primary ──┤
             (主庫)    │
                 └──── Replica 2 ◄── 讀取請求
                       (完整副本)

# 虛擬碼：應用程式怎麼使用 Replication
DATABASE = {
    "primary": "db-primary.example.com:5432",    # 寫入用這個
    "replicas": [
        "db-replica-1.example.com:5432",          # 讀取用這些
        "db-replica-2.example.com:5432",
    ]
}

def create_user(name, email):
    # 寫入 → 送到 Primary
    primary_db.execute("INSERT INTO users ...")

def get_user(user_id):
    # 讀取 → 送到任一 Replica（分散負載）
    replica = random.choice(replicas)
    return replica.execute("SELECT * FROM users WHERE id = ?", user_id)
Code language: PHP (php)

時間點 1：使用者更新大頭照
  → 寫入 Primary ✓

時間點 2：使用者立刻重新整理頁面
  → 讀取 Replica... 還是舊的大頭照！
  → 因為 Primary 的變更還沒同步到 Replica（延遲幾毫秒到幾秒）

時間點 3：幾秒後再重新整理
  → Replica 同步完成，看到新的大頭照 ✓

Replication（複製）：每台都有「全部」資料
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│ Primary     │  │ Replica 1   │  │ Replica 2   │
│ 用戶 1-100萬│  │ 用戶 1-100萬│  │ 用戶 1-100萬│
└─────────────┘  └─────────────┘  └─────────────┘

Sharding（分片）：每台只有「一部分」資料
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│ Shard 1     │  │ Shard 2     │  │ Shard 3     │
│ 用戶 1-33萬 │  │ 用戶 34-66萬│  │ 用戶 67-100萬│
└─────────────┘  └─────────────┘  └─────────────┘

Sharding Key = user_id

查詢 user_id = 42 的資料：
  → 42 % 3 = 0 → 去 Shard 0 找
  → 只查一台伺服器，速度快

查詢 user_id = 100 的資料：
  → 100 % 3 = 1 → 去 Shard 1 找
  → 同樣只查一台

# 虛擬碼：根據 Sharding Key 決定去哪個 Shard
def get_shard(user_id, total_shards=3):
    shard_number = user_id % total_shards
    return shards[shard_number]

# 查詢時
shard = get_shard(user_id=42)
user = shard.execute("SELECT * FROM users WHERE id = 42")
Code language: PHP (php)

-- 原本：一張什麼都放的大表
CREATE TABLE users (
    id INT,
    name VARCHAR(100),       -- 每次登入都要讀
    email VARCHAR(200),      -- 每次登入都要讀
    avatar BLOB,             -- 很大，但不常讀
    bio TEXT,                -- 個人介紹，偶爾讀
    preferences JSON,        -- 設定偏好，很少讀
    created_at TIMESTAMP     -- 每次登入都要讀
);

-- 垂直分割後：按讀取頻率拆成兩張表
CREATE TABLE users_core (        -- 常讀的欄位
    id INT,
    name VARCHAR(100),
    email VARCHAR(200),
    created_at TIMESTAMP
);

CREATE TABLE users_profile (     -- 不常讀的欄位
    user_id INT,
    avatar BLOB,
    bio TEXT,
    preferences JSON
);
Code language: JavaScript (javascript)

查詢「用戶登入資訊」：

拆之前：SELECT * FROM users WHERE id = 42
→ 讀出 name, email, avatar(2MB), bio, preferences, created_at
→ avatar 很大但根本用不到，浪費 I/O

拆之後：SELECT * FROM users_core WHERE id = 42
→ 只讀 name, email, created_at
→ 資料量小，查詢快

原始表：
┌────┬───────┬───────┬──────────┐
│ id │ name  │ email │ avatar   │
├────┼───────┼───────┼──────────┤
│  1 │ Alice │ a@... │ [2MB]    │
│  2 │ Bob   │ b@... │ [1.5MB]  │
│  3 │ Carol │ c@... │ [3MB]    │
└────┴───────┴───────┴──────────┘

Vertical（垂直）：按欄位切
表A: id, name, email     表B: id, avatar
┌────┬───────┬───────┐   ┌────┬──────────┐
│  1 │ Alice │ a@... │   │  1 │ [2MB]    │
│  2 │ Bob   │ b@... │   │  2 │ [1.5MB]  │
│  3 │ Carol │ c@... │   │  3 │ [3MB]    │
└────┴───────┴───────┘   └────┴──────────┘

Horizontal（水平）= Sharding：按列切
Shard A: id 1-2          Shard B: id 3
┌────┬───────┬───────┐   ┌────┬───────┬───────┐
│  1 │ Alice │ a@... │   │  3 │ Carol │ c@... │
│  2 │ Bob   │ b@... │   └────┴───────┴───────┘
└────┴───────┴───────┘
Code language: CSS (css)

讀取速度比較：
  記憶體（RAM）讀取  ≈ 0.1 毫秒
  SSD 磁碟讀取      ≈ 0.1 毫秒（隨機讀取可達數毫秒）
  資料庫查詢（含網路）≈ 1-10 毫秒
  跨機房網路請求     ≈ 50-150 毫秒

快取命中 = 省下資料庫查詢的時間

import redis

cache = redis.Redis(host='localhost', port=6379)

def get_user(user_id):
    # 第一步：先去快取找
    cached = cache.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)     # 快取命中！直接回傳

    # 第二步：快取沒有，去資料庫查
    user = db.query("SELECT * FROM users WHERE id = ?", user_id)

    # 第三步：查到後存進快取，下次就不用再查資料庫
    cache.set(f"user:{user_id}", json.dumps(user), ex=300)  # ex=300 表示 300 秒後過期

    return user
Code language: PHP (php)

要找某筆資料？
  → 先翻快取（記憶體）
    → 有找到（Cache Hit）→ 直接回傳，超快
    → 沒找到（Cache Miss）→ 去資料庫查，查到後順便存進快取

1. Cache-Aside（旁路快取）
   讀：先查快取 → 沒有就查 DB → 存進快取
   寫：直接寫 DB → 刪掉快取（下次讀時會重新載入）
   特點：最常見，應用程式自己管快取

2. Write-Through（穿透寫入）
   讀：先查快取 → 沒有就查 DB → 存進快取
   寫：同時寫 DB 和快取
   特點：快取永遠是最新的，但寫入較慢

3. Write-Behind（背後寫入）
   讀：先查快取
   寫：只寫快取 → 過一段時間再批次寫入 DB
   特點：寫入超快，但如果快取掛了可能丟資料

問題場景：

1. 用戶 A 的資料存在快取中（name = "Alice"）
2. 用戶 A 改了名字（name = "Alicia"）→ 資料庫更新了
3. 但快取裡還是舊的 "Alice"
4. 其他人查用戶 A → 拿到快取裡的舊資料 "Alice" ❌

常見解法：
- TTL（Time To Live）：設過期時間，到期自動清除
- 主動失效：資料更新時，順便刪掉對應的快取
- 版本號：快取 key 帶版本號，更新時版本 +1
Code language: JavaScript (javascript)

-- 正規化設計（教科書寫法）：資料不重複，用 JOIN 取得
-- orders 表
| order_id | user_id | product_id | quantity |
|----------|---------|------------|----------|
| 1        | 42      | 101        | 2        |

-- users 表
| user_id | name  |
|---------|-------|
| 42      | Alice |

-- products 表
| product_id | name    | price |
|------------|---------|-------|
| 101        | T-Shirt | 500   |

-- 查詢訂單詳情要 JOIN 三張表
SELECT o.order_id, u.name, p.name, p.price, o.quantity
FROM orders o
JOIN users u ON o.user_id = u.user_id
JOIN products p ON o.product_id = p.product_id;

-- 反正規化設計：資料有重複，但不需要 JOIN
-- orders_denormalized 表
| order_id | user_id | user_name | product_id | product_name | price | quantity |
|----------|---------|-----------|------------|--------------|-------|----------|
| 1        | 42      | Alice     | 101        | T-Shirt      | 500   | 2        |

-- 查詢訂單詳情，一張表搞定
SELECT order_id, user_name, product_name, price, quantity
FROM orders_denormalized
WHERE order_id = 1;

適合反正規化的場景：
- 電商的訂單紀錄（建立後幾乎不改，但常常被查詢）
- 社群媒體的貼文（讀取量遠大於寫入量）
- 報表系統（只讀，不寫）

不適合的場景：
- 經常變動的資料（如用戶即時狀態）
- 需要嚴格一致性的系統（如銀行帳戶）

一個典型的高流量系統可能同時用到：

                    ┌─────────────┐
  用戶請求 ──────►  │   快取層     │  ← Concept 19: Caching
                    │  (Redis)    │     先查快取，命中就回
                    └──────┬──────┘
                           │ Cache Miss
                    ┌──────▼──────┐
                    │   讀取副本   │  ← Concept 16: Replication
                    │  (Replica)  │     讀取走副本，分散壓力
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
       ┌──────▼──┐  ┌──────▼──┐  ┌──────▼──┐
       │ Shard 1 │  │ Shard 2 │  │ Shard 3 │  ← Concept 17: Sharding
       │用戶1-33萬│  │用戶34-66萬│ │用戶67-100萬│  資料分散到多個分片
       └────┬────┘  └────┬────┘  └────┬────┘
            │            │            │
         索引加速       索引加速      索引加速     ← Concept 15: Indexing
                                                    每個分片內用索引加速

1. 先加索引（Indexing）           ← 成本最低，效果最明顯
2. 加快取（Caching）              ← 減少資料庫壓力
3. 讀寫分離（Replication）         ← 分散讀取壓力
4. 垂直分割 / 反正規化            ← 優化資料結構
5. 最後才考慮分片（Sharding）      ← 成本最高，複雜度最大