企业官网建设流程全解析

1. 为什么要用Citus给PostgreSQL做分布式

先聊点实际的。单机PostgreSQL跑得好好的，为什么要折腾分布式？我见过太多团队，业务涨到一定量级后，数据库开始出现三个典型症状：单表数据量破亿后，即使建了索引，查询延迟也开始变得不稳定；写入吞吐上不去，主库CPU常年打满，从库只能扛读，写路径始终是单点；最棘手的是，随着数据增长，VACUUM、索引重建、备份恢复这些运维操作的时间窗口越来越长，动不动就要锁表。

这时候一般有两条路：一是做应用层分库分表，自己维护路由规则和跨库查询，工作量大，而且一旦路由键设计失误，后面改起来要命；二是引入NewSQL或者分布式数据库，但迁移成本高，团队还得重新学习一套新体系。

Citus走的是一条中间路线：它不是一个全新的数据库，而是PostgreSQL的一个扩展，直接把单机PostgreSQL升级成分布式集群。装上Citus之后，你的数据库对外表现仍然是一个PostgreSQL，连接方式一样，SQL语法几乎不用改，psql照常用，ORM框架照常连，PG的生态工具（备份、监控、迁移）基本都能沿用。区别在于，数据会被自动分片到多个worker节点上，查询会被协调器节点自动改写、下推、汇总。

这篇博文就按照我从零搭建一套Citus集群的完整过程来写，包括环境规划、安装配置、分片设计、数据迁移、性能调优，以及实际运维中踩过的坑和排查思路。如果你正在考虑把PostgreSQL从单机引向分布式，或者已经在用Citus但觉得性能没达到预期，这篇文章可以给你一个完整的参考路径。

我用的版本是PostgreSQL 15 + Citus 12.1，这是一个相对稳定且匹配度较好的组合。操作系统是Ubuntu 22.04 LTS。后面所有操作步骤我都按这个环境来展开，版本差异带来的坑我会单独标注。

2. 动手之前，先搞清楚Citus的工作原理

2.1 协调器与工作节点各干什么活

Citus集群里有两类角色：协调器（Coordinator）和工作节点（Worker）。

协调器就是你在psql里连接的那个节点，对外看起来像一个普通的PostgreSQL实例。当用户发起一个查询时，协调器会做三件事：解析SQL，根据元数据判断涉及哪些分片；生成查询计划，把能下推的部分下推到对应worker节点执行；汇总结果，把各worker返回的部分结果做聚合、排序、关联，然后返回给客户端。

工作节点负责实际存储数据分片并执行查询。数据不是均匀乱撒的，而是根据分布列（distribution column）的哈希值，按分片数量取模映射到不同的分片（shard），再按照分片亲和性（shard affinity）分配到各个worker节点上。每个分片在物理上就是worker节点上的一个普通PostgreSQL表，表名形如orders_102008。

这个设计意味着，Citus并没有发明一套新的存储引擎，它复用的是PostgreSQL本身的存储、索引、MVCC机制。所以PostgreSQL的行存储、TOAST、WAL日志、流复制这些底层能力，在Citus里依然有效，只是多了一层分布式的调度和路由逻辑。

2.2 数据怎么分片，查询怎么下推

Citus支持两种数据分布方式：哈希分布和参考表。

哈希分布是最核心的方式。创建分布式表时指定分布列，Citus会根据分布列的值计算哈希，决定数据落到哪个分片。关键在于查询下推：如果查询带了分布列的等值过滤条件，比如订单表按user_id分布，查询WHERE user_id = 123，协调器可以直接定位到那个具体的分片去执行，这个叫单分片查询，性能接近单机；如果不带分布列条件，比如查最近一周的订单，协调器就得把查询广播到所有分片，各查各的再汇总，这个叫分布式查询，性能取决于分片数和worker数量。

参考表则是把数据量小、经常需要关联的表复制到所有worker节点上，每个节点都保存一份完整的副本。典型例子是省份表、类别表、配置表。关联时Citus可以在本地完成JOIN，避免跨节点数据传输。

这里有一个新手比较容易误解的地方：Citus并不是让所有查询都变快，它擅长的是“分布列点查+聚合下推”这种模式。如果业务查询几乎不带分布列过滤，又需要频繁跨分片JOIN，那Citus的收益会大打折扣。所以后面章节我会详细讲怎么选分布列，这个决策直接决定集群的性能上限。

