本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 native partitioning — 5 段 lifecycle + 4 種 type + 跟 Vitess sharding / PG partitioning 對比。

Partition lifecycle 五段

MySQL native partitioning 是 同 instance 內把一個邏輯 table 拆成多個 physical sub-table、optimizer 可選擇只 scan 相關 partition。整個 partition lifecycle 5 段：

1Design       決定 partition key / type / 數量
2   ↓
3Create       CREATE TABLE ... PARTITION BY ...
4   ↓
5Query        WHERE clause + partition pruning
6   ↓
7Maintenance  ADD / DROP / REORGANIZE / EXCHANGE
8   ↓
9Drop         整個 partition 一次刪（比 DELETE FROM 快 1000x）

每段都有獨立工程決策。設計階段選錯 partition key、後續 maintenance + query 全部 broken。

跟 Vitess sharding 對比：

• MySQL partitioning：同 instance、optimizer 自動 pruning、無 cross-instance network cost
• Vitess sharding：跨 instance、application 透過 VTGate routing、可線性 scale

兩者不衝突、可組合：Vitess shard 內部 再 用 MySQL partition（例如：shard 切 16 個、每個 shard 的 table 再按月份 partition）。

4 種 partition type

RANGE partitioning — 連續區間切割

最常見、適合 time-series / 連續數字：

 1CREATE TABLE orders (
 2    id BIGINT AUTO_INCREMENT,
 3    user_id BIGINT NOT NULL,
 4    amount DECIMAL(10,2),
 5    created_at DATETIME NOT NULL,
 6    PRIMARY KEY (id, created_at)              -- PK 必須含 partition key
 7)
 8PARTITION BY RANGE (TO_DAYS(created_at)) (
 9    PARTITION p202601 VALUES LESS THAN (TO_DAYS('2026-02-01')),
10    PARTITION p202602 VALUES LESS THAN (TO_DAYS('2026-03-01')),
11    PARTITION p202603 VALUES LESS THAN (TO_DAYS('2026-04-01')),
12    PARTITION p_future VALUES LESS THAN MAXVALUE  -- 未來資料 fallback
13);

優點：

• Partition pruning 高效（時間 range query）
• 整個月 archive 直接 ALTER TABLE orders DROP PARTITION p202601、毫秒級

缺點：

• 必須 預先建 未來 partition（或用 p_future fallback、但 fallback partition 變大就失去 pruning 意義）
• Hot partition — 最新 partition 接收所有 INSERT、其他 partition 純歷史

LIST partitioning — 離散值切割

適合 enum-like value：

 1CREATE TABLE users (
 2    id BIGINT,
 3    name VARCHAR(100),
 4    region VARCHAR(10) NOT NULL,
 5    PRIMARY KEY (id, region)
 6)
 7PARTITION BY LIST COLUMNS (region) (
 8    PARTITION p_asia VALUES IN ('TW', 'JP', 'KR', 'CN'),
 9    PARTITION p_americas VALUES IN ('US', 'CA', 'BR'),
10    PARTITION p_emea VALUES IN ('GB', 'DE', 'FR', 'IT')
11);

優點：對 enum-like value 直接命中、pruning 簡單。

缺點：value list 不能變更（不 supported ALTER PARTITION ADD VALUE）、新國家代碼必須 REORGANIZE。

HASH partitioning — 均勻分布

對 numeric / string column 取 hash、均勻分布：

1CREATE TABLE events (
2    id BIGINT,
3    user_id BIGINT NOT NULL,
4    event_type VARCHAR(50),
5    PRIMARY KEY (id, user_id)
6)
7PARTITION BY HASH (user_id) PARTITIONS 8;

優點：均勻分布、沒有 hot partition。

缺點：

• Range query 沒效 — WHERE user_id BETWEEN 100 AND 200 不能 pruning、scan 全部 partition
• Partition 數量改變需要 REORGANIZE 整張表

KEY partitioning — MySQL 內部 hash

跟 HASH 類似、但用 MySQL 內部 hash function（不依賴 column 是否 integer）：

