待寫章節

• event.schema.json 完整欄位解說
• 欄位設計原則（source 標明來源 / data 自由欄位 / v 版本演進）
• Schema 版本演進策略（backward compatible 的增量變更）
• 跟 OpenTelemetry 的 schema 差異對照

跨分類引用

• SOT repo：tarrragon/monitor 的 schema/event.schema.json
• ← testing 模組二：log 點設計產出的事件需符合本 schema
• → monitoring 模組七 資安：schema 中哪些欄位需要 redaction

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 8.0 modern SQL 特性 — 5 個關鍵能力 + 跟 PostgreSQL 對應特性的對比。

「MySQL 是 SQL 簡單版」是個過時觀念。

這個觀念的來源很合理：MySQL 5.x 時代沒 CTE、window function 要嗑 hack、recursive query 寫不出來、JSON 處理是字串 substring 拼接、複雜分析 query 只能丟去 PostgreSQL 或 Snowflake。整整 10 年 SQL 進階特性 MySQL 全缺、PostgreSQL 全有。

MySQL 8.0（2018 推出）改變這件事。CTE / window function / lateral derived table / JSON_TABLE / hash join / atomic DDL / role-based authentication / common table expression 全部進來。這不是「終於跟上 PG」、是 MySQL 第一次有資格進入 SQL 工程深度討論。但有 caveats：每個特性的 行為實現 跟 PostgreSQL 對應特性都有 微妙差異、不能假設 PG 經驗直接套用。

對從 PostgreSQL 過來評估 MySQL 的讀者：本文是 特性對等驗證 — 哪些 8.0 特性真的可以 production 用、哪些是 marketing 但實作有 gap。對既有 MySQL 5.7 user：本文是 upgrade 5.7 → 8.0 的具體 ROI — 從 SQL feature 角度看升級值不值得。

5 個關鍵特性 + PG 對比

特性 1：CTE（Common Table Expression）

MySQL 8.0 / PG 8.4+ 都支援。

 1-- MySQL 8.0 + PG 都 OK
 2WITH order_summary AS (
 3    SELECT user_id, SUM(amount) AS total
 4    FROM orders
 5    WHERE created_at > '2026-01-01'
 6    GROUP BY user_id
 7)
 8SELECT u.name, os.total
 9FROM users u JOIN order_summary os ON u.id = os.user_id
10WHERE os.total > 1000;

行為差異：

• MySQL 8.0：CTE 不 materialize 為預設、optimizer 把 CTE 視為 inlined subquery、CTE 引用兩次以上會 重複計算
• PostgreSQL（< 12）：CTE fence by default（materialize barrier）、optimizer 不 push predicate 進 CTE
• PostgreSQL（12+）：CTE 行為跟 MySQL 接近、有 MATERIALIZED / NOT MATERIALIZED keyword 明示

對 PG 12+ user：可以套 MySQL 經驗。對 PG 11 以下 user：CTE 行為跟 MySQL 不一樣、要重看 query plan。

Recursive CTE：

1WITH RECURSIVE org_chart AS (
2    SELECT id, name, manager_id, 0 AS depth
3    FROM employees WHERE manager_id IS NULL
4    UNION ALL
5    SELECT e.id, e.name, e.manager_id, oc.depth + 1
6    FROM employees e JOIN org_chart oc ON e.manager_id = oc.id
7)
8SELECT * FROM org_chart WHERE depth <= 10;

兩家都支援、但 MySQL 8.0 有 深度上限（cte_max_recursion_depth=1000、預設 1000、PG 預設 unlimited）。複雜 hierarchical query（深度 > 1000）MySQL 需要顯式提高 limit。

特性 2：Window Function

MySQL 8.0 / PG 8.4+ 都支援、語法同 SQL standard。

1SELECT
2    order_id,
3    user_id,
4    amount,
5    SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at) AS running_total,
6    RANK() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rank_in_user
7FROM orders;

行為差異：