2.3 为什么是Citus而不是其他方案

对比应用层分库分表，Citus最大的优势是透明性：不需要改应用代码，不需要维护路由中间件，分布式细节被封装在扩展内部。对比Greenplum这类分析型MPP数据库，Citus更偏向OLTP+轻量OLAP混合场景，它支持完整的PostgreSQL事务语义，包括ACID、外键（有约束条件）、索引、触发器，而Greenplum在事务处理上有明显短板。

选型时我建议自己对照这张表做评估：

3. 集群规划与版本选型

3.1 节点规划：三节点起步还是两节点够用

Citus没有强制要求必须多少个节点，最小拓扑是一个协调器加一个worker就能跑起来，这在测试环境没问题。生产环境我建议至少两到三个worker节点，这样分片可以分布到多个节点上，发挥并行能力，同时避免协调器单点故障——注意协调器本身也可以做流复制备库，但Citus的协调器自动故障转移需要额外的运维手段，MySQL的MHA那套思路在Citus里并不直接适用。

我这次搭建用的是三个节点：

• 192.168.10.10 — coordinator
• 192.168.10.11 — worker1
• 192.168.10.12 — worker2

三台机器都是4核8G的虚拟机，磁盘SSD。生产环境建议至少8核32G起步，因为Citus节点本质还是PostgreSQL，内存越充裕，shared_buffers和work_mem可以给得越大，排序和哈希操作的性能越好。

3.2 版本组合：PostgreSQL 15 + Citus 12.1

版本选择是很多人忽略但至关重要的一步。Citus是紧跟PostgreSQL主版本迭代的，不同版本的Citus对应的PostgreSQL版本范围不同。我选的是PostgreSQL 15 + Citus 12.1，理由有三点：

PG 15的public模式权限变更更合理，逻辑复制增强，pg_stat_statements等插件集成度更高。Citus 12.x对PG 15支持是官方明确列出的稳定组合。同时Citus 12开始，分片修剪和分布式查询优化器成熟度很高，很多之前需要手动hint的查询，现在能自动生成不错的执行计划。

提示：不要盲目追求最新版本。PG 16甚至17配合最新Citus虽然已经可用，但其行为和插件兼容性可能需要社区验证更多时间。我身边有同事在生产上用PG 16 + Citus踩过扩展编译问题。稳定优先。

3.3 网络与防火墙的准备工作

Citus的coordinator和worker之间需要互相通信，走的是PostgreSQL协议，默认端口5432。集群内部需要在防火墙放行5432端口，并且建议只允许集群内网IP访问。另外coordinator需要能SSH连接到各个worker（部分管理命令工具会用到），也一并放行。

一个比较容易踩的坑：如果启用了SELinux或者AppArmor，可能需要为PostgreSQL进程单独配置网络访问策略。Ubuntu默认的AppArmor对PostgreSQL没有额外限制，一般不需要管。

4. 从零开始搭建Citus集群

4.1 在所有节点上安装PostgreSQL 15

三个节点都需要安装PostgreSQL服务和Citus扩展，操作一致。Ubuntu 22.04默认软件源里带的PostgreSQL版本是14，要装15需要先添加官方APT源。

sudo apt update sudo apt install -y postgresql-common sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh -y sudo apt update sudo apt install -y postgresql-15 postgresql-client-15

安装完成后，PostgreSQL服务会自动启动，数据库数据目录在/var/lib/postgresql/15/main。先把服务停掉，后面改配置再启动。

sudo systemctl stop postgresql

4.2 安装Citus扩展

Citus官方APT源通常已经包含在postgresql-common脚本配置的源里，直接安装：

sudo apt install -y postgresql-15-citus-12.1

装完后检查一下扩展文件是否到位：

ls /usr/lib/postgresql/15/lib/citus.so ls /usr/share/postgresql/15/extension/citus.control

看到这两个文件就说明Citus已经安装成功，接下来需要在每个节点的postgresql.conf里加载Citus库，并设置相关参数。

4.3 配置节点的关键参数

编辑/etc/postgresql/15/main/postgresql.conf，在所有节点上做三块配置。

第一块是加载Citus：

shared_preload_libraries = 'citus'

第二块是通用的PostgreSQL性能参数，注意这里是初调，后面的性能调优章节还会细调：

max_connections = 200 shared_buffers = 2GB effective_cache_size = 6GB work_mem = 16MB maintenance_work_mem = 256MB checkpoint_completion_target = 0.9 wal_buffers = 16MB