1CREATE TABLE sessions (
2    session_id VARCHAR(64),
3    user_id BIGINT NOT NULL,
4    data TEXT,
5    PRIMARY KEY (session_id, user_id)
6)
7PARTITION BY KEY (user_id) PARTITIONS 16;

用於 string column 或 composite column 的均勻分布。一般場景跟 HASH 效果接近。

Sub-partitioning — 兩層切割

RANGE + HASH 組合、深化分隔：

 1CREATE TABLE big_events (
 2    id BIGINT,
 3    user_id BIGINT,
 4    created_at DATETIME,
 5    PRIMARY KEY (id, created_at, user_id)
 6)
 7PARTITION BY RANGE (TO_DAYS(created_at))
 8SUBPARTITION BY HASH (user_id) SUBPARTITIONS 4 (
 9    PARTITION p202601 VALUES LESS THAN (TO_DAYS('2026-02-01')),
10    PARTITION p202602 VALUES LESS THAN (TO_DAYS('2026-03-01'))
11);

每個 RANGE partition 又拆 4 個 HASH sub-partition、共 8 個 physical storage location。適合 時間 range + user_id hash 兩維度。

實務罕用、複雜性高、調 query plan 困難。多數 case 用 single-level partition 即可。

Partition Pruning — Optimizer 怎麼選 partition

EXPLAIN PARTITIONS SELECT ... 顯示 query 命中哪些 partition：

1EXPLAIN PARTITIONS
2SELECT * FROM orders WHERE created_at BETWEEN '2026-02-15' AND '2026-02-20';
3
4+----+-------------+--------+------------+-------+
5| id | select_type | table  | partitions | type  |
6+----+-------------+--------+------------+-------+
7|  1 | SIMPLE      | orders | p202602    | range |
8+----+-------------+--------+------------+-------+

只命中 p202602、其他 partition 不 scan。

Pruning 失效場景：

1. Function on partition key：

   1WHERE YEAR(created_at) = 2026  -- 沒 pruning、scan 全部

   應該寫成：

   1WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01'

2. Implicit conversion：

   1WHERE created_at = '2026-02-15'  -- 字串 vs DATETIME、可能失效

   應該：

   1WHERE created_at = TIMESTAMP '2026-02-15 00:00:00'

3. OR 跨 partition：

   1WHERE created_at = '2026-02-15' OR user_id = 100  -- partition + non-partition column OR、scan 全部

4. JOIN 不直接 filter partition key：JOIN 條件不含 partition key、optimizer 估計無法 pruning。

Partition Maintenance — ADD / DROP / REORGANIZE / EXCHANGE

ADD partition

1ALTER TABLE orders ADD PARTITION (
2    PARTITION p202604 VALUES LESS THAN (TO_DAYS('2026-05-01'))
3);

對 RANGE 簡單、但要 排在 MAXVALUE partition 之前（如果有 p_future、要先 REORGANIZE）。

DROP partition

1ALTER TABLE orders DROP PARTITION p202601;

直接刪 partition file、毫秒級完成。是 time-series archive 的最大優勢 — 對比 DELETE FROM orders WHERE created_at < '...' 跑 hours。

REORGANIZE partition

切分 / 合併 partition：

1-- 切：把 p_future 切成 p202604 + new p_future
2ALTER TABLE orders REORGANIZE PARTITION p_future INTO (
3    PARTITION p202604 VALUES LESS THAN (TO_DAYS('2026-05-01')),
4    PARTITION p_future VALUES LESS THAN MAXVALUE
5);

REORGANIZE rewrites partition data、跟 OSC 一樣慢、大 partition 走 gh-ost / pt-osc 模擬（用 ghost table）。

EXCHANGE partition

把 partition 跟 獨立 table swap（不複製資料）：