• 執行 plan：MySQL 8.0 用 window iterator、單 partition 內 sort、外加 in-memory window buffer。PostgreSQL 有更成熟的 WindowAgg node、複雜 frame spec 處理更好
• Frame spec 支援度：兩家都支援 ROWS / RANGE / GROUPS、但 GROUPS frame MySQL 是 8.0.16+ 才補進、PG 11+ 才補
• 大資料量 spill behavior：MySQL window function 超過 sort_buffer_size（預設 256K）會 spill 到 disk、Performance 雪崩。PG 用 work_mem（預設 4MB）、寬裕些但也會 spill

對長期用 PG window function 寫複雜 reporting query 的 user：MySQL 8.0 可以做、但 效能 tune 工作量大、不是 drop-in。

特性 3：JSON_TABLE（PG 主要賣點對比）

這是 user 點到的對比重點。

MySQL 8.0 的 JSON_TABLE：

 1SELECT t.id, j.name, j.price
 2FROM products t,
 3     JSON_TABLE(
 4         t.metadata,
 5         '$.variants[*]' COLUMNS (
 6             name VARCHAR(50) PATH '$.name',
 7             price DECIMAL(10,2) PATH '$.price'
 8         )
 9     ) AS j
10WHERE t.category = 'shoes';

JSON_TABLE 把 JSON document 內的 array element 展開成 relational rows、然後可以 JOIN / WHERE / GROUP BY。SQL:2016 standard 規範。

PostgreSQL 對應：

PG 17+ 有 JSON_TABLE（SQL:2016 standard、跟 MySQL 同語法）、但歷史上 PG user 用兩條不同路線：

1. JSONB operator（PG 9.4+）：

   1SELECT id, metadata->'variants' AS variants
   2FROM products
   3WHERE metadata @> '{"category": "shoes"}';

2. jsonb_path_query（PG 12+）：

   1SELECT t.id, v.name, v.price
   2FROM products t,
   3     jsonb_path_query(t.metadata, '$.variants[*]') AS v;

核心差異：

選型結論：

• MySQL 是 JSON-storage 角色（document 順手存進關聯 DB）：JSON_TABLE 夠用、配 generated column + index、production-ready
• MySQL 是 document-heavy workload（大量 JSON-driven query / 複雜 path / 高 selectivity）：PG JSONB GIN index 仍是 clearly winner、或直接用 MongoDB
• MySQL 8.0 JSON 不是 PG JSONB 替代：JSON_TABLE 是 SQL standard 對齊、好 portable、但 index 跟 storage 仍弱

對「JSON 是 PG 主要賣點」的判斷：JSONB binary storage + GIN index 是 PG 在 JSON workload 的 結構性優勢、MySQL 8.0 補了 SQL_TABLE 但 index 那層沒補。8.0 後 JSON 議題 不是 deal-breaker for MySQL（不像 5.7 時代直接 disqualify）、但仍不是 MySQL 主場。

特性 4：Lateral Derived Table

MySQL 8.0.14+ / PG 9.3+ 都支援。

1-- 對每個 user、找他最近 5 個 order
2SELECT u.id, recent.*
3FROM users u
4LEFT JOIN LATERAL (
5    SELECT order_id, amount
6    FROM orders o
7    WHERE o.user_id = u.id
8    ORDER BY created_at DESC LIMIT 5
9) recent ON true;

Lateral 讓 subquery 可以 引用外部 reference column（u.id）、不可能用 plain subquery 寫出來。

行為差異：

• MySQL 8.0：lateral 後加、optimizer plan 仍在演進、複雜 lateral query 可能 plan 次優
• PostgreSQL：lateral 早就成熟、plan 跟 join 直接 fuse、效率高

對 PG-experienced 使用 lateral 寫 reporting query 的 user：MySQL 8.0 可以、但有時候要 hint optimizer 達到最佳 plan。

特性 5：Hash Join

MySQL 8.0.18+ / PG 早已有。

MySQL 8.0 之前：只有 nested loop join、大表 JOIN 完全失控（n × m row scan）。8.0.18 加 hash join、optimizer 在預估 row count 大時自動切。