第三块是Citus特有参数，coordinator和worker侧略有差异。我在所有节点上统一先配置：

citus.node_conninfo = 'sslmode=prefer' citus.max_worker_nodes_per_ha = 32

第三块里的citus.node_conninfo表示节点间通信的连接参数。如果PG启用了SSL，这里需要配置对应的SSL选项，没启用就用默认即可。

4.4 启动集群并建立节点关系

所有节点上的PostgreSQL服务启动：

sudo systemctl start postgresql sudo systemctl enable postgresql

然后切换到postgres用户，进入psql，先在coordinator上创建扩展：

sudo -u postgres psql

CREATE EXTENSION citus;

接下来在coordinator上录入worker节点。这个命令Citus会自动把元数据写入协调器的citus相关系统表，并且初始化与worker节点的连接：

SELECT citus_add_node('192.168.10.11', 5432); SELECT citus_add_node('192.168.10.12', 5432);

查看集群节点状态：

SELECT * FROM citus_get_active_worker_nodes();

如果返回两行记录，主节点列表里出现这两个worker的IP和端口，集群就已经建立成功了。这里要说一句，后期如果要把自动故障转移和节点管理交给专门的工具，可以考虑在协调器上启用citus.enable_metadata_sync、citus.replicate_reference_tables_on_activate这些参数，默认值在大多数场景下是合理的。

4.5 验证集群基本功能

先建一个简单的分布式表验证：

CREATE TABLE test_dist ( id bigint, val text ); SELECT create_distributed_table('test_dist', 'id');

然后插入数据并查询：

INSERT INTO test_dist SELECT g, 'value-' || g FROM generate_series(1, 10000) g; SELECT count(*) FROM test_dist; SELECT * FROM test_dist WHERE id = 12345;

通过EXPLAIN查看执行计划，如果出现类似Distributed Query、Custom Scan (Citus)这样的节点，说明查询确实走了分布式执行。

5. 数据建模与分布列设计

5.1 分布列选错，后面全是坑

Citus性能好坏的命门就在分布列的选择上。分布列决定数据如何跨节点分布，也决定哪些查询能够下推成单分片操作。

原则一：分布列应该是业务中最常见的高频等值查询条件。以订单表为例，如果业务大部分查询是“查某个用户的订单”，那么user_id是理想的分布列。如果按order_id分布，user_id过滤就无法裁剪分片，每次都要跑全节点。

原则二：分布列应该保证数据足够分散，避免数据倾斜。比如按gender分布就非常糟糕，男/女两个桶，数据只落在少数分片上。如果业务只有几千个大客户，但需要按客户维度做FK关联，这种场景需要评估是否需要重新建模。

原则三：需要JOIN的大表应该尽量用同一个分布列。Citus处理JOIN时，如果两边表都按相同的分布列分布，那么可以在本地节点完成匹配，不需要shuffle；否则协调器会执行重分布（repartition join），数据传输开销很大。

我见过一个真实的案例：有人把店铺的订单表按store_id分片，又把用户表按user_id分片，结果两边做JOIN的时候，Citus只能把所有表数据重分布一遍，8个worker跑一个JOIN查询耗时比单机还慢两三倍。

5.2 参考表的使用场景与注意事项

参考表适合：数据量小（几万行以内）；变化不频繁；需要和其他分布式表频繁JOIN。比如商品类目、区域配置、枚举字典。

创建参考表很简单：

CREATE TABLE regions ( id int primary key, name text ); SELECT create_reference_table('regions');

参考表会在每个worker节点上保留完整副本。新增节点时Citus会自动同步参考表数据。需要注意：参考表如果有外键指向其他参考表没问题，但如果引用分布式表，需要验证业务约束是否允许。

参考表的数据更新会触发所有节点同步，频繁写入参考表会成为性能瓶颈，所以它只适合低频更新的维表，不适合存放订单、日志这类持续写入的数据。

5.3 外键、唯一约束在分布式环境下的限制

Citus对分布式表的约束支持是有取舍的：

• 主键或唯一约束必须包含分布列。也就是说，如果表按user_id分布，唯一索引可以是(user_id, order_id)，不能只建order_id唯一索引。这是为了保证唯一性检查可以在单个分片内完成，不需要跨节点通信。
• 分布式表之间的外键要求：外键列必须等于被引用表的分布列。也就是说，如果orders按user_id分布，payments也要按user_id分布，然后外键orders(user_id) REFERENCES users(user_id)才被允许。
• 分布式表与参考表之间可以建外键，参考表作为被引用方没有限制。

