当业务从几万用户增长到几千万用户时，数据库架构的每一次调整都牵一发动全身。PostgreSQL近年来在国内互联网公司的接受度明显提升，不少团队在订单、账务、风控、日志分析等核心场景下用它替换了原有方案。要让PostgreSQL真正扛住大流量，光会装一个数据库实例是远远不够的，需要从架构分层、参数配置、SQL治理等多个维度做系统性设计。本文结合一线实践经验，把这些关键环节逐一拆开讲清楚。
一、互联网公司常见的PostgreSQL部署架构
单机PostgreSQL在小流量下没有问题，但互联网业务通常要求高可用和读写分离，因此生产环境的第一步是搭建主从复制架构。PostgreSQL通过WAL（Write-Ahead Log）实现物理流复制，主库将WAL日志异步或同步地推送到备库，备库持续回放日志保持数据一致。异步复制性能好但可能丢少量数据，同步复制数据安全但会增加写入延迟，实际使用中常见做法是一主一同步备加若干异步备库，兼顾安全与性能。
第二个关键组件是连接池。PostgreSQL的每个连接对应一个进程，进程创建和上下文切换的成本比MySQL的线程模型高得多。如果应用直连数据库，几千个并发请求很容易把实例打挂。标准做法是在数据库前面加一层PgBouncer，它以轻量模式运行，用少量真实连接服务大量客户端连接，事务级别的连接复用效果最好。
# PgBouncer核心配置示例 [databases] mydb = host=127.0.0.1 port=5432 dbname=app_db [pgbouncer] listen_addr = 0.0.0.0 listen_port = 6432 pool_mode = transaction ; 事务级复用，吞吐最高 max_client_conn = 10000 ; 客户端最大连接数 default_pool_size = 100 ; 每个数据库的真实后端连接数
当单实例写入能力达到上限时，就需要水平拆分。Citus是PostgreSQL生态中最常用的分布式扩展，它把表按分片键哈希或范围分布到多个节点，查询时自动下推到各个分片并行执行。对于订单这类按用户维度查询的业务，选择user_id作为分片键，可以让绝大多数查询只命中一个分片，扩展性非常好。另一种做法是应用层按业务模块垂直拆库，再配合逻辑复制做数据同步，适合历史包袱较重的系统。
二、高并发场景下的性能优化实战
性能优化的第一步永远是找到慢在哪里。借助pg_stat_statements扩展可以统计每类SQL的调用次数、总耗时、缓存命中率，这是定位慢SQL最直接的工具。拿到问题SQL后，用EXPLAIN (ANALYZE, BUFFERS)查看真实执行计划，重点关注是否走了预期索引、估算行数与实际行数是否偏差过大、是否出现了嵌套循环放大等问题。估算偏差大通常意味着统计信息过期，手动执行ANALYZE往往能立刻改善。
索引设计是PostgreSQL优化中回报率最高的环节。除了常见的B-tree，PostgreSQL原生支持GIN、GiST、BRIN、哈希等多种索引类型。GIN索引适合JSONB字段和数组、全文检索；BRIN索引对时序类大表（按时间递增写入）占用空间极小，代价几乎可以忽略；部分索引和表达式索引则可以精准覆盖业务查询模式，比如只为未删除的订单建索引：
-- 部分索引：只为活跃订单建立，索引体积大幅减小 CREATE INDEX idx_orders_active ON orders (user_id, created_at) WHERE status != 'deleted'; -- GIN索引：支持JSONB字段的高效查询 CREATE INDEX idx_extra_info ON orders USING gin (extra_info jsonb_path_ops); -- BRIN索引：适合按时间追加写入的大表 CREATE INDEX idx_log_time ON access_log USING brin (created_at);
参数调优同样重要。shared_buffers一般设置为机器内存的四分之一；work_mem控制排序和哈希操作的内存，设置过大在高峰期容易触发OOM，建议保持在几十MB并通过连接池限制总连接数；effective_cache_size告诉优化器操作系统缓存有多大，直接影响执行计划选择；max_wal_size调大后可以减少checkpoint频率，降低写入抖动。另外，autovacuum的参数在写多读少的表上要适当放宽阈值，避免表膨胀和事务ID回卷风险。
三、稳定性保障：备份、监控与避坑经验
备份策略上，主流方案是基础备份加WAL归档。用pg_basebackup定期做全量备份，同时配置archive_command把WAL日志持续归档到对象存储，即可实现任意时间点恢复（PITR）。建议对备份做定期恢复演练，很多团队的备份在真正需要恢复时才发现已经损坏，这类教训代价极高。
监控层面需要覆盖几个核心指标：复制延迟（pg_stat_replication中的replay_lag）、连接数与等待事件、表和索引的膨胀率、慢查询数量、缓存命中率。常用的监控方案是pg_exporter配合Prometheus加Grafana，告警规则要覆盖主从延迟超阈值、磁盘空间不足、长事务、死锁等场景。长事务尤其危险，它不仅持有锁，还会阻止vacuum清理死元组，是表膨胀最常见的元凶。
最后分享几个高频踩坑点。第一，务必避免在业务高峰期做大表的DDL，虽然新版本支持了并发建索引，但部分操作仍会锁表，建议用CREATE INDEX CONCURRENTLY并放在低峰期执行。第二，字符串比较要注意编码和排序规则（collation），从MySQL迁移过来的团队容易发现查询结果顺序或索引行为不一致。第三，事务级连接池模式下不能用SET设置会话级参数、不能使用临时表和预编译语句名跨事务复用，这些都会引发诡异报错。第四，升级版本前一定要读release note，大版本升级建议通过逻辑复制做滚动迁移，停机窗口可以压缩到分钟级。
总体来看，PostgreSQL在互联网公司的大规模实践是一条系统工程之路：架构上主从加连接池是标配，数据量再大就引入分布式扩展；性能上以慢SQL治理和索引设计为主线，配合合理的参数配置；稳定性上靠备份演练和完善的监控体系兜底。把这些环节做扎实，PostgreSQL完全有能力支撑亿级用户量的核心业务。
PostgreSQL大规模部署性能优化修改时间：2026-09-13 00:04:38