注意：MySQL 8.0 hash join 預設 不對所有 join 開、只在 optimizer_switch='hash_join=on' 且 join condition 是 equality on indexed column 時觸發。常見錯估：複雜 join 條件不觸發 hash join、optimizer fallback nested loop、query 永遠跑不完。

PG 對應：PG 一直有 hash join、optimizer 預設 cover 廣、且有 parallel hash join（PG 11+）大表 JOIN 並行加速。

MySQL hash join 是 補洞、不是 並肩特性。複雜 OLAP query MySQL 仍弱於 PG。

其他 8.0 特性（一句話帶過）

• Atomic DDL：CREATE TABLE / DROP / ALTER 變 transactional、crash recovery 不會留 orphan table（PG 早就 atomic）
• Role-based authentication：role 取代 group-level grant、user 可繼承 role（PG 早就 role 系統）
• CHECK constraint enforcement：5.7 可寫但不執行、8.0 真的 enforce（PG 一直執行）
• invisible index：建 index 但 optimizer 暫不用、適合 staging query plan 測試（PG 沒原生對應）
• Resource Group：query 跑時可分配 CPU thread 給特定 user group（PG 沒原生對應）
• Generated column：MySQL 5.7 已有、8.0 強化、可作為 JSON path 加速的 workaround

配置 step-by-step（從 5.7 → 8.0 SQL feature 升級）

如果已經是 8.0、所有特性都可以用、不必額外配置。如果是 5.7 → 8.0、需要：

1. character_set_server=utf8mb4：8.0 預設 utf8mb4（5.7 預設 latin1）、character set 不一致導致 query 行為微差
2. default_authentication_plugin=mysql_native_password：8.0 預設 caching_sha2_password、舊 client 連不上、cluster upgrade 期間用 native_password 保兼容
3. optimizer_switch='hash_join=on'：確認 hash join 啟用、預設應該已 ON
4. cte_max_recursion_depth=10000：複雜 recursive CTE 需要時提高
5. 重新 review 所有 ORM-generated SQL：8.0 keywords 變多（WINDOW、RANK、LATERAL 等變成 reserved word）、5.7 識別碼可能變 syntax error

5 個 Production 踩雷

1. CTE 引用兩次 = 跑兩次

1WITH expensive AS (SELECT ... heavy aggregation ...)
2SELECT * FROM expensive WHERE ...
3UNION ALL
4SELECT * FROM expensive WHERE other_condition;

預期 CTE 跑一次、實際 MySQL 跑兩次。Query 時間 doubled。

修法：

• 把 CTE 結果先 INSERT 進 temporary table、SELECT 兩次走 temp table（手動 materialize）
• 或 PG 用 MATERIALIZED keyword（MySQL 沒對應 hint、要手動 temp table）

2. Window function 大 partition spill 到 disk

1SELECT order_id,
2       SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at)
3FROM orders;  -- 1 億 row

sort_buffer_size=256K 預設、單 partition > 256K row 開始 spill disk、執行從秒級變分鐘級。

修法：

• 提高 sort_buffer_size（per-connection、不要設太大、connection × buffer 會吃 RAM）
• 加 INDEX 包含 user_id, created_at、optimizer 可直接用 sorted index、不必額外 sort

3. JSON_TABLE 跟 generated column 取捨錯誤

直接 JSON_TABLE on every query：

1SELECT * FROM products,
2JSON_TABLE(metadata, '$.variants[*]' COLUMNS (...));

每次 query 跑 JSON parse、無 index 加速、大表 query 慢。

修法：

• 對 常 query 的 JSON path 建 generated column：

  1ALTER TABLE products
  2ADD COLUMN category VARCHAR(50)
  3GENERATED ALWAYS AS (JSON_UNQUOTE(metadata->'$.category')) STORED,
  4ADD INDEX idx_category (category);

• JSON_TABLE 用於 ad-hoc query、不要當熱 path

• 跟 PG JSONB GIN 對比：PG 不必預先建 generated column、GIN index 直接 over JSONB