这个限制让很多从单机迁移过来的应用需要调整建表语句。建议迁移前先梳理现有表结构，把不符合条件的约束找出来，评估是调整业务逻辑还是放弃某些约束。不要把外键满天飞的单机模型直接搬过来，Citus不是这么用的。

6. 数据迁移与分布式化改造

6.1 从单机PostgreSQL数据导出

常见的迁移方式是用pg_dump导出数据。这里要特别注意：先迁移表结构，创建分布式表，再导入数据，顺序不能反。如果在普通表里先导入大量数据再调用create_distributed_table()，Citus需要额外的数据重分布过程，耗时长且占用大量临时空间。

正确流程：

1. 在源库导出schema，不导出数据：

pg_dump -h 源库IP -U postgres -d 业务库 --schema-only -f schema.sql

2. 在Citus集群的coordinator上执行schema.sql，建出普通表。

3. 分析哪些表适合做分布式表，哪些做参考表，执行相应的转换命令：

SELECT create_distributed_table('orders', 'user_id'); SELECT create_reference_table('regions');

4. 数据导入。如果源库数据量在GB级别，直接用pg_dump --data-only导出，然后再psql导入coordinator即可。数据量更大时，建议用\copy按表分批导入，或者使用pg_dump --format=custom加上-j参数并行导出。

6.2 利用copy命令高效灌入数据

对于大表，COPY是最高效的导入方式。建议在源库先把数据按分片键排序导出，排序后的数据在Citus灌入时能减少分片切换的随机IO，提升不少速度。

psql -h 源库 -c "\copy (SELECT * FROM orders ORDER BY user_id) TO '/tmp/orders.csv' WITH CSV HEADER"

然后在coordinator上执行：

\copy orders FROM '/tmp/orders.csv' WITH CSV

如果数据量上百GB，单线程COPY可能比较慢，可以考虑按时间或者按分布列范围拆分文件，并行执行多个\copy会话。但要注意，并发COPY时coordinator和worker的CPU/IO都会升高，建议观察负载逐步加并发。

6.3 应用层的改造点

数据迁过去了，应用侧也不是完全零改动。主要有三个地方要注意：

连接串改为连接coordinator的地址和端口，而不是原来的单机PG。如果做了读写分离，需要额外配置负载均衡或故障转移方案。

高频写入的业务，插入语句最好显式指定分布列，不要让数据库自己去推断。虽然Citus支持从主键推断分布列，但显式指定查询计划更可控。

事务涉及跨节点操作时要重新评估。Citus支持分布式事务（通过两阶段提交协议实现），但跨节点的写事务性能远低于单节点事务。如果应用里大量使用跨分片的大型事务，性能会明显下降。我在项目中遇到过：一个批量导入逻辑在单机PG跑没问题，上Citus后发现每个事务要写多个分片，延迟从几十毫秒涨到几秒。后来改成按分布列分批提交，才恢复正常。

7. 性能调优：从参数到SQL的完整链路

7.1 分片数量怎么定：从规划到实测验证

分片数由citus.shard_count控制，默认是32。分片数不是越大越好，也不是越小越好。

先按规则估算一个基准值：每个worker节点的分片数建议在2到4之间。也就是说，3个worker节点的集群，初始分片数在6到12之间。分片数太少会导致单分片过大，数据不均衡；太多会增加协调器维护分片元数据的内存开销，某些查询计划生成也会变慢。

我这次3 worker的集群，设为citus.shard_count = 12，每个worker平均4个分片。创建分布式表时显式指定：

SET citus.shard_count = 12; SELECT create_distributed_table('orders', 'user_id');

验证分片分布情况：

SELECT nodename, nodeporter, count(*) FROM citus_shards GROUP BY 1, 2;

如果发现某个worker的分片数明显多，说明分片分配不够均匀。可以重建表或使用citus_move_shard()调整。注意，citus_move_shard()是重活，要在低峰期操作。

7.2 协调器与worker的参数差异化配置

协调器负责查询路由和结果汇总，它本身也存储元数据表。worker节点承担真正的数据存储和查询执行。两者的参数调优侧重点不同。

worker节点上重点配置：

