PostgreSQL 分区表与逻辑复制实战

概述

前文《PostgreSQL 高级查询：窗口函数、CTE 与递归查询》已经让读者领略了 PG 复杂数据分析的威力，而《PostgreSQL 索引深度：B-Tree、Hash、GIN、GiST 与 BRIN》则系统剖析了 BRIN 索引在时序数据上的极致空间效率。然而，当业务迈入海量数据时代，单表体积突破 TB 级，仅靠精妙的索引和查询优化器调优，已经难以对抗物理 I/O 与维护窗口的瓶颈。PostgreSQL 的声明式分区表提供了一套原生的数据分片方案，将大表物理拆分为多个独立小表，结合运行时分区裁剪和分区级聚合，实现"分而治之"的查询加速。与此同时，逻辑复制作为物理流复制在粒度与灵活度上的关键补充，支持在表级别进行细粒度、跨版本、可异构的数据同步，成为数据分发、零停机升级和数据湖集成的重要支柱。本文将正面拆解这些高级数据架构能力。

随着业务数据的持续增长，单表查询和维护的瓶颈日益明显。PostgreSQL 的声明式分区表正是应对这一挑战的利器：通过 RANGE、LIST、HASH 三种分区策略，将数据物理隔离到不同的分区中，查询时通过分区裁剪自动跳过无关分区，聚合时通过分区级并行加速统计。而逻辑复制则提供了灵活的表级别数据同步方案，让你可以在不同 PG 版本、不同数据库之间高效地分发数据。本文将逐层拆解分区表的内部实现、查询优化策略、分区维护操作，以及逻辑复制的架构原理、配置与监控，并结合与 MySQL 8.0 的深度差异对比，揭示 PG 在数据架构层面的设计哲学与工程权衡。

核心要点：

• 分区表演进 ：继承分区（PG 9.x）→ 声明式分区（PG 10+），涵盖 RANGE/LIST/HASH 三种策略。
• 查询优化：运行时分区裁剪、分区级聚合/连接、子分区多层级管理。
• 分区维护 ：ATTACH/DETACH 动态管理，分区索引策略与在线重建。
• 逻辑复制：Publication/Subscription 架构，WAL 逻辑解码原理，初始快照同步，冲突处理。
• 与 MySQL 8.0 差异：PG 物理分离的分区机制 vs MySQL 逻辑组织的分区；PG 表级 WAL 逻辑复制 vs MySQL 库级 Binlog 复制。

文章组织架构图：

flowchart TD 1["1. 表分区的演进：从继承到声明式"] 2["2. 声明式分区深度：RANGE、LIST 与 HASH"] 3["3. 分区表的查询优化与索引策略"] 4["4. 分区维护：ATTACH/DETACH 与子分区"] 5["5. 逻辑复制架构：Publication 与 Subscription"] 6["6. 逻辑复制实战：配置、监控与冲突处理"] 7["7. 与 MySQL 8.x 分区与复制的差异对比"] 8["8. 故障模拟：分区裁剪失效与逻辑复制延迟排查"] 9["9. 面试高频专题"] 1 --> 2 2 --> 3 3 --> 4 4 --> 5 5 --> 6 6 --> 7 7 --> 8 8 --> 9

架构图说明：

• 总览说明：全文 9 个模块严格遵循认知路径，从分区表的历史演进出发，逐步深入到三种声明式分区的内部机制、查询优化与维护实战，再转向逻辑复制的架构原理与工程落地，最后通过 MySQL 差异对比、故障模拟和面试专题形成闭环。
• 逐模块说明：模块 1-2 建立分区表的基础认知与演进脉络；模块 3-4 聚焦查询优化与在线维护的工程实践；模块 5-6 揭示逻辑复制的架构细节与端到端实战；模块 7 从数据库设计哲学进行本质对比；模块 8 通过故意制造故障加深理解；模块 9 系统性巩固核心概念。
• 关键结论 ：PostgreSQL 的声明式分区表实现了数据的"分而治之"，逻辑复制提供了灵活的表级别数据同步。理解分区裁剪、分区级聚合和逻辑复制的冲突处理，是驾驭大数据量场景下数据库架构设计的核心能力。

---

1. 表分区的演进：从继承到声明式

PostgreSQL 中的表分区并非一蹴而就的设计，它经历了一条从"手动模拟"到"原生声明式"的清晰演进路线。理解这条路线，有助于我们把握 PG 分区表在元数据管理、数据路由和约束语义上的设计意图。

1.1 继承分区：PG 10 之前的"手工"时代

在 PostgreSQL 10 之前，数据库内核并没有原生的分区支持。用户通过表继承（INHERITS）和 CHECK 约束的组合来模拟分区行为。

实现原理 ：首先创建一张父表，其本身不存储任何数据（或者可以不存储，仅作为模板），然后为每个期望的分区创建独立子表，通过 INHERITS 继承父表的结构。为了让优化器在查询时能够跳过无关分区，需要在每个子表上添加 CHECK 约束，以定义该分区所负责的数据范围，并设置 constraint_exclusion 参数为 partition（PG 9.2+ 默认）使优化器能利用这些约束进行分区排除。然而，数据在插入时，系统并不会根据 CHECK 约束自动将行路由到正确的子表，必须由应用或数据库端使用触发器或规则手动重定向 INSERT 语句。例如，一个按日期范围分区的日志表，需在每个子表上创建 BEFORE INSERT 触发器，判断 log_date 所属范围，如果属于本分区则插入，否则静默忽略，让下一个触发器继续尝试。

这种继承分区的复杂性体现在：

• 路由机制脆弱：触发器或规则的维护成本高，且容易因疏忽导致数据落入错误分区或直接插入父表。
• 元数据割裂：父表与子表的关联仅靠继承关系维护，主键、唯一约束和外部键只能定义在各子表上，无法在父表级别统一管理。
• 分区排除不稳定 ：constraint_exclusion 对 CHECK 约束的推导有时受限于表达式的形式，可能导致不必要的子表扫描。
• ALTER TABLE 操作沉重：添加新分区需要手动创建子表、继承关系，并更新路由触发器。

尽管如此，继承机制在内部系统表 pg_inherits 中记录继承链，优化器通过 expand_inherited_rtentry 生成 Append 路径时，会检查每个子表的约束进行裁剪。这在 MVCC 层面上与常规表无异，每个子表拥有自己独立的 relfilenode 物理文件，VACUUM 机制也是分区独立运作的（详见系列第 6 篇）。这种物理独立性一直是 PG 分区实现相比 MySQL 分区的核心差异之一。

1.2 声明式分区：PG 10 的革命性变化

PostgreSQL 10 引入了声明式分区（Declarative Partitioning），其核心思想是让用户只需声明分区策略，内核自动完成数据路由和分区维护操作。语法以 CREATE TABLE ... PARTITION BY 为标志，彻底告别了触发器与手动继承。

革命性变化包括：

• 原生路由 ：INSERT/UPDATE 操作直接由执行器中的 ExecInsert/ExecUpdate 利用分区路由元数据自动定位目标分区，无需任何触发器。
• PARTITION BY 语法 ：支持 RANGE、LIST 和 HASH 三种策略，DDL 语义清晰。
• DEFAULT 分区 ：当新数据不匹配任何已有分区的边界时，可以落入 DEFAULT 分区（PG 11 引入），避免了数据丢失或报错，极大方便了边缘数据管理。
• 分区排除确定性 ：优化器使用分区系统的内建元数据表 pg_partitioned_table 和 pg_partition_tree() 等函数，直接获取分区边界，执行运行时分区裁剪（详见第 3 章），比传统 CHECK 约束推导更可靠、更高效。
• 子分区支持 ：PG 11 起支持多层级分区，可在任何一层再进行 PARTITION BY，形成复合分区树。

声明式分区的底层实现仍然保留了每个分区作为独立物理表（拥有自己的 relfilenode）的传统，这意味着：

• 每个分区可独立进行索引构建和 VACUUM 维护，互不干扰。
• 继承了 PG 的 MVCC 模型，各分区内部的行锁、可见性判断与普通表无异。
• 可和 BRIN、GIN 等高级索引结合，如在时序分区上为每个分区单独创建 BRIN 索引，获得极致的空间效率（详见系列第 5 篇索引深度）。

1.3 从继承到声明式的迁移考量

已经使用继承分区的系统，可以通过如下安全路径迁移到声明式分区：使用 CREATE TABLE new_partitioned_table ... PARTITION BY，然后依次用 ATTACH PARTITION 将原来的子表附加为分区。由于 ATTACH 只是元数据操作，且在附加时会校验 CHECK 约束与分区边界的匹配性，该过程需要短暂的 ACCESS EXCLUSIVE 锁，但实际数据移动为零。

1.4 分区表物理存储结构图