1-- 建一個 staging table 跟 partition 同 schema
2CREATE TABLE orders_staging LIKE orders;
3ALTER TABLE orders_staging REMOVE PARTITIONING;  -- staging 必須是 non-partitioned
4
5-- 把 archive partition 的資料 atomic swap 給 staging
6ALTER TABLE orders EXCHANGE PARTITION p202601 WITH TABLE orders_staging;
7
8-- 現在 orders_staging 有 p202601 的資料、orders 的 p202601 變空
9-- 可以 dump staging 到 S3、或 INSERT 進 archive DB

EXCHANGE PARTITION 是 metadata operation、毫秒級完成、不複製資料。Time-series archive 工作流的核心工具。

5 個 Production 踩雷

1. PK 必須含 partition key — Schema 設計受限

MySQL partition 規則：PK 必須包含所有 partition key column。

1-- 錯：PK 沒包含 partition key
2CREATE TABLE orders (
3    id BIGINT AUTO_INCREMENT PRIMARY KEY,  -- 只有 id
4    created_at DATETIME NOT NULL
5) PARTITION BY RANGE (TO_DAYS(created_at)) (...);
6-- ERROR 1503: A PRIMARY KEY must include all columns in the table's partitioning function

1-- 對：PK 包含 partition key
2CREATE TABLE orders (
3    id BIGINT AUTO_INCREMENT,
4    created_at DATETIME NOT NULL,
5    PRIMARY KEY (id, created_at)  -- 兩 column 都進 PK
6) PARTITION BY RANGE (TO_DAYS(created_at)) (...);

修法：

• 接受 PK 是 composite（id + partition_key column）
• AUTO_INCREMENT 仍 work、但 INSERT 必須給定 created_at
• Unique constraint 也受影響 — 所有 UNIQUE index 必須含 partition key

對 application：原本 WHERE id = X 仍 work、但慢（沒 partition pruning）、必須 WHERE id = X AND created_at >= ... 才高效。

2. Global index 沒原生支援

MySQL partitioning 沒 global secondary index（PG 有）。每個 partition 各自有自己的 local index、跨 partition 的 unique constraint 必須 包含 partition key。

例：希望 user_id 全表 unique、但 partition by created_at：

1-- MySQL 不允許這樣 — UNIQUE 必須含 created_at
2CREATE TABLE orders (
3    id BIGINT AUTO_INCREMENT,
4    user_id BIGINT,
5    created_at DATETIME,
6    PRIMARY KEY (id, created_at),
7    UNIQUE KEY (user_id, created_at)  -- 必須含 created_at、不是純 user_id
8);

對 application：跨 partition 的 unique 需要 application 層處理（INSERT 前 SELECT 檢查）或改用 Vitess lookup_hash Vindex。

3. EXCHANGE partition — schema 必須完全一致

EXCHANGE 失敗常見：staging table 跟 partition 的 index / column 順序差一個、ERROR 1736: Tables have different definitions。

修法：

• 建 staging 用 CREATE TABLE staging LIKE orders 而非手寫
• REMOVE PARTITIONING 後立即 verify schema
• 跑 OSC 改 schema 時、partition + staging table 同時改、不能漏一個

4. Orphan partition — Future partition 預先建忘記延展

部署 cron 每月建下個月 partition、cron 失敗 / pause、下個月 INSERT 無對應 partition、寫入 p_future。p_future 一年累積後變超大、partition pruning 沒效、查最近資料 scan 全表。

修法：

• 監控 p_future partition size、超過 threshold alert
• Cron 失敗 alert（不是 silent fail）
• 不依賴 cron、改成 application 層在 INSERT 前 ensure partition exists（lazy create）

5. Cross-partition query 慢

1SELECT user_id, SUM(amount) FROM orders GROUP BY user_id;

沒 partition key filter、optimizer 不能 pruning、scan 全部 partition。比 single big table without partition 還慢（因為跨 partition aggregation overhead）。

修法：

• 接受 partition 不是 讀效能 工具、是 write + archive 效能 工具
• 跨 partition aggregation 改 materialized aggregation table（trigger / scheduled job 維護）
• 跨 partition reporting 改丟 OLAP DB（BigQuery / Snowflake / ClickHouse）

跟 Vitess sharding 對比

兩者不衝突、適用不同問題。Partitioning 解決 單 instance archive + write 集中、sharding 解決 跨 instance scale。