• shared_buffers给到物理内存的25%，比如32G内存给8G。
• effective_cache_size给到物理内存的60%到70%，帮助优化器判断是否走索引扫描。
• work_mem在内存有余量的前提下，可以适当加大。排序、哈希关联都在这个内存里做，默认4MB在分析型查询下远远不够。我这边给到64MB，但要注意work_mem是每个排序操作单独分配，连接数高时会翻倍消耗内存，不要无脑调大。
• max_parallel_workers_per_gather设为2到4，让并行查询能跑起来。后台worker总预算max_parallel_workers也要相应调整。

协调器节点上的共享内存参数可以适当低于worker，因为大表数据不在本地，但shared_buffers也不能过小，因为元数据查询和结果汇总也消耗资源。

7.3 查询下推优化：避免昂贵的重分布JOIN

再看一遍执行计划，凡是出现Repartition Join的SQL，都值得审查。重分布JOIN是最费资源的操作：协调器把两张表数据按JOIN键全部重哈希分发，数据在节点间网络传输，集群再大也会被拖垮。

优化手段主要集中在三方面：

第一，检查两个JOIN表的分布列是否一致。不一致的，分析业务是否可以把两表调整到同一个分布列。比如orders和order_items本来就按order_id关联，那就都按order_id分布。

第二，小表指定为参考表。如果一个表只有几千行，与其做大表重分布JOIN，不如直接建参考表，让每个节点都有本地副本，JOIN就在本地完成。

第三，把高频查询条件下推。SQL条件里尽量带上分布列等值过滤。比如查询订单明细，业务上如果能带上user_id条件，即使order_id是主键，也建议把user_id一起放进WHERE，让Citus能精确裁剪分片。

7.4 大宽表与聚合查询的调优建议

Citus在OLAP场景下的优势在于能够把聚合计算下推。比如SELECT count(*), date_trunc('day', created_at) FROM orders GROUP BY 1，Citus会把每个分片都算一遍局部聚合，再汇总到协调器。

这类查询的调优重点：

• 排序和聚合最好在worker节点完成，协调器只做轻量汇总。
• 如果涉及高基数的GROUP BY，work_mem要足够大，否则worker排序阶段会溢写到磁盘，拖慢查询。
• 避免在SELECT列表里写SELECT *然后丢给协调器过滤，最理想的是在worker节点完成过滤和投影，减少网络传输量。
• 对经常做聚合分析的大表，可以创建物化视图，并由cron定时刷新。Citus对物化视图的支持比较好，但要注意物化视图如果建在分布表上，刷新时每条记录都要经过协调器调度，耗时较长。

7.5 实测一次从250ms到18ms的调优过程

说一个具体的优化案例。我负责的一个订单查询接口，单机PG只需要30ms左右，上了Citus集群后竟然要250ms。用EXPLAIN ANALYZE定位后发现两个严重问题：SQL里带了两个JOIN，其中一张小表没有建参考表，导致全节点重分布JOIN；查询条件里只带了order_id，没带user_id，Citus无法裁剪分片。

优化动作如下：

先看执行计划的关键部分：

EXPLAIN (ANALYZE, BUFFERS) SELECT o.id, o.total_amount, u.name FROM orders o JOIN users u ON u.id = o.user_id WHERE o.id = 1008611;

执行计划中显示Repartition Join，说明两个表没有使用同一个分布键。随后我做了两处调整：

第一，把users表改为参考表（它是典型的维表，量小且经常联合查询）。

第二，把查询条件改为：

SELECT o.id, o.total_amount, u.name FROM orders o JOIN users u ON u.id = o.user_id WHERE o.user_id = 123456 AND o.id = 1008611;

应用层在查询时想办法从会话上下文里带上user_id。改完后，执行计划变成了Router Query，只访问一个分片，延迟降到18ms。

这个案例说明：Citus不是装上就完事，分布列选择、查询写法、执行计划分析这三件事是持续投入才能拿回报的。

8. 常见问题与排查技巧实录

8.1 问题排查的常规路径

Citus集群出问题，我的排查顺序是：先确认是不是数据分布问题，再看执行计划是否下推成功，然后检查节点间的网络开销，最后考虑参数和资源瓶颈。

几个常用SQL：

