TiDB/OceanBase/PolarDB/Citus 分布式数据库

• 掌握 TiDB 分层架构（计算层/存储层/调度层）各层职责
• 理解 Raft 协议在分布式副本一致性中的作用
• 认识计算层无状态与存储层有状态的分离设计

TiDB 采用"计算与存储分离"架构。计算层（TiDB Server）是无状态 SQL 层，负责解析 SQL、生成执行计划、执行算子并汇总结果，因为不保存数据，所以可以直接扩容/缩容，通过负载均衡器分发请求即可线性扩展。存储层 TiKV 是有状态的，按 Region 分片保存数据，每个 Region 默认 3 副本，通过 Raft 协议进行选主（Leader）与日志复制（Log Replication），只有 Leader 才能读写，Follower 通过提交日志同步，保证多数派写入后数据才对外可见，从而在网络分区或节点故障时仍能保持一致与可用。

这是 NewSQL 的典型架构：计算无状态使扩展简单可靠，存储层用 Raft 把"一致性"从单机事务扩展到了多副本。Raft 的多数派（quorum）机制保证了"少数派宕机不影响可用性，多数派提交才确认"，这是 TiKV 一致性的基石。

• 理解 Raft 协议在多区域复制中的应用
• 掌握 Multi-Region 的副本放置策略
• 认识全局一致与跨区延迟的权衡

CockroachDB 每个 range 默认 3 副本，副本分布在多个 region，通过 Raft 保证强一致；多区域部署时，写入需要多数派（通常跨 region 的 quorum）确认，因此强一致但写入延迟会随地理距离增大。CockroachDB 22.1+ 提供 Multi-Region 配置，通过 SURVIVAL GOAL（REGION/AVAILABILITY）与 lease 亲和策略（如 FOLLOW THE WORKLOAD），让写入尽量在本 region 完成多数派，从而在保证全局一致性的同时降低本地延迟。

核心矛盾是"全局一致性与跨区延迟"的权衡。跨区强一致意味着必须等待远端多数派确认。CockroachDB 通过"多数派放同区域、lease 跟随工作负载"在强一致前提下尽量降低延迟，这是它与简单异步复制数据库的本质区别。

• 理解 PostgreSQL 协议兼容的价值
• 认识 SQL 方言差异对迁移的影响
• 掌握 NewSQL 数据库兼容性策略

CockroachDB 使用 PostgreSQL 线协议（wire protocol）和大部分 SQL 方言，因此现成的 PG 驱动、ORM、工具（psql、pg_dump 等）可以直接使用，应用迁移成本低。但它是分布式实现，部分 PostgreSQL 特性（如触发器、部分存储过程语义、某些索引类型）不完全支持，且单查询语义在分布式执行下可能与原生 PG 略有差异。总体上，协议兼容降低了接入门槛，但严格的生产迁移仍需做兼容性测试。

协议兼容是 NewSQL 生态策略的关键：用兼容性换取生态与工具链。相较于完全自研协议，PG 协议让 CockroachDB 直接复用庞大的 PG 客户端生态。

• 理解 Raft learner 的角色（只同步不参与投票）
• 掌握 TiFlash 列存与 TiKV 行存的同步机制
• 认识 HTAP 中行/列存一致性的实现

TiFlash 把数据复制节点作为 Raft group 中的 learner（只同步日志、不参与选主投票），通过 Raft 异步复制 TiKV 的日志，再在本地以列存格式落盘。这样 TiFlash 与 TiKV 共享同一份数据流，实现"近实时"（秒级以下）的列存视图，且不会影响 TiKV 的写入路径。查询时 TiDB 通过优化器根据代价选择从 TiKV（行存）或 TiFlash（列存）读取，从而支持同一份数据同时跑 OLTP 与 OLAP。

learner 不参与 quorum，因此复制失败不会阻塞主副本写入，做到了"分析不干扰交易"。列存近实时同步让 HTAP 的"实时"成为可能，是 TiDB 混合负载的核心机制。