跟 PostgreSQL declarative-partitioning 對比

PG partitioning 對 跨 partition unique 跟 partition-wise join 處理較好、是 reporting workload 的優勢。MySQL partitioning 對 archive workflow（DROP / EXCHANGE）較成熟。詳見 PostgreSQL Declarative Partitioning。

何時用 native partitioning

跟其他模組整合

跟 Online Schema Change

對 partitioned table 的 schema change（ALTER COLUMN）必須 每個 partition 都改。gh-ost / pt-osc 對 partitioned table 仍 work、但複雜性增加。詳見 Online Schema Change Tools。

跟 Vitess

Vitess shard 內部可再 partition、單 shard 對應一個 MySQL instance、partition 是 instance 內優化。Vitess vtctldclient PartitionTablet 命令處理 shard-aware partition 操作。詳見 Vitess sharding。

跟 InnoDB Tuning

每個 partition 是獨立 InnoDB tablespace（innodb_file_per_table=ON 預設）、buffer pool 內 cache 行為跟 single big table 不同。Partition 多時 buffer pool warm-up 時間更長。詳見 InnoDB Tuning。

跟 Replication

Partition operation（ADD / DROP / EXCHANGE）是 DDL、走 binlog、replica apply 時可能 locking issue（特別是 EXCHANGE 跟 replica running query 衝突）。詳見 Replication Topology。

跟 Query Optimization

EXPLAIN PARTITIONS 是 partition-aware query optimization 的關鍵工具、看 query 真的命中哪些 partition。詳見 Query Optimization。

容量規劃要點

相關連結

• MySQL vendor overview
• MySQL Vitess sharding（跨 instance 切割對比）
• MySQL Online Schema Change（partition table 的 schema change）
• MySQL Query Optimization（EXPLAIN PARTITIONS）
• MySQL InnoDB Tuning（partition + buffer pool 互動）
• PostgreSQL Declarative Partitioning（PG sibling 對比）
• Partition 卡片
• 官方：MySQL Partitioning

本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明大表（> 1TB）需要 partitioning、本文聚焦 partition 真實價值在哪、為什麼多數人第一次 partition 都做錯。

Partition 不是「把大表切小」、是「讓 planner pruning + 縮小 maintenance scope」

剛開始學 partitioning 的人多半從「表太大、切小一點」直覺出發；切了之後發現 — query 變慢（planner 還在看所有 partition）、INSERT 變慢（trigger / partition routing overhead）、backup 沒變短（總資料量沒變）。直覺錯了：partition 的工程價值來自兩個機制、跟「切小」沒直接關係：

1. Query planner pruning：planner 在 planning 階段 跳過 不可能命中 partition key 的 partition、查詢只 scan 相關 partition；前提是 WHERE 條件含 partition key、否則 planner 看完所有 partition、效能反而比單表差
2. Maintenance scope 縮小：vacuum / index rebuild / DROP / archive 只動單一 partition、不掃整表；vacuum 12 小時變 30 分鐘 / DROP 老資料 0.01 秒、是 partition 真正回本的地方

partition 是 為了 maintenance 跟 planner pruning 設計、不是「表變小」設計。漏掉這個 framing、partition 配置會錯。

RANGE / LIST / HASH：partition 策略對應業務形狀

 1-- RANGE: 時間序列、log、event（最常見）
 2CREATE TABLE events (
 3  id bigint,
 4  event_time timestamptz NOT NULL,
 5  payload jsonb
 6) PARTITION BY RANGE (event_time);
 7
 8CREATE TABLE events_2026_05 PARTITION OF events
 9  FOR VALUES FROM ('2026-05-01') TO ('2026-06-01');