-- 查看分片在节点上的分布是否均衡 SELECT nodename, count(*) FROM citus_shards GROUP BY 1; -- 查看当前正在运行的分布式查询 SELECT * FROM citus_stat_activity WHERE query ILIKE '%SELECT%'; -- 查看分片修剪是否生效：执行计划里有没有Shard pruning字样 EXPLAIN SELECT * FROM orders WHERE user_id = 123;

8.2 数据倾斜：为什分片ID特别大

有时候你会看到某个分片体积异常大，其他分片都很小。多半是分布列的选择导致哈希碰撞集中，或者业务数据本身分布极不均匀。排查方法：

SELECT nodeport, shardid, shard_size FROM citus_shards ORDER BY shard_size DESC;

如果倾斜严重，两个思路：一是更换分布列，换更高基数的字段；二是改用citus.rebalance_strategy中的策略，配合citus_move_shard()手动迁移独立分片。这里要注意，Citus 12的自动再平衡可能需要pro版本才开放全部能力，社区版建议手动干预。

8.3 连接数被打满，coordinator很快没响应

Citus集群里，coordinator需要同时维护与客户端和worker的PostgreSQL连接。后端连接数很容易被占满，表现为FATAL: sorry, too many clients already。

解决思路有几层：

• 提高max_connections只是表面解法，协调器内存会被堆满。
• 应用侧使用连接池，比如PgBouncer，把客户端连接收敛。注意PgBouncer要配置transaction模式，避免会话状态跨事务残留。
• 用citus.max_client_connections控制协调节点能够使用的后端连接数上限，避免worker连接不够用。

我实际踩过：没有连接池时，100个应用实例每个建10条连接，直接打爆了coordinator。上了PgBouncer（事务模式）后，后端连接稳定在40左右，集群立刻稳了。

8.4 修改分片数要谨慎，垃圾数据清理要注意

有些人在建表时没考虑好分片数，后面想改。Citus社区版不支持直接修改已存在分布式表的分片数，正确做法是：新建一张表，设置好citus.shard_count，把数据INSERT INTO ... SELECT或者\copy过去，再删掉旧表，改指向新表的视图或者应用连接。

还有一点容易忽略：Citus的分布式表删除后，worker节点上的物理分片可能不会立即删除干净。用DROP TABLE之后，检查一下worker上是否还有*_xxxxx的残留表，如果有，需要手动清理。我在一次释放存储空间时发现，由于之前删表和重建过于频繁，多个worker上残留了几百个无主分片，白白占用了几十GB磁盘。

8.5 VACUUM与膨胀问题在分布式环境下的表现

Citus每个分片都是一个独立的表，VACUUM的工作量成倍增加。高频更新的表，建议把autovacuum调积极一点，比如把autovacuum_vacuum_scale_factor从默认的0.2改小到0.05。

Citus 12对VACUUM做了并行化，可以同时清理多个分片，但coordinator上执行VACUUM时，仍然可能收到部分分片锁冲突的错误日志。遇到这种问题时，建议在低峰期对分布表执行：

VACUUM (ANALYZE, PARALLEL 4) orders;

因为Citus会把VACUUM操作下推到各个worker，让它并行执行，可以有效控制表膨胀。

8.6 节点宕机与恢复

worker节点宕机，coordinator上的查询会出现在线分片不可用错误。应对思路：

• 数据安全性上，建议每个worker开启流复制备库，Citus层面不做副本，靠PG原生的备库来保数据。
• 一旦worker宕机恢复，重启后确认citus扩展加载正常，再用SELECT citus_activate_node('worker_ip', 5432);重新激活节点。
• 如果某个分片确实损坏，先把该分片的元数据置为不可用：SELECT citus_mark_not_available('worker_ip', 5432);，优先保住集群整体可用，再恢复数据。

8.7 快速参考：常见问题速查表

9. 对这套集群的一些复盘和心得

做完整套从零搭建到调优的过程，我的感受是，Citus把分布式数据库的门槛降低了很多，但它的天花板其实是你的模型设计水平。分布列选对了，查询按着分布列走，集群可以很轻松扩展；选错了或者应用层随意写SQL，跑出来的性能甚至不如单机。

最后分享一个我后期运维时总结的习惯：每次新接入一个大表，都先跑一遍EXPLAIN，确认所有高频查询都走到了单分片路由（Router Query）或至少是下推执行（Distributed Query），而不是重分布JOIN。然后过一周再看一次分片大小分布。数据分布会随着业务变化而变化，定期体检比等出问题再救火踏实得多。