• 理解 Paxos 协议在 OB 多副本中的选主与日志复制
• 掌握"每副本独立 redo log"的落盘与恢复语义
• 认识多副本一致性与故障恢复的关系

OceanBase 每个分区（partition）默认 3 副本，通过 Paxos 协议选主并复制日志。写入时 Leader 生成 redo log 同步给多数派 follower，多数派确认后提交。每个副本独立维护自己的 redo log（日志流），保证各副本在故障时能根据各自日志独立恢复，配合 Paxos 的多数派保证，即使部分副本丢失也能恢复出一致的数据。独立 redo log 是"多副本多数派 + 各自恢复"的基础，让副本之间不共享存储也能保持一致。

与 TiDB 的 Raft 类似，OceanBase 用 Paxos 实现多数派一致。核心差异是"每副本独立 redo log + 独立存储"，这使 OB 的副本是真正独立的物理副本，任一副本的内存/磁盘独立，故障时可通过日志回放恢复。

• 理解 LSM-Tree 的写入优化（顺序写 + 合并）
• 掌握 LSM-Tree 在 OLTP 高写入场景的优势
• 认识 LSM-Tree 的读放大与写放大权衡

OceanBase 3.x 的存储引擎采用 LSM-Tree，写入先进入内存 memtable，定期刷成不可变 SSTable 并做后台 compaction 合并。相比 B+ 树随机写，LSM-Tree 把随机写变成顺序写，大幅提升写入吞吐，配合压缩（如字典压缩、块压缩）降低存储成本。同时 OB 通过每个 SSTable 的块索引、布隆过滤器（bloom filter）控制读放大，并提供增量合并（daily merge）机制进一步减少写放大，从而在 OLTP 高写入场景获得更高吞吐与更低存储开销。

LSM-Tree 是"以写换读"的经典取舍。OB 引入 LSM 正是为了支撑高并发写入与压缩存储，同时用 bloom filter、compaction 策略缓解读放大问题，这是它与传统 InnoDB 式 B+ 树引擎的区别。

• 掌握 OceanBase 的 MySQL 兼容模式
• 理解 OMS 迁移工具的职责与迁移方式
• 认识兼容性对业务迁移价值

OceanBase 内置 MySQL 兼容模式，支持 MySQL 5.7/8.0 的线协议与大部分 SQL 语法、数据类型、存储过程等，使现有 MySQL 应用可近乎零改动接入。OMS（OceanBase Migration Service）提供结构迁移、全量迁移、增量同步（基于日志）与数据校验，支持在线迁移不停机，并处理 DDL 与主键冲突等场景。通过 OMS 可把 MySQL 数据平滑迁移到 OceanBase，降低迁移成本与风险。

兼容性 + 迁移工具是 OB 从存量 MySQL 市场切入的关键。兼容 MySQL 协议降低应用改造，OMS 在线迁移降低停机风险，两者共同构成低门槛迁移方案。

• 理解 PolarDB 对 InnoDB 存储引擎的兼容
• 掌握 Redo 日志在 PolarDB 中的角色
• 认识共享存储架构下的引擎兼容

PolarDB MySQL 8.0 的存储引擎与 InnoDB 兼容，表结构、索引、redo log 格式与 MySQL 保持一致，因此现有的 MySQL 工具、备份、binlog 解析等生态可直接复用。PolarDB 将 redo log 下沉到共享存储，由多个计算节点共享同一份存储数据，redo 用于故障恢复与一致性保证。这种"一写多读"架构既保持 InnoDB 语义兼容，又通过共享存储实现计算节点扩展。

PolarDB 的核心是"计算与存储分层 + 引擎兼容"。它把 InnoDB 的存储部分（含 redo）放到共享存储，让多个计算节点共享，同时保持 MySQL 语义，从而在兼容 MySQL 生态的同时获得弹性扩展。