10
11-- LIST: tenant ID / region / status enum
12CREATE TABLE orders (
13  id bigint,
14  tenant_id int NOT NULL,
15  ...
16) PARTITION BY LIST (tenant_id);
17
18CREATE TABLE orders_tenant_premium PARTITION OF orders
19  FOR VALUES IN (1001, 1002, 1003);
20
21-- HASH: 均勻散落（無自然 partition key）
22CREATE TABLE users (
23  user_id bigint NOT NULL,
24  ...
25) PARTITION BY HASH (user_id);
26
27CREATE TABLE users_0 PARTITION OF users
28  FOR VALUES WITH (MODULUS 4, REMAINDER 0);

策略選擇關鍵：

• RANGE 適合 時間 / 有序值 — query 多半帶 WHERE event_time >= X、prune 效率最高；archive / drop 老資料是 DROP PARTITION 0.01 秒
• LIST 適合 離散 enum / tenant — query 帶 WHERE tenant_id = X prune；缺點是 tenant 增長要手動 ALTER ADD PARTITION
• HASH 適合 均勻分散、沒自然 key — query 多半 by-PK lookup、HASH 讓單 partition 大小均勻；prune 只在 WHERE hash_key = X 等值查詢觸發

選錯 partition key 是最常見的錯誤

例：events 表用 user_id HASH partition、但 query 多半 WHERE event_time BETWEEN ...、user_id 不在 WHERE — planner 沒法 prune、掃所有 partition、效能比單表更差（多了 partition routing overhead）。

partition key 必須 對應 query 最常用的 WHERE filter；錯了就退化成 維護面有好處、查詢面有壞處 的尷尬狀態。

Partition pruning：planner 怎麼決定跳過

1EXPLAIN (ANALYZE, BUFFERS)
2SELECT * FROM events
3WHERE event_time >= '2026-05-01' AND event_time < '2026-05-15';
4
5-- 期望輸出包含：
6--  Append (cost=...)
7--    -> Seq Scan on events_2026_05  (cost=...)
8-- (只 scan 一個 partition、其他 partition pruned)

pruning 觸發條件：

1. WHERE 含 partition key 的 constant expression（WHERE x = 5 觸發；WHERE x = some_function() 不觸發 planning-time prune、但 PG 11+ execution-time prune 可救）
2. PG 11+ 支援 execution-time pruning — query plan 內含 partition key、runtime 才知道值（prepared statement / NestedLoop join）
3. partition key 不在 WHERE 時 — 全部 partition 掃、是反指標、表示 partition strategy 不對

Partition-wise join / aggregate (PG 11+)

1SET enable_partitionwise_join = on;
2SET enable_partitionwise_aggregate = on;
3
4-- 兩個同 partition 策略的表 JOIN 時、planner 可 partition-wise 平行做
5SELECT * FROM events e JOIN events_metadata m
6  ON e.event_time = m.event_time
7  WHERE e.event_time >= '2026-05-01';

需要兩個表 partition strategy 完全一致（同 partition key + 同 partition boundary）— 設計時對齊、後期不容易調整。

Production 故障演練

Case 1：partition key 選錯，query 變慢

徵兆：partition 後特定查詢從 200ms 變成 2000ms；EXPLAIN 顯示 Append 下面所有 partition 都被 scan、沒 partition 被 prune。

根因：partition by user_id HASH、但 query 多用 WHERE created_at BETWEEN X AND Y；planner 不知道 user 在哪個 partition、必須掃全部。

修法：

1. 驗證 step：partition 前先 pg_stat_statements 看 top 10 query 的 WHERE pattern、partition key 必須對應其中 80% 流量的 filter
2. 修正：DROP partition strategy、改 partition by created_at RANGE；遷移用 pg_dump --section=data per-partition 重灌
3. 避免：partitioning 不可逆、設計階段 query pattern 沒看清楚不要動

Case 2：cross-partition unique constraint 不 enforce

徵兆：partition 後發現 application code 寫死 duplicate user_email、但 unique constraint 沒擋；DB 內有同 email 多筆。

根因：PostgreSQL partition table 的 UNIQUE constraint 必須包含 partition key — UNIQUE (email) 在 partition by tenant_id 的表上 無法 enforce（PostgreSQL 拒建）；workaround 用 UNIQUE (email, tenant_id)、但業務語意是「email 全域唯一」、PG 無法保證。

