說實話，我第一次在專案裡用 PostgreSQL 的 JSONB 時，覺得這東西簡直是神器——不用改 schema 就能塞各種結構的資料進去。但後來查詢越來越慢，我才意識到自己踩了一堆坑。今天這篇文章，就是我花了不少時間摸索出來的 PostgreSQL JSONB 查詢效能優化教學，希望能幫你少走彎路。

JSONB 與 JSON 的差異：別再選錯了

PostgreSQL 提供了 JSON 和 JSONB 兩種型別，很多人搞不清楚差異。簡單講：

JSON：存的是原始文字，保留空白和鍵的順序，每次查詢都要重新解析。
JSONB：存的是二進位格式，寫入時解析一次，查詢時直接讀取，速度快很多。

結論很明確：除非你有保留原始格式的特殊需求，否則一律用 JSONB。JSONB 支援索引，JSON 不行，這在效能上是天差地別的事。

JSONB 關鍵運算子速查

要有效操作 JSONB，你得先搞懂這幾個運算子，它們是日常查詢的基礎：

-- @> 包含運算子：檢查左邊是否包含右邊的 JSON
SELECT * FROM products
WHERE metadata @> '{"category": "electronics"}';

-- ? 存在運算子：檢查是否存在某個 key
SELECT * FROM products
WHERE metadata ? 'discount';

-- ->> 取出文字值
SELECT metadata->>'name' AS product_name
FROM products
WHERE metadata->>'status' = 'active';

-- #> 路徑取值（回傳 JSONB）
SELECT metadata #> '{specs, cpu}' AS cpu_info
FROM products;

這裡有個重點：@> 和 ? 可以走 GIN 索引，但 ->> 做等值比較時走不了 GIN 索引。這是很多人效能掉下去的原因，後面會詳細說明。

GIN 索引策略：jsonb_ops vs jsonb_path_ops

GIN 索引是 JSONB 效能優化的核心武器。PostgreSQL 提供了兩種 operator class，選錯會直接影響效能和空間：

-- 預設的 jsonb_ops：支援 @>, ?, ?|, ?& 等全部運算子
CREATE INDEX idx_metadata_ops ON products
USING GIN (metadata jsonb_ops);

-- jsonb_path_ops：只支援 @> 包含查詢，但索引更小、更快
CREATE INDEX idx_metadata_path ON products
USING GIN (metadata jsonb_path_ops);

我的經驗法則是這樣的：

如果你的查詢主要是 @> 包含查詢，用 jsonb_path_ops，索引大小大約只有 jsonb_ops 的 1/3，查詢也更快。
如果你還需要用 ? 去檢查 key 是否存在，那就得用預設的 jsonb_ops。

另外一個實用技巧：如果你經常用 ->> 做篩選，可以建立表達式索引：

-- 針對特定欄位建 B-Tree 索引
CREATE INDEX idx_status ON products
((metadata->>'status'));

這樣 WHERE metadata->>'status' = 'active' 就能走索引了。想更深入了解各類索引的特性，推薦看看 PostgreSQL 索引優化教學：B-Tree、GIN、GiST 完整指南。

TOAST 機制對 JSONB 的影響

這個坑比較隱蔽。PostgreSQL 的 TOAST（The Oversized-Attribute Storage Technique）機制會自動把超過約 2KB 的欄位壓縮或移到外部儲存。JSONB 欄位如果塞了很大的 JSON 物件，就會被 TOAST 處理。

問題在哪？被 TOAST 的資料在讀取時需要額外的 I/O 操作，即使你只想取其中一個小欄位，PostgreSQL 也得先把整個 JSONB 解壓出來。所以：

不要把所有東西都塞進同一個 JSONB 欄位。常查詢的欄位應該拉出來當獨立的 column。
JSONB 欄位盡量控制在合理大小，太肥的文件會嚴重拖慢查詢。

五個常見 JSONB 踩坑反模式

這些是我自己踩過或在 code review 中看到別人踩的坑：

把 JSONB 當成萬能欄位：什麼都往裡面塞，連明明可以正規化的資料也用 JSONB。這會讓查詢變慢，也失去資料庫的型別檢查。
用 ->> 篩選卻沒建表達式索引：這是最常見的效能殺手。->> 不吃 GIN 索引，沒建 B-Tree 表達式索引就是全表掃描。
在 JSONB 上做 LIKE 模糊查詢：例如 WHERE metadata->>'name' LIKE '%keyword%'，這完全走不了索引，資料量大時直接爆炸。
忽略 EXPLAIN ANALYZE：很多人寫完查詢就直接部署，從來不看執行計畫。養成習慣，每條涉及 JSONB 的查詢都先跑一次 EXPLAIN ANALYZE。
沒有用 @> 改寫查詢：能用 @> 寫的查詢就別用 ->> + 等號，前者可以走 GIN 索引。

-- 反模式：走不了 GIN 索引
SELECT * FROM products
WHERE metadata->>'category' = 'electronics';

-- 正確寫法：可以走 GIN 索引
SELECT * FROM products
WHERE metadata @> '{"category": "electronics"}';

實戰優化：從慢查詢到毫秒級回應

假設你有一個訂單系統，每筆訂單的詳細資料存在 JSONB 欄位 order_data 裡，你需要查詢特定付款方式的訂單：

-- Step 1: 建立適當的 GIN 索引
CREATE INDEX idx_orders_data ON orders
USING GIN (order_data jsonb_path_ops);

-- Step 2: 用 @> 運算子查詢
SELECT order_id, order_data->>'total' AS total
FROM orders
WHERE order_data @> '{"payment_method": "credit_card"}'
AND created_at > NOW() - INTERVAL '30 days';

-- Step 3: 確認執行計畫
EXPLAIN ANALYZE
SELECT order_id, order_data->>'total' AS total
FROM orders
WHERE order_data @> '{"payment_method": "credit_card"}'
AND created_at > NOW() - INTERVAL '30 days';

在執行計畫裡，你應該看到 Bitmap Index Scan on idx_orders_data，而不是 Seq Scan。如果還是全表掃描，檢查你的索引是否正確建立，以及查詢條件是否有用到支援的運算子。

如果你的 API 回傳大量 JSONB 資料給前端，也可以搭配 Redis 快取策略來減少資料庫壓力。特別是在 GraphQL vs REST API 架構下，善用快取能大幅提升回應速度。