• 理解 GMS（全局元数据服务）的职责
• 掌握 XPaxos 在副本复制中的作用
• 认识分布式事务与元数据一致性的关系

PolarDB-X 是分布式数据库，存储节点通过 XPaxos 协议实现多副本同步，保证每个分片的数据在多数派确认后提交，从而在节点故障时保持强一致。GMS（Global Meta Service）负责全局元数据管理（如表结构、分片分布、事务元数据），通过集群化部署保证元数据一致性与高可用。XPaxos 提供副本一致，GMS 提供元数据一致，两者结合支撑 PolarDB-X 的分布式事务与全局一致性。

分布式数据库的一致性是"副本一致 + 元数据一致"双重的。PolarDB-X 用 XPaxos 保证数据副本一致，用 GMS 保证元数据一致，这构成本地/分布式事务的坚实基础。

• 理解 HTAP 中行存与列存的协同读取
• 掌握 TiKV 的 RocksDB 写放大控制策略
• 认识 HTAP 统一读的一致性与延迟

TiKV 以 Raft 分片 + 行存支撑 OLTP 写入，TiFlash 以列存支撑 OLAP 分析，二者通过 Raft learner 同步数据。查询时优化器根据代价自动选择从行存或列存读取，实现同一份数据同时跑交易与分析。TiKV 底层用 RocksDB（LSM-Tree），写放大通过调整 compaction 参数（如 level 大小、compaction 触发阈值）、使用别名的 Raft 日志与数据合并、以及控制 LSM 层数来控制。TiFlash 的列存也采用类似 LSM 合并机制，减少写放大与存储开销。

HTAP 的本质是"一份数据两种读法"。TiDB 用行存/列存双引擎 + Raft 同步实现，写放大则借助 LSM 的 compaction 调优与日志合并来控制，这是兼顾写入性能与存储成本的关键。

• 掌握 PolarDB 的 PostgreSQL 协议兼容
• 理解 Oracle 兼容模式的价值
• 认识多方言兼容策略

PolarDB 提供 PostgreSQL 兼容版本，支持 PostgreSQL 14/15 的协议与 SQL 方言，可复用 PG 生态（驱动、扩展、工具）。此外，PolarDB 针对部分 Oracle 用户提供 Oracle 兼容模式，支持 Oracle 常见语法、数据类型、函数与存储过程，帮助存量 Oracle 业务平滑迁移。这种"多方言兼容"策略让 PolarDB 既能服务 PG 生态，也能承接 Oracle 迁移需求。

兼容性策略扩大了 PolarDB 的适用人群。PG 兼容服务开源生态，Oracle 兼容服务存量企业客户，两者降低迁移门槛。

• 理解 DocDB 的文档型 KV 存储模型
• 掌握 Raft 在副本一致中的作用
• 认识强一致与分片的结合

YugabyteDB 的存储层 DocDB 是分布式文档型 KV 存储，将行/文档数据按主键分片为 tablet，每个 tablet 通过 Raft 复制多副本，写入需多数派确认，保证强一致。DocDB 同时支持 SQL（YSQL）与 NoSQL（YCQL）两种接口，底层共享同一套分布式存储。通过 Raft + 分片，YugabyteDB 在水平扩展的同时提供强一致与高可用。

YugabyteDB 借鉴了 Google Spanner 的思路，用 DocDB 做分布式 KV，Raft 做一致性，上面叠加 SQL/NoSQL 接口。强一致源于 Raft 多数派提交。

• 理解 YSQL 与 YCQL 的差异
• 掌握两种 API 共享 DocDB 存储
• 认识多模型数据库的价值

YugabyteDB 提供两种面向用户的 API：YSQL 是 PostgreSQL 兼容的关系接口，支持 SQL、事务、约束；YCQL 是 Cassandra 兼容的 NoSQL 接口，支持 CQL 语法与松散 schema。两者共享同一 DocDB 底层存储，可各自独立使用，也可在同一集群中并存。这使 YugabyteDB 既能服务传统关系型业务，也能服务 Cassandra 迁移场景。