4. Hash join 沒觸發 — Optimizer 預估錯 row count

JOIN 大表預期 hash join、實際 MySQL 跑 nested loop、query 跑不完。常見原因：

• Table statistics 過時（沒跑 ANALYZE TABLE）
• Join condition 不是 pure equality（a.id = b.id + 1 等）
• 一邊有 LIMIT、optimizer 估 small set、選 nested loop

修法：

• 跑 ANALYZE TABLE 更新 statistics
• 用 EXPLAIN ANALYZE 看實際 row count vs 估計
• 用 optimizer_hint（如 /*+ HASH_JOIN(t1 t2) */）強制

5. Recursive CTE 深度上限 — Production query 突然 fail

cte_max_recursion_depth=1000 預設、organization hierarchy / tree query 超過 1000 層直接 fail（ER_CTE_MAX_RECURSION_DEPTH_EXCEEDED）。

修法：

• 評估真實 hierarchy 深度、設 cte_max_recursion_depth=10000 或更高
• 或 query 加 WHERE depth < N 提前停（不依賴 implicit limit）
• 對極大 hierarchy（社群 follow graph 等）改用 graph DB（Neo4j）— MySQL recursive CTE 不是 graph workload 主場

MySQL 8.0 vs PG SQL 特性 cross-reference

8.0 補了 語法層 大部分缺漏、storage / index / extensibility 層 仍是 PG 結構優勢。對「先選 SQL 工程深度」的 org、PG 仍領先；對「先選 ecosystem / replication / sharding」的 org、MySQL 已不是 disqualifier。

跟其他模組整合

跟 InnoDB Tuning

JSON column 在 InnoDB 是 LONGTEXT 包裝、大 JSON 進 off-page storage（innodb_default_row_format=DYNAMIC 才行、Antelope format 不支援）。Buffer pool 對 LONGTEXT 較不友善、大 JSON workload 可能要更大 buffer pool。詳見 InnoDB Tuning。

跟 Query Optimization

8.0 新 hash join + lateral derived 讓 EXPLAIN ANALYZE 結果更複雜。優化複雜 query 需要熟 新 plan node 類型。詳見 Query Optimization deep dive 篇（待寫）。

跟 Online Schema Change

JSON column 跟 generated column 的 schema change 走 gh-ost / pt-osc 沒問題、但 JSON 大表 ALTER 速度比一般 column 慢（每 row 重 serialize）。詳見 Online Schema Change Tools。

跟 Replication

Window function / CTE / JSON_TABLE 的 query 結果 replicate（row-level binlog 紀錄結果）、不 replicate query 本身。所以 replica apply 不會重新跑 window function、效率 OK。詳見 Replication Topology。

何時 SQL 特性是 MySQL 選型 driver

• 想要 SQL standard 對齊跨 vendor portable：MySQL 8.0 JSON_TABLE / window 都對齊 standard、PG 部分能力（JSONB operator）是 PG-only、portability MySQL 略好
• JSON workload < 20% query：MySQL 8.0 + generated column 夠用、不必為 JSON 換 PG
• JSON workload > 50% query + 複雜 path / aggregation：PG JSONB GIN 仍 winner、考慮 PG 或 MongoDB
• 需要 materialized view / FDW / partial index：PG 仍領先、不要因為 SQL feature parity 假設 MySQL 全 cover
• 既有 MySQL 投資 + SQL 工程深度上升：升 8.0 + 訓練團隊用新特性、不是換 vendor

相關連結

• MySQL vendor overview
• InnoDB Tuning（JSON column 對 buffer pool 影響）
• Online Schema Change Tools（JSON column 大表 ALTER）
• Replication Topology（ROW-format binlog 對 window function）
• PostgreSQL SQL Features Baseline（PG 反向視角、哪些特性 PG 早 5-15 年、MySQL 8.0 補齊後 PG 仍領先）
• PostgreSQL JSONB Deep Dive（PG sibling、binary storage + GIN index 跟 MySQL JSON_TABLE 對比）
• PostgreSQL vendor page（JSON / SQL feature 對比 source）
• MongoDB vendor page（document-heavy workload 替代）
• 官方：MySQL 8.0 What’s New

