呗老心眼极小聊到PostgreSQL高级性能调优，我发现一个特别常见的现象：很多人一上来就百度“PG优化参数大全”，然后照着把 shared_buffers 调到内存的四分之一，work_mem 调到 64MB，紧接着就以为大工告成。坦白讲，这种操作大多数时候能让系统“看起来健康”，但距离真正解决业务问题差得很远。前阵子我给一个跑在 PostgreSQL 18 上的业务系统做性能排查，从表面看 CPU 长期 80%、慢查询一大把，排查到最后发现，根源居然只是个低频维度表统计信息严重失真，导致优化器把嵌套循环硬生生用成了笛卡尔积。这种事情在真实环境里太常见了。这篇内容我不打算给你一份“照着抄就行”的参数清单，而是想把我自己平时做调优的完整思路——从定位瓶颈、读懂执行计划、设计索引，到持续监控——按实战顺序讲一遍。无论你是刚接手 PG 的新手 DBA，还是被慢查询折磨了许久的后端开发，读完应该都能形成一套自己的调优套路。
1. 先定位瓶颈，再谈优化：别让参数表背下所有锅
1.1 性能问题通常不是数据库单方面的事
我经常在技术群里看到有人问：“我 PG 18 跑得慢，是不是参数没优化？”这种问题几乎没法回答。因为“慢”可能发生在应用层、网络层、操作系统层，也可能发生在数据库内部。你连是一条 SQL 慢还是整体吞吐低都没说清楚，直接上参数调整就是在盲人摸象。
举个例子。有一次朋友公司反馈“数据库响应很慢”，我上去一看，CPU 使用率确实不高，内存也不紧张，但应用接口的 P99 延迟一直在涨。最后发现是应用侧连接池配置太小，几百个请求在排队等连接，数据库根本没啥压力。这种情况下你去调 PostgreSQL 的参数，再怎么调也调不出效果。
所以在动任何参数之前，我建议先回答三个问题：
- 是“全部查询都慢”，还是“某几条 SQL 特别慢”？前者多半要查资源瓶颈，后者优先查执行计划和索引。
- 是“偶尔突然慢一下”，还是“持续稳定地慢”？偶发慢要考虑检查点、autovacuum、锁等待；持续性慢大概率是查询计划本身有问题。
- 是“写入慢”还是“读取慢”？写入慢往往与 WAL、checkpoint、磁盘 fsync 相关，读取慢则更依赖内存命中率和索引结构。
这三个问题的答案，决定了你接下来的方向。别小看这一步，我见过太多人跳过这个环节，直接去改 max_connections，结果把问题从“慢”变成了“连不上”。
1.2 三张系统视图让你看清现状
PostgreSQL 在系统视图这块做得一直很厚道，不用装额外插件就能看到大部分关键指标。我上到一台新环境，第一步固定会查看这几张表。
先看 pg_stat_activity，它能告诉你当前所有会话在干什么。我常用的排查 SQL 是这样的：
sql复制SELECT pid, state, wait_event_type, wait_event, query, query_start, xact_start
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;
重点看两列：wait_event_type 和 wait_event。如果大量会话卡在 Client:ClientRead，说明应用拿完结果不继续提交请求，数据库在等客户端，问题大概率不在数据库；如果卡在 Lock:transactionid，那说明锁竞争已经非常严重了，需要顺着 pid 找到持锁会话。
再看 pg_stat_database，从实例维度了解各个库的整体健康度：
sql复制SELECT datname, xact_commit, xact_rollback, blks_read, blks_hit,
temp_files, temp_bytes
FROM pg_stat_database;
blks_read 和 blks_hit 的比值可以看出共享缓冲区的命中率，如果 blks_hit / (blks_hit + blks_read) 长期低于 99%，说明你的 shared_buffers 或者查询写得太糙，导致大量物理读。temp_files 和 temp_bytes 一旦明显增长，几乎是 work_mem 不够的实锤，排序和哈希操作溢出到了磁盘。
PG16 之后引入了 pg_stat_io 视图，到 PG18 这个视图已经很成熟了。它能按 backend type、object、operation 拆解 IO 层的读写、命中、驱逐情况，特别适合分析“到底是 checkpoint 在刷盘拖累性能，还是某个业务查询在猛读”。官方文档里有完整的列说明，你可以按需查阅。
1.3 连接数不是越多越好
关于连接数这个坑，我多说两句。很多应用没接连接池，随着用户量上涨就把 PostgreSQL 的 max_connections 从 100 调到 500、1000。代价不是一点点。
每一个连接在后端都是一个独立进程，而不是线程。进程多了，上下文切换成本和内存占用都会涨。更重要的是，在高并发下，连接数一旦超过 CPU 核心数的合理倍数，系统大部分时间都在切换进程上，而不是真正执行 SQL。你看到的 CPU 使用率很高，其实都在空转。
更合理的方案是：数据库侧保留 100 到 200 个连接足够，应用侧用 PgBouncer 或内部连接池做中转。即使真的需要更高的并发，也应该先评估 CPU 核数和每条查询的平均耗时。如果单条查询 10ms，一条连接一秒就能串行执行 100 次，没必要开几百条连接去抢 CPU。
如果你用 Docker Compose 部署 PostgreSQL 18，还要额外注意容器 --ulimit 和宿主机的限制。容器内看到的 CPU 和内存可能不是真实资源，连接数开大了，容器会先碰到进程数或文件句柄上限，报错信息还不直观。我建议容器环境下至少要把 max_connections 控制得比宿主机实际资源估算值更低，避免无意义的资源争抢。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 配置参数里真正值得动手的那几个值
2.1 shared_buffers 和 effective_cache_size 要一起看
既然说到了参数，那就把最核心的几项聊透。PostgreSQL 的参数非常多，但日常调优你真正需要关心的，翻来覆去就那么几个。
shared_buffers 是 PostgreSQL 自己管理的内存缓存，相当于数据库的“私有仓库”。业界比较通用的经验值是物理内存的 25% 左右，但这个经验有两个前提：一是同一台机器上没有跑其他吃内存的大型应用，二是你用的 PostgreSQL 版本较新。PG11 之后，shared_buffers 的设置已经可以在大内存服务器上放到十几 GB，而不会像老版本那样出现性能回退。在 PG18 上，我遇到 64GB 内存的机器时通常给 16GB。
effective_cache_size 是一个“估计值”，它告诉优化器操作系统层面大概还有多少缓存可用。这个值不是说你真的分配了多少内存，而是让优化器判断走索引时“回表”的成本有多高。你把它设得比实际可用内存大很多，优化器就会更倾向于选索引扫描；设得偏小，优化器容易高估随机读成本，倾向于全表扫描。
我见过不少人把 shared_buffers 调到 32GB，但 effective_cache_size 还留着默认的 4GB，结果优化器觉得“反正缓存不够，索引回表太贵”，明明有索引也走全表扫描。这两个参数必须搭配着看：effective_cache_size 建议设为操作系统可用文件缓存加上 shared_buffers 的总量，比如机器内存 64GB，其他应用占掉 16GB，那设为 40GB 到 48GB 是比较安全的。
2.2 work_mem 设多大才不挖坑
work_mem 是每个排序、哈希操作能用的内存上限。默认值 4MB 对于现代服务器来说确实很保守，尤其遇到一些复杂报表查询，排序数据量大，很容易溢写到临时文件，性能断崖式下跌。
但你别急着把它调到 256MB。这里有一个非常容易被忽略的乘法效应：work_mem 不是“一条 SQL 最多用这么多”，而是“每一个排序/哈希节点都可能用这么多”。一个并行度为 4 的查询，如果里面有排序节点又有哈希连接，每个 worker 各占一份，瞬间就可能吃进去 4 × 2 × 256MB 的内存。再叠加几个并发会话，内存很容易被打满。
要不要调大，应该结合 pg_stat_database 里的 temp_files 和 temp_bytes 来判断。如果临时文件用量不大，说明 work_mem 目前够用，不需要动。如果确实有很多排序溢写，我习惯从 32MB 或 64MB 开始，按查询场景逐步往上加，而不是一步到位。同时，建议对大查询单独用 SET LOCAL work_mem 在事务内指定更大值，而不是全局调高，这样既能满足那条复杂 SQL 的需要，又不会影响其他短小查询。
2.3 WAL 和 checkpoint：写入性能与崩溃恢复的取舍
如果你的系统是写入密集型，那么 WAL 相关参数会直接影响吞吐。max_wal_size 和 checkpoint_completion_target 的配合逻辑是：允许 WAL 积累到多少才触发 checkpoint，以及 checkpoint 刷盘要分散在多长时间内完成。
max_wal_size 设大了，checkpoint 触发的频率低，写入峰值性能会好看很多，但崩溃后恢复时要重放更多的 WAL，恢复时间长。反过来，设小了，checkpoint 频繁触发，每次都要刷大量脏页到磁盘，业务查询会周期性变慢。我通常把 max_wal_size 设为 4GB 到 8GB，这个量级对于大多数业务来说，既能保证恢复时间可控，又能让 checkpoint 周期不那么敏感。
还有一个经常被忽略的点是 wal_compression。如果业务写入的数据行重复度高、压缩效果好，开启它能让 WAL 体积明显下降，间接提高写入带宽。PG18 里相关设置在默认情况下已经比较合理，但如果你跑的是大字段多的表，值得专门关注一下。
2.4 autovacuum 才是长期健康的守护者
很多人调优只看查询性能，对 autovacuum 不上心，这是大忌。PostgreSQL 的并发控制机制决定了它必须靠 VACUUM 清理死元组，如果 autovacuum 跟不上写入速度，表会不断膨胀，索引效率下降，最终所有查询一起变慢。
我习惯把 autovacuum_vacuum_scale_factor 从默认的 0.2 调低一些，比如 0.05，然后配合 autovacuum_vacuum_threshold 一起看。这样对于千万级的大表，等死元组到 5% 就会触发一次，表膨胀会控制得更及时。autovacuum_analyze_scale_factor 同理，调到 0.02 左右，统计信息更新更频繁，执行计划就不会因为数据分布变化而长期失真。
这里有个容易忽略的细节：autovacuum 进程本身会消耗 IO 和 CPU，调得太激进会让业务高峰期出现周期性抖动。折中的做法是把 autovacuum_vacuum_cost_limit 稍微调大一点，让单次清理更快完成，而不是拖着更久。具体多少取决于你的磁盘能力，SSD 上可以给 2000 甚至更高，机械盘就别给太激进。
3. EXPLAIN 是调优地图：多半慢查询都死在执行计划上
3.1 五分钟看懂 EXPLAIN 关键行
不管参数配得多漂亮，SQL 写得烂，性能照样崩。所以我排查慢查询时，不会先调参，而是先做一个 EXPLAIN ANALYZE。执行计划是优化器的决策过程，你只有看懂它，才知道索引该建在哪里、SQL 该怎么改。
举一个典型例子：
sql复制EXPLAIN (ANALYZE, BUFFERS)
SELECT o.id, c.name, o.total_amount
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at >= '2025-01-01'
ORDER BY o.created_at DESC
LIMIT 100;
输出里你首先要看 actual time 和 rows，而不是 cost。cost 是优化器的估算值，actual time 是真实执行耗时。当两者差距非常大时，说明优化器的估算依据——也就是统计信息——出了偏差，或者参数导致成本模型错乱。
然后看 Buffers。shared hit=87 说明命中了共享缓冲区，shared read 说明经历了物理读。如果一条 SQL 执行了几百行却读了几万个 buffer，你要怀疑是不是锁定了太多页面，或者扫描范围太大。
最后看 Planning Time 和 Execution Time。如果 Planning Time 特别高，可能是表结构复杂、分区表太多；如果 Execution Time 高，问题集中在执行阶段。
3.2 最常见的三种低效执行计划
我看了大量慢查询之后，发现低效执行计划翻来覆去就是三类。
第一类是大表全表扫描。当查询条件能过滤掉 90% 以上的数据，但优化器还是选了 Seq Scan，通常原因有两个：要么没有可用索引，要么统计信息显示这列数据分布不够有区分度。解决办法不是硬加索引，而是先看统计信息是不是过期了。
第二类是嵌套循环 JOIN 的驱动表选反了。嵌套循环适合小表驱动大表，如果优化器把大表放外层，每取一行都要去小表里找匹配，代价会呈指数级增长。这时候要检查两边的 join 列统计信息，以及是否有合适的索引。
第三类是排序溢出。执行计划里出现 Sort Method: external merge 基本就是 work_mem 不够用，数据被排到磁盘上了。这种问题往往不是索引能解决的，而是需要优化 SQL 的排序方式，或者针对该查询单独调大 work_mem。
3.3 统计信息不准，比参数不对更要命
优化器做决策的依据是统计信息，统计信息一旦失真，再好的参数配置也白搭。
我在 PG18 上排查过一个很典型的案例。某张订单表有 1200 万行，其中一个状态列 order_status 的取值包括 completed、pending、refunded，其中 refunded 占比通常不到 1%。但由于前一天做了大批量导入，几百万条 completed 数据涌进来，而 autovacuum 还没来得及触发 analyze，优化器就还拿着旧统计信息，以为 refunded 的比例很高。
结果查询“最近退款订单”的时候，优化器估算了有 8 万行符合条件，直接选了全表扫描。实际上符合条件的只有 17 行。这就是典型的“统计信息与实际分布严重脱节”。
遇到这种情况，第一动作就是手动执行一次 ANALYZE，让统计信息回到正常状态。光解决这一次还不够，长期方案有两个方向：一个是把 default_statistics_target 调高一些，或者针对关键列单独设置更高的统计目标：
sql复制ALTER TABLE sales_order ALTER COLUMN order_status SET STATISTICS 1000;
另一个是把 autovacuum_analyze_scale_factor 调低，让数据分布变化后能更快触发 analyze。两种手段结合，才能避免同样的问题反复出现。
4. 索引策略：不是所有索引都叫 B-tree
4.1 什么时候索引反而帮倒忙
索引不是建得越多越好，这是老生常谈，但很多人还是会犯。每建一个索引，插入、更新、删除时都要额外维护一份，表的写放大就会增加。一个写多读少的业务如果堆了七八个索引，性能瓶颈会从查询转移到写入上，这属于典型的“为了优化而优化”。
还有一个容易被忽略的点：低选择性的列建普通 B-tree 索引没有意义。比如布尔字段、状态字段，如果某个值占了表中 90% 的行，优化器知道全表扫描成本更低，就不会走索引。即使强制走了索引，大量回表也会让查询比全表扫描还慢。
所以建索引之前，先想清楚一个问题：这个查询的过滤条件到底能把数据缩小到多少？如果过滤后还有 30% 以上的数据，那索引的价值不大，应该考虑其他手段，比如分区表、物化视图或者调整查询逻辑。
4.2 部分索引和表达式索引：小而美的实用派
这是我想特别推荐的两类索引，因为它们是 PostgreSQL 里性价比极高的武器，但很多开发者根本没用过。
部分索引是只对满足条件的行建立索引。还是拿订单表举例，如果业务里高频查询是“退款订单”，那可以这样建：
sql复制CREATE INDEX idx_orders_refunded ON orders (created_at DESC)
WHERE order_status = 'refunded';
这个索引的体积只有全表索引的几十分之一，维护成本低，查询速度还快。更重要的是，它给了优化器一个非常明确的信号：只搜退款订单时，走这个索引成本极低。
表达式索引适合查询条件里对字段做了函数处理的情况。比如用户登录经常用邮箱，而邮箱在库里存的是大小写混合，查询写成 WHERE lower(email) = 'xxx'，普通索引根本用不上。这时候需要：
sql复制CREATE INDEX idx_users_lower_email ON users (lower(email));
索引里存的是表达式的计算结果，优化器在遇到同样表达式时就能命中。
4.3 GIN 和 BRIN 的适用场景
B-tree 固然万能，但有些场景换用别的索引结构，效果是量级上的提升。
GIN 索引适合“一个字段包含多个值”的查询，典型包括数组类型、全文检索、JSONB 的包含操作。比如一张表有个标签数组字段，要查“包含标签 'postgres' 的所有文章”，普通 B-tree 一点忙都帮不上，GIN 却能快速命中。它的核心原理类似倒排索引，代价是构建和更新成本高一些，但在读多写少的内容型系统里非常划算。
BRIN 索引则是大表顺序扫描场景的奇兵。如果数据插入基本按时间顺序，比如日志表、订单流水表，查询又总是带时间的范围过滤，BRIN 索引能记录每个数据块范围内最小值和最大值，直接跳过不满足条件的块。它的体积比 B-tree 小几个数量级，构建极快，维护成本低。我曾在 2 亿行的日志表上建 BRIN 索引，查询走 BRIN 扫描后，扫过的块数从几万降到几百，效果极其明显。
4.4 向量检索场景下的 pgvector 索引选择
这几年 AI 应用越来越普及，PostgreSQL 上存向量数据的需求也越来越多，pgvector 是绕不开的扩展。在 PG18 上使用 pgvector，索引选择主要集中在 IVFFlat 和 HNSW 两种。
IVFFlat 的原理是先聚类再检索，构建速度快，内存占用低，但查询精度对参数 lists 比较敏感。HNSW 是基于图的近似最近邻算法，查询质量和召回率通常更好，但构建时需要更多内存，参数 m 和 ef_construction 直接影响索引质量和构建时间。
我个人的实践经验是：如果你的数据量在百万级以内，更看重查询精度，HNSW 是省心的选择。千万级以上或者内存有限，IVFFlat 通过合理调参也能达到不错的效果。建索引时，向量距离算子要和查询语义保持一致，否则索引不会被使用：
sql复制CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);
注意 HNSW 构建期间对 maintenance_work_mem 的消耗明显高于普通索引，必要时单独给这个参数设置一次较大值，避免构建中断。
5. 一次执行计划紊乱的排查：完整调优案例
说了这么多理论，我完整还原一个真实调优过程。这套思路你在 PG18 环境下可以直接照搬。
系统背景：某电商后台，订单表 sales_order 约 1200 万行，PG18 实例部署在 16 核 64GB 内存的机器上，业务反馈“退款订单查询”页面打开很慢，原来几百毫秒，现在要等 5 秒。
我接手后先查 pg_stat_statements，按总耗时排序，很快定位到这条 SQL：
sql复制SELECT * FROM sales_order
WHERE order_status = 'refunded'
ORDER BY created_at DESC
LIMIT 20;
然后执行 EXPLAIN (ANALYZE, BUFFERS)，关键输出大概是这样的：
code复制Limit (cost=0.42..68.32 rows=20 width=600) (actual time=4821.44..4821.47 rows=17 loops=1)
-> Sort (cost=0.42..68.32 rows=20 width=600) (actual time=4821.40..4821.42 rows=17 loops=1)
Sort Key: created_at DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on sales_order (cost=0.00..245167.88 rows=84321 width=600)
Filter: (order_status = 'refunded'::text)
Rows Removed by Filter: 11997832
看到这个结果，我第一反应不是去配索引，而是先问：为什么优化器会预估 refunded 有 84321 行，实际只有 17 行？这明显是统计信息偏了。
接着查 pg_stats：
sql复制SELECT null_frac, n_distinct, most_common_freqs, most_common_vals
FROM pg_stats
WHERE tablename = 'sales_order' AND attname = 'order_status';
果然，most_common_freqs 里 completed 的频率被估计到 0.98 以上，refunded 的频率远低于实际优化器使用的估算值。原因是前一天晚上批量导入了 800 万行 completed 状态的历史订单，导入后还没来得及触发 autovacuum analyze，统计信息仍然停留在导入前的分布。
处理过程分三步。
第一步，先让统计信息回到正常状态：
sql复制ANALYZE sales_order;
执行完后重新跑 EXPLAIN，查询已经改为走 Bitmap Index Scan，耗时会到 300ms 左右。
第二步，针对这张表的关键状态列提升统计精度，防止以后数据分布波动时再次低估：
sql复制ALTER TABLE sales_order ALTER COLUMN order_status SET STATISTICS 1000;
第三步，给这个高频查询专门建一个部分索引，不管是统计信息暂时偏差还是未来数据量增长，都能兜底：
sql复制CREATE INDEX idx_sales_order_refunded_created
ON sales_order (created_at DESC)
WHERE order_status = 'refunded';
几周后又回访了一次，这条查询始终稳定在百毫秒级别，没有再出现反复。这个案例里，真正的修复动作只有 ANALYZE，但长期保障靠的是统计策略和索引设计的组合，而不是某个参数的一锤子买卖。
6. 把调优变成常态：监控与压测要同时上
6.1 pg_stat_statements 和 auto_explain 一定要开
一次调优结束只能说明当下的问题解决了，不能保证以后不出新问题。所以在生产环境，我强烈建议从一开始就打开两样东西：pg_stat_statements 和 auto_explain。
pg_stat_statements 是慢查询排查的第一入口。它记录每条 SQL 的总耗时、调用次数、平均耗时、读写块数等信息，能让你快速找出“整体拖垮数据库的 TOP N 查询”。配置方式是在 postgresql.conf 里加入：
code复制shared_preload_libraries = 'pg_stat_statements,auto_explain'
注意 shared_preload_libraries 需要重启实例才能生效，所以这个配置要在初始化时就想好，而不是等出了问题再补。
auto_explain 的价值在于自动抓取慢 SQL 的执行计划。生产环境里你不可能随时手敲 EXPLAIN，而慢查询出现的那一刻，执行计划恰恰是最关键的证据。我通常设置：
code复制auto_explain.log_min_duration = '1s'
auto_explain.log_analyze = on
auto_explain.log_buffers = on
这样任何超过 1 秒的查询都会把带实际耗时的执行计划打到日志里，复盘时直接翻日志就行。
6.2 pgbench 压测时容易忽略的细节
压测同样是调优里不可缺的一环。PostgreSQL 自带的 pgbench 简单好用，但很多人用它的方式太粗糙。
先用它初始化测试数据：
bash复制pgbench -i -s 100 mydb
-s 100 表示生成 100 倍基础数据量的测试数据，大约 1000 万级别的记录，适合在有代表性的数据量下压测。
然后执行压测：
bash复制pgbench -c 50 -j 8 -T 300 -P 5 mydb
-c 50 是并发连接数，-j 8 是线程数，-T 300 表示压测 300 秒，-P 5 是每 5 秒打印一次进度。
这里有个细节：pgbench 默认跑的是 TPC-B 这种写入密集型负载，它只能验证一个方面。如果你系统主要是读多写少，最好自己写一个自定义 SQL 脚本再压。你甚至可以模拟真实业务里最重的几条查询，把它们放进 bench.sql，用 pgbench -f bench.sql 来跑，这样得到的数据才有参考价值。
压测过程中一定要同时监控系统的 CPU、内存、IO 和数据库的等待事件。只看 TPS 数据容易骗人，有时候 TPS 很高，但负载已经变成异常状态了。
6.3 调优后的回归对比很重要
最后说一个很多人不重视的习惯：调优前后一定要做对比记录。你在改参数之前，先量一组基线数据：几条关键 SQL 的耗时、高峰期 TPS、pg_stat_database 里的缓存命中率、pg_stat_statements 里 TOP5 的平均耗时。改完之后再跑一遍同样的测量流程，才能确认改动是真有效，还是只是心理作用。
我自己在排查时会用一个简单的表格记录每次改动的参数、原因、生效方式和前后对比。时间久了，这个东西的价值会远超你电脑里任何一份“优化大全”。
我在实际项目中养成的一个习惯是：每次调优都从“定位现象”开始，而不是从“改配置”开始。先把现象描述到能复现的程度，再顺着执行计划、统计信息、资源使用一层层挖下去，极少有查不清楚的问题。PostgreSQL 18 的能力已经非常强，大部分慢查询都不是数据库本身不行，而是它手头的统计信息、索引和资源参数被用歪了。如果你能把这套定位思路跑顺，很多疑难杂症都会变得很简单。