多 API 共享单一存储是 YugabyteDB 的差异化。YSQL 承接关系型，YCQL 承接 NoSQL 迁移，降低生态迁移成本。

• 理解 xCluster 的异步复制语义
• 掌握 xCluster 的适用场景（异地、容灾）
• 认识与 Raft 强一致的差异

xCluster 是 YugabyteDB 的跨集群异步复制能力，在不同集群之间异步同步表数据，用于跨数据中心灾备、异地多活或数据湖等场景。与集群内 Raft 强一致不同，xCluster 是异步的，允许数据在目标集群有短暂延迟，因此跨地域延迟低但存在最终一致语义。它支持选择性复制特定表，并可通过状态监控跟踪复制进度。

xCluster 解决"跨集群异步复制"需求，与集群内 Raft 强一致互补：强一致保证单集群内，异步复制保证跨集群容灾，两者结合覆盖不同 RPO/RTO 需求。

• 理解 Citus 的 coordinator/worker 架构
• 掌握分布式表的选择与分布
• 认识分片与查询下推

Citus 是 PostgreSQL 扩展，把 PostgreSQL 变为分布式数据库。它通过 coordinator 节点接收查询，将大表（distributed table）按分布列（distribution column）哈希分片到多个 worker 节点，worker 存数据并执行子查询。查询时 coordinator 将 SQL 下推到相关 worker，尽量在本地完成处理，减少跨节点数据传输。Citus 还支持 reference table（小表在每个节点复制一份）配合 join 下推。

Citus 的分布式核心是"分片 + 下推"。分布列决定数据如何分布，设计好的分布列让 join 与聚合尽量在节点内完成，避免跨节点 shuffle。

• 理解 HTAP 双引擎架构
• 掌握优化器自动选引擎的机制
• 认识一致性读取与成本估算

TiDB 的 HTAP 由 TiKV（行存）与 TiFlash（列存）双引擎实现。写入与点查走 TiKV，分析型查询走 TiFlash。优化器根据表统计信息与访问代价，结合 hint 或自动化策略，在候选引擎中选择成本更低的一方执行。通过 TiFlash 的 Raft learner 同步，行存与列存视图保持一致，从而支持"一份数据两种读法"的混合负载。

自动选引擎依赖优化器的代价模型。TiDB 通过统计信息评估行存/列存的执行代价，选择成本更低的引擎，实现 HTAP 的透明化。

• 理解 Placement Rules 的标签与规则
• 掌握副本放置策略的应用
• 认识与 PD 调度结合

TiDB 的 Placement Rules 允许管理员为数据（表、分区或 Region）指定副本放置规则，结合节点标签（如机房、磁盘类型、地域）约束副本的物理位置。例如把某些表副本放在 SSD 节点、或限定副本分布在特定机房实现容灾。PD 根据这些规则调度 Region 副本，使副本布局符合要求。这为多机房容灾、冷热分离等需求提供了灵活控制。

Placement Rules 是 PD 调度的高级能力。它用"标签 + 规则"描述副本放置需求，让数据布局与物理拓扑解耦，实现按需的容灾与存储策略。

• 理解 Follower Reads 的读取机制
• 掌握 Stale Reads 的容忍度设置
• 认识强一致读与延迟的权衡

CockroachDB 19.1+ 支持 Follower Reads（20.1 起生产可用）与 Stale Reads。Follower Reads 允许从本地 follower 副本读取数据，只要数据满足时间戳的"bounded historical timestamp"保证即可，避免跨区域访问 leader 的往返延迟，但读取的是稍旧的数据（有界陈旧）。Stale Reads 则显式允许读取旧快照，通过 AS OF SYSTEM TIME 指定容忍度。两者都以牺牲部分实时性换取更低的读延迟，适合能容忍延迟读的应用。