本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 PG 在 OLTP 譜系的定位、本文聚焦 JSONB deep dive — binary storage + GIN index 的結構性優勢。

JSON vs JSONB：選 JSONB

PG 9.2 加 JSON type、9.4 加 JSONB。99% 場景用 JSONB：

JSONB 唯一缺點是 binary 儲存（不保留 key order / whitespace / duplicate）。99% application 不在意這些。

從 application semantics 視角、JSONB 是 PG JSON 的 the right type、JSON 是 legacy / niche。

JSONB GIN Index：核心結構性優勢

PG GIN（Generalized Inverted Index）可以對 JSONB 內所有 key/value pair 建 inverted index：

1CREATE TABLE products (
2    id SERIAL PRIMARY KEY,
3    metadata JSONB
4);
5
6-- GIN index
7CREATE INDEX idx_products_metadata ON products USING GIN (metadata);

加完後、JSONB query 用 GIN index 加速：

1-- @> (contains) 用 GIN
2SELECT * FROM products WHERE metadata @> '{"category": "shoes"}';
3
4-- ? (has key) 用 GIN
5SELECT * FROM products WHERE metadata ? 'discount';
6
7-- ?| (has any of these keys) 用 GIN
8SELECT * FROM products WHERE metadata ?| array['discount', 'promotion'];

跟 MongoDB index 對比、PG 不必 預先 define JSON path index、USING GIN (metadata) 對 整個 JSONB document 任意 path 都有效。

jsonb_ops vs jsonb_path_ops

PG GIN 對 JSONB 有兩種 operator class：

1-- jsonb_ops（預設）
2CREATE INDEX idx_meta_default ON products USING GIN (metadata);
3
4-- jsonb_path_ops（小、快、但只支援 @>）
5CREATE INDEX idx_meta_path ON products USING GIN (metadata jsonb_path_ops);

選擇：

• 只跑 @> containment query → jsonb_path_ops（index 小、快）
• 跑 ? / ?| / ?& key existence query → jsonb_ops（預設）

Operator + Path Query

JSONB 提供豐富 operator + jsonpath：

Operator

 1-- Extract value（returns jsonb）
 2SELECT metadata -> 'name' FROM products;
 3
 4-- Extract text（returns text）
 5SELECT metadata ->> 'name' FROM products;
 6
 7-- Path extract
 8SELECT metadata #> '{variants, 0, price}' FROM products;
 9SELECT metadata #>> '{variants, 0, price}' FROM products;  -- 返回 text
10
11-- Containment（用 GIN index）
12SELECT * FROM products WHERE metadata @> '{"category": "shoes", "active": true}';
13
14-- Reverse containment
15SELECT * FROM products WHERE '{"sub": "value"}' <@ metadata;
16
17-- Key existence
18SELECT * FROM products WHERE metadata ? 'discount';
19SELECT * FROM products WHERE metadata ?| array['a', 'b'];  -- 任一 key
20SELECT * FROM products WHERE metadata ?& array['a', 'b'];  -- 全部 key

jsonpath（PG 12+）

SQL/JSON jsonpath 是 SQL standard、PG 12+ 支援：

 1-- jsonb_path_query：展開 path 結果
 2SELECT jsonb_path_query(metadata, '$.variants[*].price')
 3FROM products WHERE id = 1;
 4
 5-- jsonb_path_exists：返 boolean
 6SELECT * FROM products
 7WHERE jsonb_path_exists(metadata, '$.variants[*] ? (@.price > 100)');
 8
 9-- jsonb_path_query_array：返 array of result
10SELECT jsonb_path_query_array(metadata, '$.tags[*]')
11FROM products;

jsonpath 比 PG-specific operator 標準化、跨 vendor portable。

Partial JSONB Index

對 只 query subset row 的場景、建 partial index：

