PostgreSQL 17 JSON_TABLE 完整教學：用 SQL 直接查詢 JSON 資料的終極方案

如果你有在用 PostgreSQL 存 JSON 資料（誰沒有呢？），你一定寫過那種又長又醜的 jsonb 查詢——一堆箭頭運算子、jsonb_array_elements、lateral join，看得頭都暈了。每次寫完都想說：為什麼不能直接用 SQL 查 JSON 就好？

PostgreSQL 17 的 JSON_TABLE 就是來回答這個問題的。它讓你用純 SQL 語法把 JSON 資料「攤平」成關聯式的行與列，就像查普通的資料表一樣直覺。

什麼是 JSON_TABLE？

JSON_TABLE 是 SQL/JSON 標準的一部分，讓你直接在 FROM 子句中把 JSON 文件轉換成虛擬的關聯式表格。簡單說：JSON 進去，Table 出來。

這個功能在 Oracle 和 MySQL 8.0 中早就有了，PostgreSQL 終於在 17 版追上。對於已經習慣用 PostgreSQL 的後端工程師來說，這是一個巨大的生產力提升。

基本語法

JSON_TABLE 的基本語法是放在 FROM 子句中，指定 JSON 資料來源、路徑表達式和欲提取的欄位。你需要定義 COLUMNS 子句來指定每個輸出欄位的名稱、型別和 JSON 路徑。

舉個例子：假設你有一個訂單表，orders 欄位中有一個 jsonb 的 items 欄位存放訂單明細。以前你要用 jsonb_array_elements 搭配 lateral join，現在直接用 JSON_TABLE 就能攤平。

巢狀路徑（NESTED PATH）

JSON_TABLE 支援 NESTED PATH，可以處理多層巢狀的 JSON 結構。例如訂單裡面有商品列表，每個商品又有變體（尺寸、顏色），都可以用 NESTED PATH 一層一層展開。

這在以前需要多層 lateral join 才能做到的事情，現在一個 JSON_TABLE 就搞定了，可讀性大幅提升。

錯誤處理

JSON_TABLE 提供了內建的錯誤處理機制。你可以在 COLUMNS 定義中指定 DEFAULT ... ON ERROR，當 JSON 路徑找不到對應的值時，會使用預設值而不是拋出錯誤。

還有 ON EMPTY 子句，處理 JSON 路徑存在但值為空的情況。這兩個機制讓你在處理不完美的 JSON 資料時更加從容。

跟傳統 jsonb 查詢的比較

實際應用場景

場景 1：電商訂單分析

電商系統常把訂單明細存成 JSON。用 JSON_TABLE 可以直接寫報表查詢，例如「各商品類別的月銷售額」，不需要先把 JSON 資料 ETL 到另一個表。

場景 2：API 日誌分析

API 日誌通常以 JSON 格式儲存。JSON_TABLE 讓你直接在資料庫中分析請求模式，不需要額外的日誌分析工具。搭配 Deno 2 後端開發的 API 設計，可以建立完整的監控管道。

場景 3：設定檔管理

應用程式的設定檔常存成 JSON。用 JSON_TABLE 可以輕鬆查詢和比對不同環境的設定差異。

效能考量

JSON_TABLE 在大多數情況下效能跟手寫的 jsonb 查詢差不多，甚至更好，因為查詢規劃器可以更好地理解你的意圖。但有幾點需要注意：

• 對常查詢的 JSON 路徑建立 GIN 索引
• 避免在超大 JSON 文件上使用（考慮先正規化）
• 善用 EXISTS 子句做條件過濾
• NESTED PATH 層數不要太深（建議不超過 3 層）

PostgreSQL 17 其他重點更新

除了 JSON_TABLE，PostgreSQL 17 還有幾個值得後端工程師關注的更新：

• 增量備份：大幅減少備份時間和儲存空間
• 邏輯複製槽故障轉移：高可用架構更可靠
• 並行查詢增強：FULL JOIN 和 RIGHT JOIN 支援平行執行
• pg_maintain 角色：讓普通使用者執行維護操作

如果你在用 Prisma ORM，升級到 PostgreSQL 17 後可以在 raw query 中直接使用 JSON_TABLE。搭配 Cloudflare Workers 邊緣運算做 API 層，就是 2026 年最現代的後端架構。

總結

JSON_TABLE 是 PostgreSQL 17 最實用的新功能之一。它不會改變你的資料庫架構，但會大幅改善你查詢 JSON 資料的開發體驗。如果你的資料庫中有任何 jsonb 欄位，升級到 PostgreSQL 17 並開始使用 JSON_TABLE，你會回不去的。