这是"线性一致读 vs 低延迟"的权衡。Follower Reads 用有界陈旧交换更近的本地读，Stale Reads 用可配置陈旧交换更低延迟，是地理分布下优化读延迟的经典手段。

• 理解 Gateway Node 的请求路由职责
• 掌握 geo-partitioning 的数据放置
• 认识本地化读写优化

CockroachDB 中接收客户端请求的节点称为 Gateway Node，它负责将相关 range 的读写路由到持有 lease 的节点，并协调跨节点事务。Geo-partitioning 允许把不同数据行（按分区键）绑定到特定区域，通过 PARTITION BY 语法配合 zone config 让数据就近放置，从而让本地应用主要读写本地数据，降低跨区延迟。Gateway 路由 + geo-partitioning 共同实现地理就近的读写。

Gateway Node 承担路由与协调，geo-partitioning 让数据按地域分布，二者结合实现"数据就近、访问就近"，是跨区域低延迟的关键设计。

• 理解全局内存表的用途
• 掌握 TiProxy 的连接与负载均衡
• 认识 v7 新特性

TiDB v7+ 引入全局内存表（Global Memory Table），用于存放下发到多个 TiDB 节点共享的元数据/配置，实现跨节点一致的全局状态，减少各节点状态不一致问题。TiProxy 是 TiDB 的代理层，负责对 TiDB Server 进行连接管理与负载均衡、优雅运维（如滚动重启、连接迁移），并支持 SQL 级路由，提升集群协调与可用性。两者共同改善多节点集群的一致性与运维体验。

全局内存表解决多节点共享状态一致，TiProxy 解决连接分发与运维平滑。这些都是 TiDB 走向更大规模集群的工程优化。

• 理解 row-level TTL 的过期淘汰
• 掌握 CDC 的变更捕获
• 认识生产级数据管理能力

CockroachDB 的 row-level TTL 允许按行设置过期时间（基于时间戳列），由后台任务自动清理过期行，用于数据保留策略与成本控制。CDC（Change Data Capture）通过 rangefeed 捕获表的变更并输出到 Kafka 等下游，支持实时数据同步与流式处理。两者都已进入生产可用，为数据生命周期管理与实时集成提供内建能力。

row-level TTL 解决数据保留，CDC 解决实时变更输出，两者是数据库面向生产的数据管理能力。TTL 需要高效批量删除，CDC 需要低延迟变更感知。

• 理解单机分布式一体化的含义
• 掌握 OB Cloud 的部署弹性
• 认识从单机到分布式平滑演进

OceanBase 4.x 支持单机分布式一体化部署，即同一套代码既能以单机模式运行（降低入门成本），也能平滑扩展为分布式多副本集群。通过 OB Cloud 云服务，用户可以从单机起步，随业务增长在线扩容节点与副本，无需重新架构。这种设计让中小规模业务也能用 OB，同时保留向分布式演进的能力。

单机分布式一体化解决"分布式门槛高"的问题。它让用户从单机低价起步，数据量/并发增长后平滑横向扩展，兼顾易用性与扩展性。

• 理解 OBProxy 的代理职责
• 掌握读写路由与负载均衡
• 认识 SQL 解析与路由

OBProxy 是 OceanBase 的接入代理，负责接收客户端请求，解析 SQL 后根据分区路由规则将请求转发到持有数据副本的节点，并实现读写分离、负载均衡与故障转移。它能识别主备副本，将读请求路由到合适的副本，写请求路由到主副本，从而在保证一致性的同时分散负载。OBProxy 还支持连接池与会话保持。

OBProxy 类似一个"智能网关"，把 SQL 路由到正确节点，并完成读写分离与负载均衡。路由准确性（分区剪枝）直接影响性能。

• 理解 PolarDB 一写多读架构
• 掌握 RW/RO 节点的角色
• 认识共享存储下的读扩展