修法：

1. 架構：跨 partition 唯一性必須在 application 層 enforce（lock + check 模式）
2. 替代：用 non-partitioned 表存唯一性目標（user_email_registry）、做寫入前 lookup
3. 設計階段檢查：partition by X、unique constraint 必須含 X；若業務要求 unique 不含 X、partition strategy 錯

Case 3：ATTACH PARTITION 鎖表太久

徵兆：新 month partition ATTACH PARTITION 跑 30 秒、期間整個 events 表 read 阻塞、application timeout 大量。

根因：ATTACH PARTITION 預設加 ACCESS EXCLUSIVE lock 在 parent table、scan 整個新 partition 驗證 CHECK constraint；大 partition + 沒 CHECK constraint 預先驗證 → 鎖時間爆。

修法：

 1-- 1. 先把要 attach 的 partition 加 CHECK constraint，用 NOT VALID 不掃描
 2ALTER TABLE events_2026_06 ADD CONSTRAINT events_2026_06_range
 3  CHECK (event_time >= '2026-06-01' AND event_time < '2026-07-01') NOT VALID;
 4
 5-- 2. VALIDATE 用 SHARE UPDATE EXCLUSIVE lock、允許讀寫
 6ALTER TABLE events_2026_06 VALIDATE CONSTRAINT events_2026_06_range;
 7
 8-- 3. ATTACH 不再需要 scan（CHECK 已 VALIDATE 過）
 9ALTER TABLE events ATTACH PARTITION events_2026_06
10  FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');
11-- ATTACH 變 instant

Case 4：partition 數爆炸，planner planning time 爆

徵兆：partition 累積到 500+（daily partition 跑 1-2 年）、簡單 query EXPLAIN 顯示 planning_time 從 1ms 漲到 200ms、application response 變慢。

根因：partition 越多 planner 要評估的 partition 越多、即使有 pruning、planning 階段也要 walk 全部 partition table；500+ partition 是 planning overhead 明顯的閾值。

修法：

1. 架構：partition granularity 對應 retention — 不要 daily partition 留 2 年（→ weekly / monthly）
2. archive 老 partition：DETACH 老 partition、轉成 cold storage 表、planner 不再看
3. enable_partition_pruning 預設 on、確保啟用
4. PG 12+：planner 對 partition table 的 list 處理優化、planning time 上限拉高、但仍要控

Case 5：DETACH 後磁碟空間沒回收

徵兆：DETACH PARTITION 後 pg_database_size 沒下降、預期釋放 50GB；磁碟仍滿。

根因：DETACH 只是把 partition 從 parent table 分離、partition 自己仍是獨立表存在；要真釋放需要 DROP TABLE detached_partition。SRE 以為 DETACH = 刪掉。

修法：

1-- 完整流程
2ALTER TABLE events DETACH PARTITION events_2024_01;
3-- events_2024_01 仍存在、佔磁碟
4
5-- 確認沒 query 在用後
6DROP TABLE events_2024_01;
7-- 才釋放磁碟

Routine：archive workflow

1-- 月底跑：
2-- 1. detach 13 個月前的 partition
3ALTER TABLE events DETACH PARTITION events_2025_04;
4
5-- 2. dump 到 cold storage
6\COPY events_2025_04 TO '/cold/events_2025_04.csv' (FORMAT CSV);
7
8-- 3. drop 釋放磁碟
9DROP TABLE events_2025_04;

容量規劃

實務 default：

• 時間序列（events / log）：monthly RANGE partition、retention 12-24 個月
• Multi-tenant（orders / records）：tenant_id LIST partition + 大 tenant 各自獨立 partition
• 均勻散落（user / metric）：8-16 個 HASH partition、單 partition 50-100GB

整合 / 下一步

跟 autovacuum tuning 整合

partitioning 是 autovacuum 問題的長期解：

1. Hot partition autovacuum 緊（scale_factor 0.05、cost_limit 5000）
2. Cold partition autovacuum_enabled = false
3. 但 partition 數爆會把 autovacuum_max_workers 跑滿、需要拉