1-- 只對 active product 建 metadata index
2CREATE INDEX idx_active_products_metadata
3ON products USING GIN (metadata)
4WHERE status = 'active';
5
6-- Query active products + JSONB filter
7SELECT * FROM products
8WHERE status = 'active' AND metadata @> '{"category": "shoes"}';
9-- → planner 用 partial GIN index

Partial index 比 full GIN 小很多、write cost 低、index hit rate 高。

5 個 Production 踩雷

1. 大 JSONB + TOAST — 性能崩潰

JSONB > 2 KB 自動進 TOAST（PG 內外部 storage）、每次 query read 該 row 都要 de-TOAST（拉外部 storage 再合併）。大 JSONB（> 50 KB）每次 query 慢 10-100x。

修法：

• 把 大 attribute 拆獨立 column（如 description TEXT 不放 metadata）
• 用 JSON path index 對 hot path 加速、不必每次讀整個 JSONB
• 用 pg_column_size(metadata) 監控 JSONB size 分布、找 outlier
• 對 truly 大 document（> 1 MB）考慮 separate table 或 object storage

2. Nested update — 整個 JSONB 重寫

PG 沒 atomic partial update。修改 nested key 必須讀整個 JSONB → 修改 → 寫回：

1UPDATE products
2SET metadata = jsonb_set(metadata, '{discount}', '0.2'::jsonb)
3WHERE id = 100;
4-- 等同於：讀 metadata、改 discount、寫回整個 metadata

對 大 JSONB + 高頻 update 場景、寫吞吐受限。跟 MongoDB $set operator 對應 partial document update 不同。

修法：

• 對 high-update nested key 拆獨立 column
• Application 層 batch update（攢一批一次 update）
• 接受 PG JSONB 是 immutable-replace 心智模型、不是 mutable in-place

3. Index 選錯 op class — ? query 走 full scan

對 jsonb_path_ops index、? key existence query 走 full scan（不用 index）。Application 看 query 慢、查 EXPLAIN 才發現 index 沒用。

修法：

• 設計階段確認 application query pattern：只用 @> 還是會用 ?
• 多 query pattern → jsonb_ops（預設）
• 純 containment → jsonb_path_ops（省 index size）
• 不確定先用預設、production 觀察後再優化

4. jsonb_path_query 跟 jsonb_path_exists 行為差

• jsonb_path_query(metadata, '$.variants[*].price') — 展開、每個 match return 一 row
• jsonb_path_exists(metadata, '$.variants[*]') — return boolean（true if any match）

Application 想要「過濾 row」用前者寫成：

1-- 錯：返多 row 給每個 product、結果 row count 暴增
2SELECT id, jsonb_path_query(metadata, '$.variants[*].price') FROM products;

應該：

1-- 對：只過濾 product
2SELECT * FROM products WHERE jsonb_path_exists(metadata, '$.variants[*] ? (@.price > 100)');

修法：

• 區分 exists 過濾 row vs query 展開 row
• 過濾用 jsonb_path_exists 或 @> operator
• 展開用 jsonb_path_query + 配合 LATERAL 或 subquery

5. Partial index 條件不對齊 query

1CREATE INDEX idx_active_metadata ON products USING GIN (metadata) WHERE status = 'active';
2
3-- Application query 但 status 沒 explicit
4SELECT * FROM products WHERE metadata @> '{"category": "shoes"}';
5-- → 不用 partial index（planner 不知道 status='active' 條件）

修法：

• Application query 必須包含 partial index 的 WHERE 條件：

  1SELECT * FROM products WHERE status = 'active' AND metadata @> '...';

• 確認 planner 用 partial index：EXPLAIN 看 Index Scan using idx_active_metadata

• 不對齊 query pattern 的 partial index = waste

何時用 JSONB vs 拆 column

JSONB 是 PG 適合 semi-structured data 的工具、不是 MongoDB 替代品。對 主要結構化 + 少量 JSON 場景 JSONB 完美；對 主要 JSON / 複雜 nested aggregation 場景 MongoDB 仍是專業選擇。