PolarDB 采用计算与存储分离，多个计算节点共享同一份存储。其中 RW（读写）节点接受写入并负责协调，RO（只读）节点挂载同一份数据用于读扩展。写入通过 RW 节点的 redo 下沉到共享存储，RO 节点按需读取，实现读流量水平扩展而不移动数据。应用可将读请求路由到 RO 节点，降低写节点的负载。

共享存储让"只加读节点不复制数据"成为可能。RW 负责写，RO 负责读，实现计算层的读写分离与读扩展，是 PolarDB 的核心优势。

• 理解 PolarFS 共享存储架构
• 掌握单副本多挂载的原理
• 认识存储与计算解耦

PolarDB 使用自研的 PolarFS 分布式共享存储，将数据以单一副本（多份冗余用于可靠性）存放在共享存储池中，多个计算节点通过网络挂载同一份数据。这样无需在每节点复制数据，新加只读节点即可获得数据访问，实现"计算扩展而不迁移数据"。PolarFS 提供高性能网络访问与一致性保证，支撑一写多读架构。

PolarFS 是 PolarDB 存储层的关键。它把"数据副本"从计算节点剥离，放到共享存储，让多节点共享读取，从而派生出一写多读的弹性架构。

• 理解 OB 的 LSM + Paxos 架构
• 掌握 TiDB 的 Raft 分片架构
• 对比两种分布式架构差异

OceanBase 采用"LSM-Tree 存储 + Paxos 多副本"，每个分区独立执行 Paxos 保证一致，存储用 LSM 支持高写入，副本是独立物理副本（各自日志）。TiDB 采用"Raft 分片 + 行存/列存"，TiKV 按 Region 分片用 Raft 复制，TiFlash 做列存。差异在于：OB 用 Paxos（多数派日志），TiDB 用 Raft；OB 的存储是 LSM-Tree，TiDB 底层 TiKV 用 RocksDB（也是 LSM）；OB 严格按分区做日志同步，TiDB 按 Region 分片。两者都支持水平扩展与强一致，但 OB 更强调单机写放大控制与高压缩，TiDB 更强调 HTAP 双引擎。

两者都是"分片 + 一致性协议 + LSM 存储"的典型 NewSQL 架构，只是协议（Paxos vs Raft）与 HTAP 落地方式不同。理解这些差异有助于选型与原理题作答。

• 理解计算与存储分离的原理
• 掌握共享存储下加节点的方法
• 认识数据不迁移的收益

PolarDB 把数据放在共享存储（PolarFS）上，计算节点本身不持有数据，只缓存热数据。新增只读（RO）节点时，只需挂载共享存储并初始化计算进程，即可访问同一份数据，无需复制或迁移数据，因此可以在分钟级新增计算节点。由于数据天然共享，横向扩展计算能力与数据迁移解耦，扩容效率高、数据一致性天然保证。

"数据不迁移"源于存储与计算解耦。共享存储让数据集中一处，计算节点随需挂载，扩容只是加计算进程，所以扩展快、无数据搬迁成本。

• 理解 Tablet 分片机制
• 掌握分片与负载均衡
• 认识水平扩展的原理

YugabyteDB 将表数据按主键范围（range）或哈希（hash）拆分为多个 tablet，每个 tablet 是多副本的独立单元，分布在集群节点上。通过将 tablet 分散到不同节点并动态迁移，数据量和负载可以水平扩展，节点变多时吞吐随之提升。tablet 的自动分裂与负载均衡由 master 管理，保证数据分布均匀。

Tablet 分片是 YugabyteDB 分布式的基础。水平扩展的本质是"数据分片 + 副本分布 + 负载均衡"，tablet 让数据分散到集群，节点越多吞吐越高。

• 理解 TServer 与 Master 的职责
• 掌握角色分离的意义
• 认识高可用与扩展

YugabyteDB 将节点分为 TServer 与 Master 两种角色。TServer 负责实际的数据存储与查询执行（tablet 服务），Master 负责集群元数据管理（表、分区、tablet 位置、负载均衡、Leader 管理）。角色分离让数据服务与元数据服务互相独立，Master 作为轻量元数据服务可独立扩展，TServer 专注数据读写，两者互不干扰，便于运维与高可用部署。