flowchart TD Parent["父表（分区表）
relfilenode: 0（不存数据）"] Part1["分区1：orders_2024_q1
relfilenode: 16384
物理文件：base/16400/16384"] Part2["分区2：orders_2024_q2
relfilenode: 16385
物理文件：base/16400/16385"] Part3["分区N：orders_2024_qn
relfilenode: 16386
物理文件：base/16400/16386"] SysMeta["系统元数据：pg_partitioned_table
记录分区层级与边界"] Parent -- "分区映射" --> Part1 Parent -- "分区映射" --> Part2 Parent -- "分区映射" --> Part3 SysMeta --> Parent

• 图表主旨概括：展示声明式分区表在 PG 中的物理存储结构，父表仅作为逻辑入口，每个分区拥有独立的物理文件。
• 逐层/逐元素分解 ：父表不存储实际数据，其 relfilenode 通常为 0（或指向一个空文件）；分区1、分区2、分区N各自对应独立的 relfilenode，物理上完全隔离。系统元数据表 pg_partitioned_table 记录分区表的分区策略、分区键和边界信息。
• 设计原理映射：这体现了声明式分区"物理分离"的设计哲学，使得每个分区的 VACUUM、索引重建、备份恢复都可以独立执行，避免了全表锁冲突。同时也延续了 PG 的每表独立物理存储模型，与一般的堆表无异。
• 工程联系与关键结论 ：物理分离意味着当某个分区的数据膨胀或索引损坏时，仅仅影响该分区，我们可以单独针对该分区执行 REINDEX 或 VACUUM FULL，而不影响其他分区的读写。这与 MySQL 将分区作为同一个表空间内的逻辑组织形成鲜明对比，后者无法做到独立物理维护。

---

2. 声明式分区深度：RANGE、LIST 与 HASH

PostgreSQL 16.x 支持的声明式分区具备三种基本策略和复合子分区能力，能够覆盖绝大多数数据分片场景。

2.1 RANGE 分区

RANGE 分区按连续值范围（如时间、ID 范围）划分数据，是最常见的分区形式，天然适合基于时间的归档和范围查询。

创建示例：

-- 创建按订单日期分区的订单表
CREATE TABLE orders (
    order_id      BIGINT NOT NULL,
    customer_id   INT,
    order_date    DATE NOT NULL,
    total_amount  DECIMAL(12,2)
) PARTITION BY RANGE (order_date);

-- 创建月度分区
CREATE TABLE orders_2024_01 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

CREATE TABLE orders_2024_02 PARTITION OF orders
    FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

-- 创建默认分区，捕获超出范围的数据
CREATE TABLE orders_default PARTITION OF orders DEFAULT;

• 逐行解读 ：父表 orders 通过 PARTITION BY RANGE(order_date) 声明分区策略；分区 orders_2024_01 通过 FOR VALUES FROM ... TO ... 定义左闭右开区间；DEFAULT 分区用于存储所有不落在已定义范围的 order_date 行，避免插入失败。
• 适用场景 ：时序数据、按日期归档，大部分查询带有范围条件（WHERE order_date BETWEEN ...）。

查询示例与裁剪验证：

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT * FROM orders WHERE order_date = '2024-01-15';

输出中会包含 Subplans Removed: N 或仅扫描 orders_2024_01 的信息，证明其他分区被裁剪。当 enable_partition_pruning=on 时，优化器在计划阶段即可移除无关分区，执行器也只扫描目标分区。

2.2 LIST 分区

LIST 分区按离散值列表（如地域、状态、租户 ID）分区，便于分类管理。

CREATE TABLE customer_events (
    event_id    BIGINT NOT NULL,
    region      TEXT NOT NULL,
    event_data  JSONB
) PARTITION BY LIST (region);

CREATE TABLE events_us PARTITION OF customer_events
    FOR VALUES IN ('US', 'CA');

CREATE TABLE events_eu PARTITION OF customer_events
    FOR VALUES IN ('DE', 'FR', 'UK');

CREATE TABLE events_other PARTITION OF customer_events DEFAULT;

• 要点 ：FOR VALUES IN (...) 明确规定该分区存储的离散值集合；当插入 region = 'JP' 时，若无其他分区匹配，则落入 events_other。
• 适用场景：按固定分类维度隔离数据，例如多租户系统的租户 ID 列表，或区域报表。

2.3 HASH 分区

HASH 分区通过对分区键进行内部哈希，将数据均匀分布到指定数量的分区，避免写入热点。

CREATE TABLE sensor_readings (
    sensor_id   INT NOT NULL,
    measured_at TIMESTAMPTZ NOT NULL,
    value       DOUBLE PRECISION
) PARTITION BY HASH (sensor_id);

-- 创建 4 个哈希分区
CREATE TABLE readings_p0 PARTITION OF sensor_readings
    FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE readings_p1 PARTITION OF sensor_readings
    FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE readings_p2 PARTITION OF sensor_readings
    FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE readings_p3 PARTITION OF sensor_readings
    FOR VALUES WITH (MODULUS 4, REMAINDER 3);

MODULUS 为总分区数，REMAINDER 为当前分区对应的余数，所有分区等分哈希空间。PG 使用 hash_any 函数族计算。哈希分区不保证数据的局部性，但写入分布均匀。

2.4 子分区（Sub-Partitioning）

复杂场景可以将多种策略组合，实现多层级分区。

CREATE TABLE orders (
    order_id    BIGINT,
    region      TEXT NOT NULL,
    order_date  DATE NOT NULL,
    amount      DECIMAL
) PARTITION BY RANGE (order_date);

-- 一级分区：按日期
CREATE TABLE orders_2024 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01')
    PARTITION BY LIST (region);

-- 二级分区：在日期分区内按地区
CREATE TABLE orders_2024_us PARTITION OF orders_2024
    FOR VALUES IN ('US', 'CA');
CREATE TABLE orders_2024_eu PARTITION OF orders_2024
    FOR VALUES IN ('DE', 'FR');

这种结构能够同时利用时间的范围裁剪和地区的精确匹配，但需要留意：随着层级增加，分区总数呈乘积式膨胀，元数据开销和维护复杂度会显著上升。一个合理的分区总数（一般建议数千以内）和恰当的层级设计至关重要。

---

3. 分区表的查询优化与索引策略

分区表查询优化的核心在于"减"------减少扫描的分区数量，并在单个分区上尽可能并行。PostgreSQL 提供了三个关键的优化器开关，用于控制分区级优化行为。

3.1 运行时分区裁剪

参数 enable_partition_pruning（默认 on）控制优化器是否在计划时和运行时排除不相关分区。裁剪发生在两个阶段：

• 计划时静态裁剪 ：当 WHERE 条件包含常量（如 order_date = '2024-03-15'），优化器直接利用分区边界元数据移除不可能包含目标数据的分区。
• 运行时裁剪 ：当过滤条件包含参数化变量（如 $1、函数结果或来自外表的连接列），优化器生成一个可在执行时动态选择分区的 Append 节点，执行器在获得具体值后即时裁剪。

验证示例：准备分区表并插入数据后，执行：

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT * FROM orders WHERE order_date BETWEEN '2024-01-10' AND '2024-01-20';

观察计划中仅出现 orders_2024_01 的扫描。若设置 SET enable_partition_pruning = off;，则计划会扫描所有分区，Subplans Removed 消失，总执行时间显著增加。

内幕 ：在优化器内部，分区表被展开为一组 RelOptInfo，生成路径时由 set_append_rel_pathlist 调用 prune_append_rel_partitions，该函数使用分区键上的基数估算和 PartClauseInfo 结构决定保留哪些分区。最终构建的 AppendPath 或 MergeAppendPath 只包含存活的分区。

3.2 分区级聚合与连接

参数 enable_partitionwise_aggregate（PG 11+）和 enable_partitionwise_join（PG 12+）控制是否按分区执行聚合或连接。

• 分区级聚合 ：对于 GROUP BY 包含分区键的场景，优化器可以将每个分区先进行局部聚合，再在上层汇总。这样可利用分区独立、并行的特性加速，减少最终归并的数据量。示例：

SET enable_partitionwise_aggregate = on;
EXPLAIN (ANALYZE) SELECT region, sum(amount) FROM orders GROUP BY region;

每个分区内部先对 region 做局部聚合，然后 Append 汇总，最后 HashAggregate。如果关闭该参数，则所有分区的数据汇集后一次性聚合，可能引发大量内存使用。

• 分区级连接 ：当两个分区表以相同的分区策略进行连接（例如两个按相同 sensor_id 哈希分区的表），优化器可以逐分区执行连接，避免全表连接。这要求两个表的分区树完全一致。

3.3 分区表的索引约束

全局唯一索引的限制 ：PG 不存在全局索引的概念。分区表上的唯一索引（以及唯一约束、主键）必须包含所有分区列。例如 UNIQUE(order_id) 在分区表上是不允许的，因为无法保证跨分区唯一性，除非唯一索引列就是分区键本身（或其超集）。若业务需要全局唯一 order_id，而不想使其成为分区键，有两种替代方案：

• 使用应用程序生成的全局唯一 ID（UUID 或雪花 ID），依赖极小概率碰撞。
• 维护一张单独的全局唯一序列表，但失去数据物理隔离性。

分区索引的独立膨胀管理：每个分区可以独立创建本地索引，强烈建议为每个分区单独创建索引而非使用全局索引，因为这延续了物理隔离的哲学。索引膨胀监控与 VACUUM 也可按分区粒度进行。例如：

CREATE INDEX ON orders_2024_01 (customer_id);

然后通过 pg_stat_user_tables 和 pgstattuple 扩展监控该分区索引膨胀，并执行 REINDEX (VERBOSE) INDEX idx_name 重建。

在线重建分区索引 ：PG 12 引入 REINDEX CONCURRENTLY，允许在不长时间阻塞写操作的情况下重建索引。

REINDEX INDEX CONCURRENTLY idx_orders_2024_01_customer_id;

该命令采用创建新索引、交换旧索引、等待旧事务结束并清理的复杂流程，对生产环境非常友好。值得注意的是，REINDEX CONCURRENTLY 也可对分区表父表执行，它会递归处理所有分区索引，但实际执行仍是分区独立完成的。

3.4 分区裁剪 vs 全表扫描对比图

flowchart TB Query["查询: WHERE order_date = '2024-01-10'"] OptON["enable_partition_pruning = on"] OptOFF["enable_partition_pruning = off"] Query --> OptON OptON --> Eliminate["优化器裁剪分区
仅保留 orders_2024_01"] Eliminate --> Scan1["顺序扫描 orders_2024_01"] Scan1 --> Result["快速返回结果"] Query --> OptOFF OptOFF --> AllParts["扫描所有分区
orders_2024_01, orders_2024_02, ..."] AllParts --> ScanAll["顺序扫描所有分区"] ScanAll --> Result2["慢速返回结果"]

• 图表主旨概括 ：对比启闭 enable_partition_pruning 时，同一个查询的执行路径差异，直观显示裁剪的意义。
• 逐层/逐元素分解 ：输入查询带有对分区键的等值条件；当 enable_partition_pruning=on 时，优化器直接移除其他分区，仅扫描目标分区；关闭时，Append 节点会扫描所有分区，即便有条件硬过滤也会浪费大量 I/O。
• 设计原理映射：分区裁剪利用了分区边界的元数据，结合优化器的约束推导能力，本质上是一种多表查询下推过滤器。
• 工程联系与关键结论 ：保留 enable_partition_pruning=on 是生产环境的基线配置；当发现某类查询意外慢速时，首要检查是否发生了意外的分区全扫描，可能是查询条件未使用分区键，或函数包裹导致表达式非 sargable。

---

4. 分区维护：ATTACH/DETACH 与子分区

声明式分区提供了一套强大的在线分区维护命令，使得数据生命周期管理（如归档、旋转）对应用透明。

4.1 ATTACH PARTITION 在线附加

可以将一张独立存在的表附加为分区表的某个分区，前提是该表满足分区边界约束（当不存在 DEFAULT 分区时，附加前会进行 CHECK 约束验证）。操作只需要短暂的 ACCESS EXCLUSIVE 锁，期间不复制数据。

-- 事先创建好独立表，结构与分区表一致，并填充数据
CREATE TABLE orders_2024_03 (LIKE orders INCLUDING ALL);
INSERT INTO orders_2024_03 SELECT * FROM staging WHERE order_date BETWEEN '2024-03-01' AND '2024-03-31';

-- 在线附加为分区
ALTER TABLE orders ATTACH PARTITION orders_2024_03
    FOR VALUES FROM ('2024-03-01') TO ('2024-04-01');

ATTACH 的内部行为：

• 在 pg_partitioned_table 中记录新分区边界。
• 验证表中所有行都满足边界（若事先有 CHECK 约束可减少验证开销）。
• 更新分区路由信息，后续 DML 立即生效。

工程实践 ：经常用于数据归档流程：将过期的分区从主表 DETACH 后压缩备份，或将新预填充的月份数据作为分区 ATTACH。

4.2 DETACH PARTITION 在线解除

DETACH PARTITION 将指定分区变为一张独立普通表，数据仍在原处，不受任何删除。

ALTER TABLE orders DETACH PARTITION orders_2024_01;
-- 此后 orders_2024_01 为独立表，可以单独导出、备份或删除

此操作通常与归档策略结合：先 DETACH，然后对该表执行 pg_dump 并行备份，最后 DROP TABLE。全程不会阻塞主分区表上的查询。

4.3 分区表的 VACUUM 与 ANALYZE

由于各分区物理独立，可以对单个分区执行 VACUUM 或 ANALYZE，无需担心全表锁。例如：

VACUUM (ANALYZE, VERBOSE) orders_2024_01;

这对大表十分关键：每日仅对新写入的分区执行 ANALYZE 以更新统计信息，老分区可降低维护频率。此外，autovacuum 也是按分区表独立触发的，避免了全局长时间阻塞。

4.4 分区增删对应用的透明性

应用代码可使用分区表主表名进行所有操作，路由完全在服务器端完成。添加新分区后，新数据自动写入；解除分区后，查询不再扫描该分区，实现了平滑的数据生命周期管理。

---

5. 逻辑复制架构：Publication 与 Subscription

物理流复制将 WAL 二进制流从一个主库同步到一个或多个备库，复制的是整个集群的底层变更，无法进行表级筛选。逻辑复制正是为了填补这一空白而生，允许细粒度地复制指定表的逻辑变更（INSERT、UPDATE、DELETE）。

5.1 逻辑复制的 WAL 解码原理

逻辑复制需要将 WAL 中的物理页变更反向解析为高层次的行更改。这由以下组件协作完成：

• wal_level = logical ：必须在源端设置，使 WAL 日志包含逻辑解码所需的足够信息（例如行的旧值和新值，取决于 REPLICA IDENTITY）。
• REPLICA IDENTITY ：定义了在 UPDATE 和 DELETE 时记录哪些旧值用于构建复制标识。默认使用主键（DEFAULT，若存在），若表无主键，可选 USING INDEX 或 FULL（记录整行旧值，开销大）。
• 逻辑解码插件（pgoutput）：作为 WAL 和 Publication 之间的适配层，将解码后的变更封装成逻辑复制协议消息，发送给订阅端。
• Publication：定义哪些表的哪些操作需要被发布。
• WAL Sender：进程使用复制连接将逻辑增量流推送给订阅端的 Apply Worker。

整个逻辑复制建立在 MVCC 快照之上：初始同步阶段，订阅端获取源库的一致性快照进行数据拷贝；之后增量的 WAL 解码从快照 LSN 之后开始应用。

5.2 Publication 的创建与管理

-- 创建发布，发布 orders 表的 INSERT, UPDATE, DELETE
CREATE PUBLICATION pub_orders FOR TABLE orders
    WITH (publish = 'insert,update,delete');
-- 添加更多表
ALTER PUBLICATION pub_orders ADD TABLE customers;
-- 查看所有发布
SELECT * FROM pg_publication;

发布可以针对特定操作类型，甚至只发布 INSERT。FOR ALL TABLES 则发布数据库中所有表的变更。

5.3 Subscription 的创建与管理

-- 在目标库创建订阅，指定连接信息和发布的名称
CREATE SUBSCRIPTION sub_orders
    CONNECTION 'host=source_host dbname=sourcedb user=repuser password=secret'
    PUBLICATION pub_orders
    WITH (enabled = true, create_slot = true, copy_data = true);

• copy_data 默认 true，表示创建时立即从源库快照同步现有数据。
• 后面的增量更改自动应用。
• 可通过 ALTER SUBSCRIPTION ... DISABLE 暂停，ENABLE 恢复。
• REFRESH SUBSCRIPTION 用于在 Publisher 端添加了新表后手动刷新。

5.4 初始快照同步的内部流程

初始快照同步是逻辑复制保证数据一致性的核心步骤。其内部流程序列如下图所示。

sequenceDiagram participant Sub as Subscription端 participant Pub as Publication端(WAL Sender) participant Snap as 源库快照 Sub->>Pub: CREATE SUBSCRIPTION (copy_data=true) Pub->>Snap: 开启可重复读事务，获取快照 Pub-->>Sub: 发送表结构信息 loop 每个表 Pub->>Pub: 导出快照数据 (COPY) Pub-->>Sub: 传输表数据 end Pub->>Pub: 记录快照结束LSN Pub-->>Sub: 进入增量同步模式，从该LSN发送WAL

• 图表主旨概括：描绘首次创建订阅时，源端如何利用快照导出存量数据并平滑过渡到增量 WAL 流，保证不丢一条变更。
• 逐层/逐元素分解 ：订阅端发起请求，源端开启一个可重复读事务（快照），然后通过类似 COPY 的机制将数据批量输送；快照期间源端发生的 WAL 变更被缓存在逻辑复制槽中；快照完成后，Apply Worker 从精确的快照结束 LSN 开始应用 WAL，实现数据无缝衔接。
• 设计原理映射：依赖 MVCC 提供的快照隔离能力，保证初始副本一致性；逻辑复制槽防止所需 WAL 被清理，直到订阅端消费完毕。
• 工程联系与关键结论 ：如果订阅端创建时 copy_data=true 但源表数据巨大，初始同步可能耗时较长，期间源库需保留足够 WAL（通过 max_slot_wal_keep_size 限制）。此外，务必监控复制槽的 WAL 积压，以防主库磁盘耗尽。这就是逻辑复制在生产中需严密监控的根源。

5.5 逻辑复制架构全景图

flowchart LR Client["客户端写入"] --> Src["源库实例
wal_level=logical"] Src --> WAL["WAL 日志"] WAL --> Decoder["逻辑解码插件
(pgoutput)"] Decoder --> Pub["Publication
pub_orders"] Pub --> WALSender["WAL Sender 进程"] WALSender -- "逻辑复制协议
（TCP）" --> ApplyWorker["Apply Worker
（订阅端）"] ApplyWorker --> Dst["目标库实例
Subscription sub_orders"]

• 图表主旨概括：宏观展示逻辑复制的组件与数据流，从源库写入直到目标库回放。
• 逐层/逐元素分解：客户端写入触发 WAL 生成；逻辑解码器从 WAL 中提取逻辑变更消息；Publication 过滤出需要发布的消息；WAL Sender 通过复制协议将消息流式传输；目标库的 Apply Worker 接收并按照事务边界应用修改。
• 设计原理映射：采用生产者-消费者模型，复制槽作为缓冲协调；解码插件化设计使 PG 可以支持多版本输出格式，也便于第三方集成。
• 工程联系与关键结论 ：逻辑复制是纯数据层的异步复制，默认复制冲突不自动解决，必须以应用设计预防或结合触发器处理。理解其异步本质对于设计最终一致性系统至关重要。

---

6. 逻辑复制实战：配置、监控与冲突处理

6.1 完整 Pub/Sub 搭建步骤

源端配置（postgresql.conf 调整）：

wal_level = logical
max_replication_slots = 5
max_wal_senders = 5

重启后创建复制用户并授权：

CREATE USER repuser REPLICATION LOGIN CONNECTION LIMIT 5 PASSWORD 'secret';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO repuser;

创建发布：

CREATE PUBLICATION pub_orders FOR TABLE orders, customers;

目标端创建订阅：

CREATE SUBSCRIPTION sub_orders
    CONNECTION 'host=192.168.1.100 dbname=sourcedb user=repuser password=secret'
    PUBLICATION pub_orders;

随后数据开始同步，可在目标库查询确认行数。

6.2 监控延迟与错误

PG 16 提供了 pg_stat_subscription_stats 视图，显示每个订阅的统计信息。

SELECT subname,
       apply_error_count,
       latest_error_time,
       latest_error_message,
       total_lag,
       last_msg_send_time
FROM pg_stat_subscription_stats;

total_lag 标识订阅端应用延迟，有助于判断复制是否滞后。apply_error_count > 0 表示存在冲突导致应用暂停。

6.3 常见冲突场景与处理方案

逻辑复制最常见的冲突是：

• 主键冲突：目标端已存在与源端推送相同主键的行（可能由其他写入或误操作导致）。
• 更新缺失行：源端更新了一行，但目标端找不到该行（可能被手动删除）。

处理策略：

• 在源端预防：确保写入逻辑不会在不同分片写入相同主键，例如采用 UUID 或全局唯一序列。
• 在订阅端跳过冲突事务：ALTER SUBSCRIPTION ... SKIP (lsn = 'xxx'); 跳过失败事务，跳过一行，但可能导致数据不一致，需谨慎。
• 使用触发器：在订阅端为表创建 BEFORE INSERT OR UPDATE OR DELETE 触发器，对冲突进行自定义处理（如将冲突行记录到日志表，并返回 TG_OP='SKIP' 等）。

6.4 跨版本升级应用

逻辑复制提供了一种零停机将 PG 14 升级至 PG 16 的途径：在 PG 16 新实例创建订阅，指向旧库的发布，数据同步完成后，应用切换连接到新库即可。由于逻辑复制是表级的且可跨版本，这种方式比物理复制升级（需要大版本二进制兼容）更灵活。

---

7. 与 MySQL 8.x 分区与复制的差异对比

7.1 分区实现对比

特性	PostgreSQL 声明式分区	MySQL 8.0 原生分区
存储模型	每个分区为独立的物理表（独立文件）	所有分区共享同一表空间（一个 .ibd 文件或各分区 .ibd ），但本质属于同一表
分区路由	内核执行器自动路由	服务器层通过分区函数路由
全局索引	不支持全局唯一索引（除非索引含分区键）	不支持全局索引（仅本地索引）
DEFAULT 分区	支持	不支持（插入不匹配值直接报错）
分区维护	ATTACH/DETACH 在线附加/解除，操作更快	REORGANIZE PARTITION, REBUILD PARTITION 等，通常需要重建数据
子分区	支持多层嵌套	支持子分区（组合分区），但语法不同
技术核心	基于表继承与物理隔离	分区是存储引擎的一个特性，分区表视为一个逻辑表

关键差异：PG 的物理独立意味着每个分区可以拥有自己的索引策略、独立的 VACUUM，适合大数据归档；而 MySQL 的分区则倾向于使用统一的表空间和存储引擎特性，分区更多是逻辑上的划分，缺乏独立物理维护的能力。

7.2 复制机制对比

特性	PostgreSQL 逻辑复制	MySQL 8.0 Binlog 复制（Row 模式）
复制粒度	表级别（Publication 可指定部分表）	实例级别或库级别（使用过滤器）
同步原理	基于 WAL 逻辑解码，输出行变更	基于 Binlog 的 ROW/STATEMENT/MIXED 事件
DDL 复制	不支持（需手动同步 DDL）	支持（可选），但 GTID 下部分 DDL 复制有坑
过滤灵活性	Publication 可精确到表及操作类型	通过 replicate-do-table 等过滤，库级限制大
复制槽	有逻辑复制槽，防止 WAL 清理	无等效概念，依赖 Binlog 过期策略
冲突处理	停止并报错，需手动跳过	SQL 线程停止，需 slave_skip_errors 或手动注入空事务

架构哲学：PG 的逻辑复制强调表级别的精细化复制，追求最小传输量和灵活性；MySQL 的 Binlog 复制根植于其传统的主从架构，偏向于全库一致性复制，粒度较粗。

PG ATTACH/DETACH 与 MySQL 分区维护对比 ：在 PG 中附加新分区几乎瞬间完成，无需移动数据；而在 MySQL 中，REORGANIZE PARTITION 往往伴随着数据重分布，需要更长时间的锁和 I/O。同样，解除分区 PG 能立即独立，而 MySQL 必须通过 EXCHANGE PARTITION 与普通表交换数据。

---

8. 故障模拟：分区裁剪失效与逻辑复制延迟排查

理解分区表与逻辑复制的工作机制后，通过人为制造故障来观察系统行为，是加深认知的最佳途径。本章精心设计两个高频故障场景，逐步演示问题复现、根因定位与修复策略。

8.1 故障一：分区裁剪失效导致全表扫描

故障机制 ：分区裁剪由参数 enable_partition_pruning 控制，默认开启。一旦该参数被意外关闭，或者查询条件对分区键施加了非 sargable 的表达式，优化器将被迫扫描所有分区，执行性能出现数量级衰退。

场景模拟 ：假设 orders 表已按 order_date 创建月度分区，并灌入数月数据。在正常状态下，执行一个只命中单月的查询：

-- 正常裁剪情形
SET enable_partition_pruning = on;
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, SUMMARY OFF)
SELECT * FROM orders
WHERE order_date BETWEEN '2024-03-01' AND '2024-03-15';

输出中仅出现 orders_2024_03 分区的 Sequential Scan（或 Index Scan），Subplans Removed 为其余分区的数量，执行时间通常在毫秒级别。

模拟故障：在同一会话中关闭分区裁剪：

SET enable_partition_pruning = off;
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, SUMMARY OFF)
SELECT * FROM orders
WHERE order_date BETWEEN '2024-03-01' AND '2024-03-15';

此时计划节点中出现 Append 展开所有分区，每个分区均被执行一次顺序扫描，Subplans Removed 变为 0，实际执行时间可能放大数十倍甚至上百倍。EXPLAIN (ANALYZE, SETTINGS) 输出中亦会标记 enable_partition_pruning: off。

根因定位：

• 参数级原因 ：enable_partition_pruning 可以在 postgresql.conf、数据库级或会话级关闭。排查时需检查 SHOW enable_partition_pruning 的结果，并核对是否有用户在连接初始化时执行了 SET 命令。
• 表达式级原因 ：即使参数开启，若 WHERE 条件中使用了函数包裹分区键，如在 order_date 上使用 date_trunc('month', order_date) = '2024-03-01'，优化器通常无法推导出有效的分区边界。可通过 EXPLAIN 确认是否依然触发了 Append 全分区扫描。
• 统计信息级原因 ：若某个分区的 pg_class.reltuples 统计信息丢失或严重不准，优化器可能对裁剪后的代价产生误判，但通常不会直接恢复全分区扫描------这往往还需结合其他因素。

修复方案：

• 确保 enable_partition_pruning = on（除非在极特殊的查询场景下，确信全分区扫描比裁剪开销更低，这在日常几乎不存在）。
• 重构查询，使分区键直接与常量进行简单比较，避免函数包裹。对于必须使用函数的场景，可考虑生成列（Generated Column）并以此为分区键。
• 保持分区统计信息及时更新：ANALYZE orders_2024_03;。

源码视角 ：优化器在 allpaths.c 中调用 set_append_rel_pathlist()，其中会检查 enable_partition_pruning，若为 false，则跳过 prune_append_rel_partitions()，所有分区进入 Append 路径。prune_append_rel_partitions() 内部使用 get_append_rel_partitions() 依据 PartClauseInfo 过滤无效分区。

8.2 故障二：逻辑复制延迟过大与冲突中断

故障机制：逻辑复制由于是异步跨进程解码与传输，天然存在一定延迟，但当延迟突破秒级甚至分钟级时，往往暗示着瓶颈存在。此外，订阅端一旦遇到主键冲突或行更新缺失，应用进程会立即停止，导致复制中断。

故障场景一：延迟持续增大

模拟方法：在发布端开启一个大事务，对已发布的表进行大量更新但不提交，同时持续插入数据。此时 WAL 日志会快速累积，逻辑解码插件需要解析大量未提交事务，而订阅端无法应用这些未完成的数据。

排查步骤：

1. 订阅端查询 pg_stat_subscription_stats：

SELECT subname, total_lag, last_msg_send_time, last_msg_receipt_time
FROM pg_stat_subscription_stats;

total_lag 显著增大且持续增长。

2. 源库检查 pg_stat_replication：

SELECT pid, application_name, state, write_lag, flush_lag, replay_lag, reply_time
FROM pg_stat_replication WHERE application_name = 'sub_orders';

观察 write_lag、flush_lag、replay_lag 的数值，判断瓶颈在 WAL 发送、写入还是回放阶段。

3. 查看源库逻辑复制槽：

SELECT slot_name, slot_type, active, restart_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag_size
FROM pg_replication_slots WHERE slot_type = 'logical';

lag_size 反映了未被订阅端消费的 WAL 积压量，若持续增大，说明 Apply Worker 处理速度跟不上。

根因分析：

• 大事务：长事务或未提交事务使得 WAL 无法被消费端应用（逻辑复制必须等待事务提交），同时阻塞 WAL 清理。
• REPLICA IDENTITY FULL ：对于无主键表，设置了 REPLICA IDENTITY FULL，每次 UPDATE/DELETE 都会将整行旧值写入 WAL，解码后产生巨大消息量，加重网络与订阅端负担。
• 订阅端处理能力：Apply Worker 在目标库上执行 SQL 的效率受限于目标库的 CPU、IO 速度、索引质量和并发写入冲突。
• 网络瓶颈：跨数据中心高延迟或低带宽导致发布端 WAL Sender 发送速率受限。

修复策略：

• 避免发布端出现长时间未提交的大事务；拆分大批量更新为小批量并频繁提交。
• 为所有参与逻辑复制的表设定合适的主键或唯一索引，将 REPLICA IDENTITY 设置为 DEFAULT，避免 FULL。若业务需要无主键表复制，考虑添加自增 id 并创建唯一索引。
• 提升订阅端硬件资源，确保 Apply Worker 的写入不被阻塞；必要时可增加 max_sync_workers_per_subscription 并启用并行 apply，但每个表只能由一个 apply worker 处理以保证事务顺序。
• 使用 ALTER SUBSCRIPTION ... SET (streaming = 'parallel')（PG 14+）开启流式传输与并行应用，进一步降低延迟。
• 监控并调整 max_slot_wal_keep_size 防止复制槽无限膨胀占满磁盘。

故障场景二：复制冲突导致中断

冲突表现：订阅端应用进程停滞，pg_stat_subscription_stats 中 last_error_message 包含类似错误：

ERROR: duplicate key value violates unique constraint "orders_pkey"
DETAIL: Key (order_id)=(12345) already exists.

模拟方法：

• 发布端插入一条 order_id=12345 的行并提交，订阅端正常同步。
• 手动在订阅端再次插入同样 order_id 的行（模拟其他写入通道或应用错误），导致唯一索引冲突。
• 发布端再次更新该行，订阅端尝试应用时触发冲突，同步停止。

手动修复步骤：

1. 确认故障事务的 LSN：SELECT * FROM pg_stat_subscription_stats WHERE subname = 'sub_orders'; 可读到错误信息及关联 LSN。
2. 查看冲突行的具体数据：

SELECT * FROM orders WHERE order_id = 12345;

评估目标端该行与源库的差异（可通过查询源库或解析 WAL）。

3. 若确定目标端多余行可以删除：

DELETE FROM orders WHERE order_id = 12345 AND /* 仅目标端添加的标识条件 */;

或更新为与源端一致的值，使后续应用能继续。

4. 通知订阅跳过该失败事务：

ALTER SUBSCRIPTION sub_orders SKIP (lsn = 'xxx/xxx');

SKIP 会跳过当前失败的事务，订阅从下一个开始继续。注意被跳过的数据将永久丢失本次变更，需后续补偿。

5. 重新启用订阅：

ALTER SUBSCRIPTION sub_orders ENABLE;

自动预防：理想状态下，逻辑复制的架构应该避免此类冲突。措施包括：

• 源端与目标端严格分离写入职责，订阅端表只读。
• 若目标端有填充初始化数据的需要，应在订阅创建完毕之前完成，或使用 copy_data = true 的订阅初始化。
• 在订阅端创建 BEFORE INSERT OR UPDATE OR DELETE 触发器，对冲突进行自定义处理，如将冲突行写入冲突日志表并返回 NULL 让 Apply Worker 跳过该行。该方法复杂且可能带来副作用，需谨慎测试。

工程实践总结 ：逻辑复制用于生产环境时，必须配置全面的监控告警，包括 pg_stat_subscription_stats 的 total_lag 趋势和错误计数，并结合 pg_stat_replication 与复制槽状态形成三级监控网。冲突处理应以架构预防为首，手动跳过为最后手段。

---

9. 面试高频专题

9.1 PostgreSQL 的声明式分区与传统继承分区有什么本质区别？

一句话回答

声明式分区将数据路由与分区排除职责交给数据库内核，由 PARTITION BY 语法统一声明；继承分区依靠表继承和 CHECK 约束与用户手工编写的触发器模拟分区，路由与排除均需人工维护。

详细解释

从内部实现看，声明式分区在 PG 10 引入了一套完整的元数据体系（pg_partitioned_table、pg_partition_tree()），优化器可以直接读取分区边界进行确定性的运行时裁剪，执行器则在 ExecInsert/ExecUpdate 中通过分区路由映射表自动定位目标分区。而继承分区虽然在系统表 pg_inherits 中记录了父子表关系，优化器在生成 Append 路径时会遍历子表并检查 CHECK 约束以决定排除，但 CHECK 约束本质上是用户层面的断言，优化器只能做模式匹配推导，复杂表达式可能推导失败，且插入时的路由必须靠触发器逐表试探。

从工程维护角度看，声明式分区的 ATTACH/DETACH 操作仅需元数据变更即可完成分区的在线附加与剥离，而继承分区添加新分区需要同步更新所有路由触发器或规则，极易出错。声明式分区还引入了 DEFAULT 分区，能够优雅地捕获边缘数据，这在继承体系下只能通过繁琐的额外触发器实现或直接报错。

从版本演进看，声明式分区是社区对分区功能的正规化重构，逐步补充了哈希分区、子分区、分区级聚合与连接等高级优化，未来所有分区相关增强都将建立在此基础之上，继承分区已进入维护模式。

多角度追问

1. 性能角度 ：两者在分区裁剪效率上有何量化差异？
   → 声明式分区的裁剪基于严格的区间代数运算，复杂度 O(log N) 通过二分查找定位分区，且支持运行时裁剪；继承分区依赖约束推导，容易失效而回退至全扫描。
2. 迁移角度 ：如果不暂停服务，如何将继承分区表在线迁移到声明式分区？
   → 创建新声明式分区表，使用逻辑复制将旧表变更同步过来，然后瞬间切换应用指向新表。或者非实时场景分阶段 ATTACH 旧分区的数据表（先建空分区，再挪数据）。
3. 锁竞争角度 ：在继承分区表中，插入数据时由于触发器是串行执行的，高并发下是否有不同于声明式分区的锁行为？
   → 继承分区的触发器逻辑在每个子表上依次判断，会引入额外的处理延迟和锁获取（如子表的 RowExclusiveLock 重复获取），声明式分区直接在路由后锁定目标单分区，效率更高。

加分回答

源码层面，声明式分区在规划期的 generate_partition_prune_steps 和运行时的 ExecFindPartition 提供了高效的分区间过滤。PG 16 进一步优化了多级子分区裁剪，可以在编译期生成更下推的过滤条件。继承分区中的 constraint_exclusion 仅仅是一种优化器尝试，其代码路径在 src/backend/optimizer/path/allpaths.c 中仍可见，但标记为相对旧式的方法。

9.2 RANGE、LIST、HASH 分区分别适用于什么场景？如何选择？

一句话回答

RANGE 适合连续键的范围查询与数据归档；LIST 适合离散分类管理，如多租户隔离；HASH 适合没有任何明显范围或分类特征但需要均匀分布写入负载的场景。

详细解释

选择分区策略的核心准则有两个：第一，最常见的查询模式是否能用分区键进行裁剪；第二，数据写入是否会在某个分区上形成热点。

对于 RANGE 分区，典型场景是订单表按月份或按 ID 范围，业务查询常常携带时间范围或 ID 范围。优化器可以高效裁剪不需要的月份，而且老数据可以按月整体 DETACH 做归档。RANGE 分区的边界必须清晰，并且通常建议均匀间隔以利于维护自动化。其风险在于最后一个分区通常承受所有的写入，如果时间粒度过大，写入热点仍存在（但比单表好）；粒度过细则分区数量爆炸。

LIST 分区适合根据少数固定离散值划分数据，比如按地理大区 (US, EU, APAC)、按业务流程状态或租户 ID。业务查询往往针对某个确定值的全量数据，裁剪效果非常确定。如果后续需要新增分类，可以直接通过 ATTACH PARTITION 添加新分区，而不需要像 RANGE 那样担心分裂现有区的代价。

HASH 分区则是在既无顺序又无明确分类时使用的最后手段。典型例子是物联网传感器数据，按照传感器 ID 进行哈希分区，可以确保数据写入几乎均匀分布在所有分区，避免热分区。缺点也很明显：几乎所有携带非分区键过滤的查询都会扫描全部分区，除非查询也限定了分区键（如 WHERE sensor_id = ?）。HASH 分区不支持 DEFAULT 分区，因为模数逻辑决定了全部空间必须被精确覆盖。

选择流程：首先判断是否有自然的范围维度（时间、序列）且多数查询带有范围条件，若有则选择 RANGE；否则看是否有少量固定的分类属性可用于 LIST；若都不满足但数据量极大且需要打散写入热点，则选 HASH。还可以采用组合分区，例如第一层 RANGE 按月，第二层 HASH 按用户 ID，兼顾时效性归档和写入均匀。

多角度追问

1. 架构扩展 ：如果业务发展后需要更改分区策略，如何在线调整？
   → 新建正确策略的分区表，使用逻辑复制同步数据，切换应用。或者对于简单增加 RANGE 边界可以用 SPLIT PARTITION（PG 不支持原生在线拆分，不过可通过 DETACH + ATTACH 新边界分区然后数据迁移的方式来模拟）。
2. 存储层面 ：三种分区的物理存储差异？
   → 完全没有差异，每个分区都是独立的物理表。
3. 索引角度 ：如果对 HASH 分区表创建一个非分区键上的 B-Tree 索引，会有什么影响？
   → 每个分区上都会创建该索引，跨分区查询需扫描所有分区的索引，然后归并结果，效果类似于索引全扫描。

加分回答

PG 的 HASH 分区基于 hash_any 扩展函数计算分区映射，属于一致性哈希范畴吗？不是，PG 的 HASH 分区使用静态模数（MODULUS），增加分区数需要重新分布所有数据，与传统一致性哈希可以只移动部分数据不同。社区已存在类似一致性哈希分区的第三方扩展，但原生未实现。

9.3 分区裁剪是如何工作的？如何验证它是否生效？

一句话回答

分区裁剪是优化器利用分区表的分区边界元数据，在计划阶段或执行阶段排除不可能包含目标数据的分区，减少扫描量；通过 EXPLAIN 查看扫描的分区数或 Subplans Removed 即可验证。

详细解释

分区裁剪分两个阶段：计划时静态裁剪与运行时动态裁剪。

计划时裁剪 发生在优化器生成路径时，调用 prune_append_rel_partitions()。该函数对每个分区的边界限制（记录在 pg_partitioned_table 关联的 RelOptInfo 中）与查询 WHERE 子句进行区间代数求交。若某一分区与过滤条件无交集，则从 Append 路径中移除。这一步主要针对常量条件有效。

运行时裁剪 针对参数化条件，例如预编译语句的参数、连接列的值或从子查询中获取的值。优化器会生成一个特殊的 Append 节点，内部包含分区裁剪执行器。实际执行时，先计算参数的具体值，再决定打开哪些分区，多余的子计划根本不会被启动。Subplans Removed 计数器在 EXPLAIN ANALYZE 中就是指示有多少分区在运行时被剔除。

验证方法：

SET enable_partition_pruning = on;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT * FROM orders WHERE order_date = '2024-05-10';

输出中只出现一个分区（如 orders_2024_05）的扫描，且 Subplans Removed 表示其他分区被移除。还可以故意关闭参数对比。

多角度追问

1. 边界条件 ：当分区边界存在 NULL 值（如在 RANGE 分区中使用了 MAXVALUE）时，裁剪行为如何？
   → MAXVALUE 表示无穷大，任何有限值都能被该分区包含，但优化器仍然可以裁剪掉上界小于过滤条件的其他分区。
2. 表达式索引 ：如果分区键是表达式，裁剪还能生效吗？
   → 声明式分区直接支持表达式分区键，优化器能识别分区键与 WHERE 中同样表达式的等价关系并进行裁剪。但若 WHERE 中表达式形式不同（如拼写差异或函数不同），裁剪可能失效。
3. Join 裁剪 ：当两张大分区表进行 JOIN 时，裁剪能否保持？
   → 如果 join 条件包含了各自的分区键并且可用包含动态裁剪的运行时 Append，那么可以以交错的方式裁剪，有效减少实际组合量（动态分区连接优化在 PG 12+ 逐渐增强）。

加分回答

PG 16 中的运行时裁剪支持 PartitionPruneInfo 数据结构存储裁剪步骤，减少规划开销。此外，当查询涉及多级子分区时，裁剪会自上而下进行，每一级都会再次裁剪下一级，因此超级大分区表的多层裁剪仍然高效。

9.4 逻辑复制与物理流复制有什么根本区别？各自的适用场景？

一句话回答

逻辑复制复制的是表级别的行变更（INSERT/UPDATE/DELETE），允许跨版本、按表过滤；物理流复制复制的是数据库集群的 WAL 物理记录，保证整个实例的完全一致，适用于高可用和只读扩展。

详细解释

物理流复制工作在 WAL 级别，将主库生成的 WAL 文件或流式 WAL 记录直接发送给备库，备库按顺序回放这些物理页变更，最终得到与主库完全相同的数据库集群。这种方式复制粒度粗，不能选择库或表，必须复制整个实例。其优势是延迟极低、实施简单，并支持同步流复制保证零数据丢失。典型场景：基于 PG 的一主多从读写分离，或 Patroni 等自动故障切换的高可用方案（详见系列第 11 篇）。

逻辑复制则利用逻辑解码，将 WAL 中的物理变更还原为原始 SQL 操作（行级插入、更新和删除），然后通过 Publication/Subscription 模型推送给目标实例。复制粒度是表级，可灵活选择复制哪些表的哪些操作，甚至只复制部分 DML。它还支持跨大版本复制，源库 PG 13 可以复制到 PG 16。逻辑复制不要求目标库物理结构完全一致，甚至可以有不同的索引布局，只要复制表结构兼容。此外，逻辑复制允许数据聚合分发，一个源可以同时向多个目标分发不同表的子集，但劣势是不支持 DDL 复制，延迟相对较高，资源消耗更多（额外解码、发送进程），并且缺乏内建的冲突自动解决机制。

适用场景选择：

• 物理流复制：高可用、读写分离、灾难恢复。
• 逻辑复制：表级数据同步、跨版本在线升级、多数据中心数据分发与整合、异构环境数据管道（例如数据从 OLTP 系统流入分析库）。

多角度追问

1. 数据一致性 ：物理复制的一致性和逻辑复制的一致性保障差异？
   → 物理复制严格字节级一致，逻辑复制是事务级最终一致（异步），允许短暂的主备数据不同步。
2. 故障切换 ：高可用环境能否混合使用？
   → 常见模式是物理流复制用于容灾，逻辑复制用于报表库数据同步，两者互不影响，可以在同一个主库上并存。
3. 资源争用 ：逻辑复制对主库的性能影响体现在哪里？
   → WAL 日志量因 REPLICA IDENTITY 的设置可能增大，逻辑解码进程占用额外 CPU 与内存，且逻辑复制槽阻止 WAL 清理，可能引发磁盘压力。

加分回答

PG 底层，物理复制是通过 walsender 进程直接以 physical 复制协议工作，逻辑复制则通过 walsender 加载 pgoutput 插件，使用 logical 复制协议。PG 14 引入了逻辑复制的流式传输和事务并行应用能力，大幅缩短大型事务的延迟，缩小与物理复制的延迟差距。

9.5 如何在不停机的情况下将一张大表改造为分区表？

一句话回答

通过逻辑复制创建影子分区表并实时同步数据，然后瞬间切换应用的表名，或者利用 ATTACH PARTITION 从外部表逐步吸入数据进行分阶段再造。

详细解释

不停机改造的核心思想是"并行存在 + 数据补齐 + 瞬间切换"。

方案一：逻辑复制迁移法（最为稳健）

1. 在同一个库或目标库创建期望的分区表结构：

CREATE TABLE orders_new (LIKE orders INCLUDING ALL) PARTITION BY RANGE (order_date);
-- 创建各分区...

2. 在源表 orders 上创建发布：

CREATE PUBLICATION pub_orders FOR TABLE orders;

3. 为 orders_new 创建订阅：

CREATE SUBSCRIPTION sub_orders_new
  CONNECTION 'host=localhost dbname=mydb' PUBLICATION pub_orders
  WITH (copy_data = true);

初始快照将会逐步将存量数据复制至新表，此过程中源表依然正常读写。

4. 监控复制延迟，当延迟接近零后，在一个低流量窗口执行切换：将应用读写指向 orders_new，同时移除旧表。为保证原子性，可借助 BEGIN; LOCK TABLE orders IN ACCESS EXCLUSIVE MODE; ALTER TABLE orders RENAME TO orders_old; ALTER TABLE orders_new RENAME TO orders; COMMIT; 极短时间内排他锁完成重命名。

5. 清理订阅与旧表。

方案二：逐步 ATTACH 法 （适用数据可分批移动）

若表数据可按时间或 ID 分批且允许业务短暂间断（秒级），可以不借助逻辑复制：

1. 创建新的分区表。
2. 将旧表历史数据按片段导出，并逐一创建独立表加载，然后 ATTACH PARTITION。
3. 最后的活跃数据，可瞬间停止写入，将剩余数据插入最后分区后附加上去。
   此法有停止写入的时间窗口，适用性受限。

多角度追问

1. 外键关联 ：旧表有外键依赖如何处理？
   → 切换后外键需要重建到分区表，可在锁定窗口内包裹 DDL 完成。逻辑复制方案允许同步重建外键后切换。
2. 序列问题 ：分区表如果有自增主键序列，迁移过程中如何确保不冲突？
   → 逻辑复制会自动同步数据，copy_data 阶段会复制当前序列的值。切换后及时同步或调整序列起点。
3. 索引预创建 ：新分区表的索引应该在什么时候创建？
   → 一次创建在空分区上开销小，但如果是在 copy_data 期间创建索引，会影响同步性能。建议待初始同步完成后、切换前创建，或者初始同步时不带索引，同步完成后 REINDEX CONCURRENTLY 构建。

加分回答

PG 16 新增的 CREATE TABLE ... PARTITION OF ... FOR VALUES ... (subpartition) 和 pg_partman 第三方工具可以自动维护分区创建，但迁移过程中的大表切换依然依赖上述原理。生产级方案可以结合 pg_dump + 逻辑复制的混合方式以降低初始同步的压力。

9.6 逻辑复制中，REPLICA IDENTITY 配置有什么作用？

一句话回答
REPLICA IDENTITY 控制如何在 WAL 中记录 UPDATE 和 DELETE 操作所需的行标识信息，用于订阅端准确定位要修改的行。

详细解释

逻辑复制解码出行的变更事件后，订阅端必须知道哪一行要被更新或删除。REPLICA IDENTITY 定义了这一需求：

• DEFAULT（默认）：表存在主键时，使用主键列作为行标识。WAL 仅记录主键值和更新列，效率高。若表无主键，则不可用，无法加入逻辑复制发布。
• USING INDEX index_name：使用指定的唯一索引（必须 NOT NULL）列作为标识。
• FULL ：使用整行的全部列作为标识，任何表都可以设置，但每次 UPDATE 和 DELETE 都会在 WAL 中记录整行的旧值，导致 WAL 量大幅膨胀，解码和传输开销剧增，严重影响延迟。
• NOTHING ：不记录任何旧值，仅用于只插入表或少有删除/更新的场景，逻辑复制不允许用于 UPDATE 和 DELETE 的复制。

若一张表既没有主键也没有开启 FULL 的 REPLICA IDENTITY，则该表无法发布到逻辑复制中。工程中强烈推荐为所有参与复制的表创建显式主键，并使用默认设置，以保证复制性能和可维护性。

多角度追问

1. 无主键表的救赎 ：如果确实无法添加主键，除了 FULL 还有哪些优化手段？
   → 设计规范上应避免。实在无法改变，可以增加一个 UUID 列作为唯一标识并设为主键或唯一索引，然后用 REPLICA IDENTITY USING INDEX。
2. FULL 模式下长宽表的性能代价：100 列的表更新一列，WAL 会记录全部 100 列的旧值副本，不仅 WAL 爆增，解码和订阅端应用也会拖慢。
3. DDL 变更影响 ：更改 REPLICA IDENTITY 是瞬间的目录修改，但会影响后续的所有 WAL 记录，当前正在进行的复制可能收到混合格式，需保证兼容。

加分回答

解码插件 pgoutput 根据 REPLICA IDENTITY 从旧行中的 tuple 提取标识信息并构建消息；订阅端 worker 使用该标识信息生成对应的 DELETE 或 UPDATE 的 WHERE 条件。若主键值发生变更（不推荐），订阅端将其视为 DELETE + INSERT，所以 REPLICA IDENTITY 稳定至关重要。

9.7 分区表为什么不能有全局唯一索引？有什么替代方案？

一句话回答

分区表本质是多个独立物理表，PostgreSQL 没有全局索引结构来实现跨分区的唯一性检查，因此唯一索引和主键必须包含所有分区键；替代方案包括使用 UUID 作为全局唯一标识，或者拆分唯一性检查由应用或外部服务保证。

详细解释

对于普通堆表，唯一索引建立在单一的 relfilenode 上，B-Tree 结构可以直接扫描全部键值来判断唯一性。但分区表的每个分区都有自己独立的 relfilenode 和单独的索引，数据库缺乏一个统一的全局索引结构来跨分区检查重复。因此，约束 UNIQUE(order_id) 在分区表上无法创建，因为数据库不能允许一个可能违反整个表唯一性的约束。PG 只允许"分区本地"的唯一索引，且前提是索引列包含所有分区键。例如分区键为 order_date，则 UNIQUE(order_id, order_date) 是可以的，因为给定 order_date 后，行一定只会落在一个分区内，唯一性只需在单分区内保证。

替代方案：

• UUID 主键：使用 UUID 或无冲突的雪花 ID 作为主键，放弃依赖数据库保证唯一，由应用程序或 ID 生成方案确保。这样甚至可以不将 ID 作为分区键，避免分区键改变数据分布，但无法再利用数据库约束。
• 外部唯一性服务：使用 Redis 或数据库序列表预先申请 ID。
• 重新设计分区键包含唯一列 ：如将 unique_id 作为分区键，或者与现有分区键组合。

多角度追问

1. 性能影响 ：如果在每个分区上分别建立相同列的索引，跨分区查询是否会使用索引？
   → 会分别扫描每个分区的索引，然后归并结果，效率比全局索引单次查找差。
2. 是否可以在父表上建立基于表达式的索引冒充全局？
   → 不可以，父表本身不存储数据，无法建真实索引。
3. MySQL 分区的全局索引情况？
   → MySQL InnoDB 分区表同样不支持全局唯一索引，除非唯一键包含所有分区列，情况与 PG 相同。

加分回答

PG 16 社区有讨论 Future 全局索引的可行性，但由于物理分离的设计哲学，实现需要交叉引用不同文件的索引项，这背离了 PG 的架构，短期内无官方计划。分区表的最佳实践：让分区键与业务主键形成绑定关系根本规避此问题。

9.8 PostgreSQL 的逻辑复制与 MySQL 的 Binlog 复制有什么不同？

一句话回答

PG 逻辑复制基于 WAL 逻辑解码，提供表级的灵活发布/订阅；MySQL Binlog 复制根植于 Server 层日志，以实例或库级别的全部变更复制为基本单位。

详细解释

架构层面，PG 的逻辑复制完全由插件机制驱动，解码插件 pgoutput 作为 WAL 到消息的中介，Publisher/Subscriber 模型允许独立配置发布哪些表的哪些操作。MySQL 的复制基于 binlog，记录格式可以是 STATEMENT、ROW 或 MIXED，默认所有库表的 DML 都会被记录，然后通过 CHANGE MASTER 指向主库，IO 线程拉取 binlog，SQL 线程回放。过滤粒度仅在 replicate-do-db/replicate-do-table 级别，但粒度相对象 PG 粗，且过滤逻辑有时可能产生意外跳过。

在 DDL 复制方面，PG 的逻辑复制完全不处理 DDL（需要手动在目标库同步），这使其跨版本复制异常灵活（无 DDL 版本兼容问题），但也给频繁 DDL 的系统增加管理成本。MySQL 的 binlog 可以复制绝大多数 DDL，接近物理一致性。

在复制延迟监控与可靠性方面，PG 有逻辑复制槽保持 WAL 不被清理；MySQL 使用 binlog 过期机制（expire_logs_days），如果备库太慢，主库 binlog 被清可能导致复制中断。两者均有各自的中断风险。

多角度追问

1. GTID 对比 ：MySQL 的 GTID 与 PG 的 LSN 在复制中的作用？
   → MySQL GTID 提供全局唯一事务标识，便于故障切换和重定位；PG 的 LSN 是严格有序的字节位置，不具备全局事务 ID，物理复制和逻辑复制都用 LSN 定位，但逻辑复制基于事务边界，内部辅助 origin 机制标识来源。
2. 过滤粒度 ：如果只想复制某个表的部分行，PG 和 MySQL 分别怎么处理？
   → PG 可以在 Publication 中通过行级过滤（使用 WHERE 子句，PG 15+ 支持），MySQL 原生不支持行级复制过滤，只能通过触发器或应用方案。
3. 异构复制 ：哪种更容易将数据同步到非自身数据库（如 Kafka、Redis）？
   → PG 的解码插件设计很容易对接外部消费者，开发定制插件即可（如 decoderbufs 对接 Kafka）；MySQL 通常需要第三方工具如 Maxwell、Debezium 解析 binlog。

加分回答

PG 逻辑复制在 PG 16 中的流式传输和并行 apply 能力日益强大，正在缩小与传统物理复制和 MySQL 复制在延迟上的差距。此外，PG 的逻辑复制可以轻松实现双向或多主复制（需自行解决冲突），而 MySQL 的 Group Replication 用 Paxos 实现，但限制较多。

9.9 如何监控逻辑复制的延迟？pg_stat_subscription_stats 的使用。

一句话回答

通过查询 pg_stat_subscription_stats 视图的 total_lag 列与相关时间戳，结合 pg_stat_replication 和复制槽状态，构建多层延迟监控体系。

详细解释
pg_stat_subscription_stats 是 PG 14 引入的关键监控视图，每个订阅一条记录。

SELECT subname,
       apply_error_count,
       latest_error_message,
       total_lag,
       last_msg_send_time,
       last_msg_receipt_time,
       latest_end_lsn,
       latest_end_time
FROM pg_stat_subscription_stats;

• total_lag ：类型 interval，表示订阅端应用落后于发布端的时间长度，是最直观的延迟指标。内部通过比较消息的提交时间戳与本地应用完成时间计算得出，需要主库和备库时钟同步（NTP）以保证准确性。
• last_msg_send_time / last_msg_receipt_time：上一次消息从发布端发出和订阅端收到的时间，两者之差反映了网络传输延时。
• apply_error_count 与 latest_error_message：用于监控冲突或应用错误，一旦非零立即告警。

在发布端，可以辅助查询 pg_stat_replication 视图观察每个 WAL Sender 的 write_lag、flush_lag、replay_lag，这些反映了 WAL 在不同阶段（写入备库系统缓存、刷盘、回放）的延迟。同时必须监控 pg_replication_slots 中 active 状态及 restart_lsn 与当前 lsn 的差值，计算 WAL 积压大小，设置磁盘报警阈值。

多角度追问

1. total_lag 突然飙升的排查路径？
   → 检查是否有大事务未提交，网络抖动，查看 REPLICA IDENTITY FULL 或长时间未提交的事务。
2. 订阅端停止响应时，如何安全清理？
   → 先 DISABLE 订阅，观察 WAL 发送端是否停止积压，必要时 DROP SUBSCRIPTION 并清理复制槽。
3. 延迟容忍度设计 ：通常可以接受多大的复制延迟？
   → 依据业务需求，报表库一般秒级可接受，缓存同步需要亚秒则不合适用逻辑复制。

加分回答

PG 16 增加了 pg_stat_subscription 视图的更多细节，可联合 pg_stat_progress_apply 观察应用进度。自定义监控可以写一个 check_postgres 插件或 Prometheus 导出器，循环执行上述 SQL 并暴露延迟指标。

9.10 ATTACH PARTITION 的内部原理是什么？附加时需要注意什么？

一句话回答
ATTACH PARTITION 通过元数据操作将一个已有表注册为分区表的子分区，同时验证所有现有行满足分区边界；过程中需获取父表及其分区的 ACCESS EXCLUSIVE 锁。

详细解释

执行 ALTER TABLE parent ATTACH PARTITION child FOR VALUES ... 时，PG 内部主要经历以下步骤：

1. 锁获取 ：对父表和子表获取最高级别的 ACCESS EXCLUSIVE 锁，确保没有并发写入。
2. 边界约束检查 ：如果分区表没有预定义 DEFAULT 分区，且需要验证子表中的每一行都满足新分区的边界条件。该检查通过执行 SELECT count(*) FROM child WHERE NOT (bound_condition) 完成。如果子表已有匹配的 CHECK 约束，且该约束与分区边界等价，PG 可以跳过全表扫描验证（称为"免检 ATTACH"），从而大大加速操作。
3. 元数据更新 ：在系统目录中插入 pg_partitioned_table 的记录，建立子表与父表的关系，注册分区路由信息。
4. 锁释放：提交事务后，新分区立即对 DML 可见。

注意事项：

• 在大表上 ATTACH 若未利用免检优化，会触发全表验证，可能需要较长时间持有排他锁，阻塞所有对父表的写入和查询。最佳实践是在附加前主动为新表添加一个与边界等价的 CHECK 约束，并保证数据符合。
• ATTACH 之后的子表索引会被分区表自动继承引用。
• 如果已有 DEFAULT 分区，且新分区边界包含了一些原本属于 DEFAULT 分区的行，ATTACH 会成功，但原本 DEFAULT 分区中的那部分匹配新边界的行不会自动移动，需要后续手动迁移或清理 DEFAULT 分区，否则可能造成某些行同时可以被两个分区匹配的语义混乱（实际查询时按严格边界匹配，不会错误，但数据分布不符合预期）。

多角度追问

1. 在线数据归档 ：如何搭配 DETACH 和 ATTACH 实现无缝滚动分区？
   → 每月初，将最老的分区 DETACH 并归档，然后 ATTACH 一个新空分区作为最新的月份。
2. 如果 ATTACH 失败（数据不满足边界）会报什么错？
   → 错误类似于"violates partition constraint"，事务回滚，表仍为独立表。
3. 性能调优 ：如何为大表 ATTACH 提前创建最佳 CHECK 约束？
   → 使用与分区边界完全相同的表达式，例如 CHECK (order_date >= '2024-01-01' AND order_date < '2024-02-01')。

加分回答

源码在 src/backend/commands/tablecmds.c 中 ATExecAttachPartition 实现了逻辑，其中 validatePartitionConstraint 函数执行实际的数据验证。PG 16 允许排他锁期间短暂的微小查询阻塞，但如果验证耗时过长，建议升级至 PG 12+ 的 ATTACH PARTITION CONCURRENTLY 功能？遗憾的是 PG 尚未提供 ATTACH CONCURRENTLY，但有 patch 讨论过。目前只能通过控制验证耗时来降低影响。

9.11 分区表的索引应该如何管理？如何在线重建分区索引？

一句话回答

每个分区自己的索引独立维护，通过 REINDEX CONCURRENTLY 可以在不影响写的状态下重建任何分区索引，对于父表执行该命令会自动递归所有子分区。

详细解释

分区表的索引管理要点：

• 分区表父表上无法创建有效索引（如果是全局索引概念），所有索引必须建在每个分区上。通常我们会将索引创建命令直接执行在父表上，让系统递归到每个分区创建本地索引。

CREATE INDEX idx_orders_customer_id ON orders (customer_id);

该语句会在每个已存在分区上创建相应的索引，并且未来 ATTACH 的新分区也会自动创建相同索引？并不会，新 ATTACH 的分区需要独立再建索引（或先建好）。

• 索引膨胀监控：可以按分区维度查询 pg_stat_user_indexes 与 pgstattuple，对膨胀严重的老分区集中重建。
• 在线重建：REINDEX CONCURRENTLY 允许在不长期阻塞写入的情况下重索引。它会：
  1. 在表中创建新索引（带临时名），异步构建。
  2. 等待所有正在修改表的事务结束。
  3. 在系统目录中交换新旧索引，旧索引标记为失效。
  4. 再次等待所有老旧事务完成后，清理旧索引文件。 全程只以 SHARE UPDATE EXCLUSIVE 锁阻塞 DDL 但允许 DML。如果重建过程中失败，系统会留下失效索引，需手动清理。

要重建整个分区表上的索引，执行：

REINDEX INDEX CONCURRENTLY idx_orders_customer_id;

即使索引名是父表对象，PG 也会找到所有分区的对应索引，并逐一进行并发重建。但注意这并非同时，而是串行遍历。

多角度追问

1. 唯一索引重建过程的约束检查？
   → 新索引构建时常规的约束验证依然有效，违反唯一性的数据会导致重建失败。
2. 系统表负载 ：大量并发 REINDEX CONCURRENTLY 可能造成目录锁竞争，应低峰期分批执行。
3. 与 VACUUM 的关系：重建索引可以消除膨胀，但 VACUUM 只能标记死行，不能收缩索引物理大小，因此 REINDEX 是大表定期必须执行的任务。

加分回答

PG 16 优化了 REINDEX CONCURRENTLY 对死锁的处理，增加了重试机制，使其在活跃 OLTP 下更稳定。结合 pg_indexam_wal_advancement 等技术，未来可能逐步实现自动索引清理。

9.12 系统设计题：多租户订单系统的数据架构

题目

设计一个支持多租户的订单系统数据架构，要求：① 按租户 ID 进行数据隔离；② 每个租户的订单按月份自动分区；③ 实时将热数据同步到分析库进行报表查询。请结合 PG 的分区表和逻辑复制特性，给出核心的库表设计、分区策略和同步方案。

一句话回答

采用 LIST（租户）+ RANGE（月份）两级复合分区实现数据隔离与生命周期管理，通过逻辑复制精准同步热数据分区至分析库。

详细解释

1. 库表设计

CREATE TABLE orders (
    order_id    UUID NOT NULL DEFAULT gen_random_uuid(),
    tenant_id   INT  NOT NULL,
    order_date  DATE NOT NULL,
    customer_id INT,
    amount      DECIMAL(12,2),
    details     JSONB,
    PRIMARY KEY (order_id, tenant_id, order_date)  -- 分区键全包含保证唯一
) PARTITION BY LIST (tenant_id);

分区分层策略

第一层：按 tenant_id LIST 分区，每个租户一个主分区。当新租户注册时，动态创建新租户分区：

CREATE TABLE orders_tenant_100 PARTITION OF orders
    FOR VALUES IN (100)
    PARTITION BY RANGE (order_date);

第二层：在每个租户分区内部按月 RANGE 分区，自动或定时创建未来月份分区（如通过定时任务或 pg_partman 扩展）：

CREATE TABLE orders_tenant100_202405 PARTITION OF orders_tenant_100
    FOR VALUES FROM ('2024-05-01') TO ('2024-06-01');
CREATE TABLE orders_tenant100_202406 PARTITION OF orders_tenant_100
    FOR VALUES FROM ('2024-06-01') TO ('2024-07-01');
-- 为捕获异常数据，每租户分区下可创建 DEFAULT 分区（但 RANGE 子分区整体不支持 DEFAULT？PG 支持在 LIST 分区下创建 DEFAULT 分区，但二级 RANGE 子分区下无法再 DEFAULT，可设置 MAXVALUE 分区兜底）
CREATE TABLE orders_tenant100_future PARTITION OF orders_tenant_100
    FOR VALUES FROM ('2025-01-01') TO (MAXVALUE);

2. 数据生命周期管理

• 每月初，通过定时脚本为新月份创建空分区（CREATE TABLE ... PARTITION OF），同时将超老旧的月份数据分区 DETACH 后备份并删除。
• 由于每个租户的月度分区物理独立，可按需单独进行 VACUUM、ANALYZE 和索引优化。
• 确保每个分区均有对应业务所需索引，如 (customer_id)、(order_date) 等本地索引。

3. 实时同步至分析库

分析库可能是另一 PG 实例，不承接 OLTP 流量，专注于复杂查询和报表。

方案架构：

• 在 OLTP 库对 orders 表创建 Publication：

CREATE PUBLICATION pub_orders_analytics FOR TABLE orders;

• 在分析库创建相同的分区表结构（可适当简化索引以加速加载）。
• 分析库创建 Subscription：

CREATE SUBSCRIPTION sub_analytics
    CONNECTION 'host=oltp-db dbname=appdb user=replicator password=xxx'
    PUBLICATION pub_orders_analytics
    WITH (streaming = 'parallel', synchronous_commit = 'off');

复制颗粒度：由于 Publication 是针对父表 orders，所有租户的所有分区的变更都会被发送。如果需要进一步减少同步量，可针对热数据租户只复制特定租户分区，这将要求在发布端对各租户分区独立发布（PG 16 允许精确到分区表）。考虑到部分租户可能已不活跃，只同步活跃租户能节约分析库空间。为此，直接对活跃租户的一级分区或其当前月度分区创建发布：

CREATE PUBLICATION pub_active_tenants FOR TABLE orders_tenant_100, orders_tenant_200;

这样分析库仅订阅活跃租户的变更，历史租户数据可离线导入。

4. 分析库的查询优化

分析库通常运行聚合查询，可针对性地启用分区级聚合（enable_partitionwise_aggregate = on）并按租户或月份进行并行聚合扫描。由于数据已实时同步，报表几乎实时的。

冲突处理 ：分析库完全只读，禁用写入（设置 default_transaction_read_only = on 并收回写权限），从根源上消除逻辑复制冲突。

多角度追问

1. 扩展性追问 ：如果有上万个租户，LIST 一级分区会性能下降吗？
   → PG 16 单个分区表分区数理论上限数千到一万，过多分区会导致规划时间增加及系统目录膨胀。此时可引入 HASH 分区替代 LIST 做粗粒度分布，比如 HASH（tenant_id）MODULUS 128 分为 128 个桶，桶内再 RANGE 按月。租户隔离的逻辑在应用层映射。
2. 查询跨租户月报 ：如何高效获取所有租户某月的总销售额？
   → 查询条件带上月份，优化器会裁剪每个租户分区内只保留该月分区，通过分区级聚合分别算出每个租户求和，最后汇总。
3. 故障恢复 ：如果分析库逻辑复制中断，如何修复？
   → 若中断时间短，ALTER SUBSCRIPTION ... ENABLE 自动接续；时间长可能导致 WAL 被清理，则需要重建订阅（DROP SUBSCRIPTION 后重建），此为万不得已时。

加分回答

实际企业级落地方案可以使用 Citus 将租户分布到多个节点，同时结合本设计思想，形成 "分布式 + 分区" 双层分片。逻辑复制可与 Citus 共存，通过其分片逻辑更细粒度地同步到分析平台。此外，可利用 timescaledb 超表实现基于时间的自动分区，混合 PG 分区与行业扩展，但需留意授权。

---

附录：PG 分区与复制速查表

特性	核心语法/参数	适用场景	注意事项
声明式分区	CREATE TABLE ... PARTITION BY RANGE/LIST/HASH	大表分片，时间归档，多租户	唯一索引须含分区键
分区裁剪	enable_partition_pruning = on	所有分区表查询优化	避免在分区键上使用函数
分区级聚合	enable_partitionwise_aggregate = on	按分区键 GROUP BY 查询	需合适统计信息
ATTACH/DETACH	ALTER TABLE ... ATTACH/DETACH PARTITION	在线归档、数据旋转	ATTACH 需短暂独占锁
逻辑复制	CREATE PUBLICATION ... FOR TABLE / CREATE SUBSCRIPTION	表级数据同步，跨版本升级	不复制 DDL；需监控延迟
复制冲突处理	pg_stat_subscription_stats 查看，手动跳过	解决复制中断	应先预防冲突
REINDEX CONCURRENTLY	REINDEX INDEX CONCURRENTLY idx_name	在线重建分区索引	成功后需清理残留

延伸阅读 ：PostgreSQL 官方文档 Table Partitioning 和 Logical Replication；《PostgreSQL: The Definitive Guide》分区与复制部分。

---