跟其他模組整合

跟 Query Optimization

JSONB query 的 planner 行為：

• @> containment 對 jsonb_ops / jsonb_path_ops 都用 GIN
• ? 只對 jsonb_ops 用 GIN
• jsonb_path_exists 用 functional index（不是 GIN）
• 看 EXPLAIN 確認用對 index、詳見 Query Optimization

跟 SQL Features Baseline

JSONB 是 PG 結構性領先特性之一、詳見 SQL Features Baseline。

跟 MVCC + Lock Model

JSONB UPDATE 整個 column 重寫、每次 update 創新 tuple、跟 row update 相同 MVCC behavior。詳見 MVCC + Lock Model。

跟 MySQL JSON_TABLE

MySQL 8.0 JSON_TABLE 跟 PG jsonpath 類似（都 SQL standard）、但 index 機制 完全不同：

• PG：JSONB + GIN index over 整個 column
• MySQL：JSON column + generated column + index over generated

PG JSONB GIN 是 結構性領先、MySQL 短期內難對應。詳見 MySQL Modern SQL Features。

觀測 metric

• pg_column_size(metadata) — 每 row JSONB size 分布
• pg_relation_size('idx_name') — JSONB GIN index 大小
• pg_stat_user_indexes.idx_scan — JSONB index 使用次數
• TOAST table size：SELECT pg_relation_size(reltoastrelid) FROM pg_class WHERE relname='products'

相關連結

• PostgreSQL vendor overview
• PG SQL Features Baseline（JSONB 是 PG 結構領先之一）
• PG Query Optimization（JSONB index 用對）
• PG MVCC + Lock Model（JSONB update 跟 MVCC）
• MySQL Modern SQL Features（JSON_TABLE vs JSONB 對比）
• MongoDB vendor（純 document workload 替代）
• 官方：PG JSON Functions / JSONB Indexing

本文的判讀錨點是：Document Store 是 MySQL 內的 document access pattern，而非 MongoDB 等專用 document database 的完整替代。它適合 relational schema 旁邊的 flexible JSON，但不適合把主要資料模型都藏進無治理 JSON。

官方文件路由的核心責任是固定 X Protocol claim。實作前先查 MySQL 8.4 Document Store；本文最後檢查日是 2026-05-22。

Responsibility Boundary

Responsibility boundary 的核心責任是把 Document Store 和 SQL table 關係說清楚。

Document Store 的價值是降低 flexible object 的開發摩擦。它不免除資料合約、index、migration、backup 與 audit 的責任。

Suitable Use Cases

Suitable use cases 的核心責任是找出 document pattern 的合理位置。

Document Store 最適合局部 flexible data。若核心 query 需要大量 join、aggregation、transaction invariant，應把穩定欄位拉回 relational schema。

Query and Index

Query and index 的核心責任是避免 JSON 查詢變成不可觀測黑箱。

MySQL JSON 查詢可以從 generated column 建 index。正式服務要把常用 JSON path 寫進 query contract，避免每次都掃完整 document。

Migration Boundary

Migration boundary 的核心責任是讓 document data 可演進。Document 欄位雖然 flexible，但 application 仍會依賴某些 key；這些 key 一旦進入 workflow，就要有版本與 validation。

最小治理：

1. Document version field。
2. Required key validation at application boundary。
3. Backfill script for new required key。
4. Index review for promoted key。
5. Export / backup restore validation。

當 JSON key 變成 join key、permission key 或 reporting key，應評估搬到 relational column。

No-Go Conditions

No-go conditions 的核心責任是指出 Document Store 的邊界。

Document Store 要服務於 flexible edge，而非取代資料建模。當 flexible area 穩定下來，就把它納入 schema governance。

下一步路由

Document Store / X Protocol 完成後，JSON 與 SQL 能力讀 Modern SQL Features；若主要資料模型是 document，讀 MongoDB；migration 到 PostgreSQL JSONB 可讀 MySQL to PostgreSQL。