角色分离是分布式数据库的常见设计。TServer 承担数据径路，Master 承担控制面，分离后数据流量与元数据流量互不影响，且元数据可以独立容灾。

• 理解 reference table 与 distributed table 的概念
• 掌握 join 下推与数据复制
• 认识小表与大表的分表策略

Citus 中 distributed table 是哈希分片到多个 worker 的大表，数据按分布列分布；reference table 是复制到每个 worker 的小表（通常为维度表、配置表），每个节点都有完整副本。通过把大表做成 distributed table、小表做成 reference table，join 时小表可在每个 worker 本地参与，避免跨节点数据传输，从而优化 join 性能。

这是 Citus 的建模关键：大表分片、小表复制。reference table 让 join 在本地完成，distributed table 让大表分散，二者配合实现分布式 join 下推。

• 理解 MX 多协调节点模式
• 掌握 coordinator 与 worker 的角色
• 认识高可用与扩展

MX 模式是 Citus 的架构，允许任意节点既可作为 coordinator 处理查询，也可作为 worker 存储数据，实现协调节点与工作节点的统一。相比传统"单 coordinator + 多 worker"模式，MX 让多个节点都能承接查询路由，避免单 coordinator 成为瓶颈，并支持多 coordinator 高可用。coordinator 与 worker 通过清晰的职责划分与元数据同步，确保互不冲突地协同工作。

MX 模式解决单 coordinator 瓶颈，让所有节点都能路由查询。它通过让节点同时扮演 coordinator 与 worker 角色，实现负载均衡与高可用。

• 理解 colocation 的概念
• 掌握 colocate_with 的用法
• 认识共分布与 join 下推

Citus 中若两张 distributed table 使用相同的分布列且设置 colocate_with 指向彼此，则它们会被共分布（colocated），即共享相同分片布局，同一分片号的数据落在同一 worker。这样 join 时匹配行在同一节点，可在本地完成 join，避免跨节点 shuffle。colocate_with 通过强制关联表采用一致的分片与分布，极大提升 join 性能。

共分布是分布式 join 优化核心。让经常 join 的表按相同分布列分片，使 join 计算本地化，是 Citus 提升性能的关键手段。

• 理解 Citus 的并行分析能力
• 掌握查询下推与并行执行
• 认识 HTAP 混合负载

Citus 基于 PostgreSQL，天然支持行存的 OLTP 事务，同时通过分布式将分析查询拆分为多个子查询下推到各 worker 并行执行，聚合结果后返回，从而在多个 worker 上并行处理大表分析，提升分析吞吐。这种"分布式并行 + PG 事务能力"让 Citus 能在同一套系统上兼顾交易与分析，适合 HTAP 场景。worker 越多，并行度越高，分析查询越快。

Citus 的 HTAP 价值在于"分析并行"与"事务兼容"的结合。利用 PG 的丰富 SQL 能力 + 多 worker 并行，实现 OLAP 提速的同时保持 OLTP。

• 理解分区键与数据分布的关系
• 掌握跨分片事务的代价
• 认识分区键设计最佳实践

分区键（分片键）决定数据如何分布，若分区键选择不当，一个事务涉及的数据会散落在多个分片，产生跨分片（分布式）事务，需要协调多节点提交，延迟高、复杂度大。最佳实践是：选择业务访问以之为维度的、高基数的、分布均匀的列作为分区键；让频繁一起访问的数据（如同一用户的所有记录）落在同一分片，从而把多数事务变成单分片事务；避免使用低基数或热点列（如枚举值）作为分区键，防止数据倾斜。设计原则是"让事务尽量本地化，跨分片事务尽量少"。

分区键是分布式数据库性能的命门。跨分片事务比例越低，性能越好。通过选择均匀且与业务访问模式匹配的分区键，把相关数据共分片，能显著降低分布式事务成本。