跟 index 設計整合

partition table 的 index 處理：

1. PG 11+ 全域 index：CREATE INDEX ON partitioned_table (...) 自動在每 partition 建 local index
2. 不存在跨 partition unique — 只能 partition-local
3. partition-wise index scan：PG 11+ 跟 partition-wise join 一起、index lookup 平行

跟 backup / PITR

partition 不是 backup 替代品 — 但能加速 partial restore：

1. 只 restore 特定時段的 partition、不用 restore 整個表
2. 對應 PITR + WAL archiving 的 partial recovery scenario

下一步議題

• Sub-partitioning：partition 內再 partition（時間 + tenant）、適合 multi-tenant + 時間序列
• pg_partman extension：自動建月 partition、不用 cron
• Foreign key to partitioned table (PG 12+)：跨 partition FK enforce、但 cascade 限制多

相關連結

• 上游 vendor 頁：PostgreSQL
• 上游 chapter：Schema Design — partition 是 schema 決策
• 平行 deep article：Patroni HA / autovacuum tuning / TimescaleDB Deep Dive（hypertable 是 partition 自動化）
• 後續路由：Partition Redesign（重排 partition strategy 的 migration playbook）
• Methodology：Vendor 深度技術文章的寫作方法論

本文的判讀錨點是：pg_partman 解決的是 partition lifecycle operation，而非 partition strategy 本身。Partition key、query pattern、retention、index、foreign key 與 migration 仍要先在 Declarative Partitioning 與 Partition Redesign 做對。

Responsibility Boundary

Responsibility boundary 的核心責任是區分 PostgreSQL 原生 partition 和 pg_partman。

pg_partman 的價值在於減少重複 DDL。它不會替 application 選出正確 partition key，也不會自動修復跨 partition query 設計。

Core Concepts

Core concepts 的核心責任是理解 pg_partman operation vocabulary。

Premake 是防止 insert 打到不存在 partition 的保護。若 partition 建立落後於時間，application insert 會失敗或落到 default partition；production 要對 future partition count 設 alert。

Retention 是資料生命週期操作。Drop 舊 partition 速度快，但要先確認 legal retention、backup、analytics dependency 與 downstream CDC。

Setup Pattern

Setup pattern 的核心責任是把 pg_partman 導入流程放進 migration gate。

1CREATE EXTENSION IF NOT EXISTS pg_partman;
2
3CREATE TABLE events (
4  id bigserial,
5  tenant_id uuid NOT NULL,
6  created_at timestamptz NOT NULL,
7  payload jsonb NOT NULL
8) PARTITION BY RANGE (created_at);

實際建立 partman config 要依 pg_partman 版本與 provider 支援文件執行。Managed PostgreSQL 可能限制 extension version、background worker 或 scheduler，因此 setup 前要先確認 provider boundary。

最小 setup evidence：

1. Extension version。
2. Parent table DDL。
3. Partition key 與 interval。
4. Premake 數量。
5. Retention policy。
6. Maintenance job schedule。
7. Test insert 到 current / future partition。

Maintenance Runbook

Maintenance runbook 的核心責任是讓 partition lifecycle 可觀測。

Maintenance job 要有 owner。Cron、pg_cron、background worker、Kubernetes job 或 managed scheduler 都可以；重點是 job failure 會告警，並且有人處理。

Migration and Backfill

Migration and backfill 的核心責任是把既有大表轉成 partman-managed partition。這通常比新表導入更高風險。

Backfill 要控制 WAL、replica lag、autovacuum、index bloat 與 lock。大型 table 應先用 shadow table 或 partition redesign playbook，避開 peak traffic 直接重建。

Failure Modes

Failure modes 的核心責任是列出 pg_partman 常見事故。

pg_partman 事故通常是 lifecycle 事故。Runbook 要先看 maintenance job，再看 partition metadata 與 application query。

下一步路由

pg_partman advanced 完成後，partition 設計讀 Declarative Partitioning；重排策略讀 Partition Redesign；migration gate 讀 Online Schema Change。