PostgreSQL 的默认配置目标是“在任何环境下都能启动”而非“在任何环境下都能高性能运行”。1. shared_buffers —— 数据库的缓存心脏shared_buffers 16GB # 物理内存的 25% huge_pages try # 优先申请大页不足时回退普通页作用PostgreSQL 最重要的共享内存区域用于缓存数据页。与 Oracle 的 Buffer Cache 作用类似但 PG 依赖操作系统页缓存作为二级缓存构成独特的分层缓存架构。配置原则起点物理内存的25%读多写少、热数据集较大→ 可逐步调高至 30–40%配合pg_buffercache监控实际使用率写入密集型负载→ 建议保持 25%将更多内存留给操作系统页缓存以优化写入缓冲大页配置说明Linux 专用数据库服务器建议配置 HugePages可显著降低 TLB 压力。容器环境Docker / Kubernetes需额外验证 HugePages 支持情况部分容器运行时默认未开启大页。# 查看大页状态 cat /proc/meminfo | grep Huge # 须确保 HugePages_Total 0 且 HugePages_Free 0 # 若 HugePages_Total 0需在操作系统层面配置如 sysctl vm.nr_hugepages与 MySQL 的架构差异——为何不能设为 75%PostgreSQL 采用双层缓存架构shared_buffers 操作系统页缓存。当数据从磁盘读取时会同时缓存在两个层级。若shared_buffers设置过大同一数据页可能重复驻留两份造成严重的内存浪费。MySQL InnoDB 通常将更多内存集中分配给 Buffer Pool因此常见经验值为物理内存的 60% 75%。但是否使用操作系统页缓存取决于innodb_flush_method等配置。在 Linux O_DIRECT场景下可基本绕过 OS Cache而默认配置下仍会存在一定程度的双重缓存。-- 查看表缓存命中率若已稳定在健康阈值以上继续增大 shared_buffers 收益有限 SELECT sum(heap_blks_hit) / (sum(heap_blks_hit) sum(heap_blks_read))::float AS table_cache_hit_ratio FROM pg_statio_user_tables; -- 索引缓存命中率同样关键——命中率下降说明索引块正被频繁换出可能需调大缓存 SELECT sum(idx_blks_hit) / (sum(idx_blks_hit) sum(idx_blks_read))::float AS index_cache_hit_ratio FROM pg_statio_user_indexes;缓存命中率健康阈值参考值2. work_mem —— 排序和哈希操作的内存work_mem 16MB # 全局保守值作用指定单个排序、哈希操作如 ORDER BY、DISTINCT、HASH JOIN所能使用的最大内存。一旦超过此阈值操作将溢出到磁盘临时文件性能显著下降。核心认知每个操作独立分配一块内存非每条 SQL 共用一个复杂查询可能包含多个排序节点和多个 Hash Join 节点内存占用呈倍数叠加极端理论峰值≈work_mem × 并发连接数 × 每连接操作数但实际 OLTP 场景下多数查询不触发排序/哈希分配真实峰值远低于此理论值-- 检查是否在使用临时文件——排序或哈希操作内存不足的标志 SELECT datname, temp_files, temp_bytes FROM pg_stat_database WHERE datname current_database(); -- 若 temp_files 持续高速增长说明 work_mem 不足正确策略全局守小按需放大-- 对分析型用户单独调大 ALTER USER analyst SET work_mem 256MB; -- 对特定大查询会话临时调大 SET work_mem 512MB; SELECT ...; -- 执行大查询 RESET work_mem; -- 用完立刻恢复避免影响同会话后续轻量操作3. maintenance_work_mem 与 autovacuum_work_memmaintenance_work_memmaintenance_work_mem 512MB # VACUUM、CREATE INDEX、REINDEX 等使用注意自 PostgreSQL 9.4 起autovacuum worker 实际受autovacuum_work_mem控制默认未设置时回退到此值。手工执行的维护操作会足额分配。-- 手动对大表创建索引时临时调高 SET maintenance_work_mem 4GB; CREATE INDEX CONCURRENTLY idx_large ON large_table(col); RESET maintenance_work_mem;autovacuum_work_mem —— 大表维护的隐藏瓶颈autovacuum_work_mem 1GB # PG 9.4 可用大表环境建议单独设置大型表 VACUUM 时若autovacuum_work_mem过小默认回退到maintenance_work_mem可能导致索引清理需要更多轮次VACUUM 总耗时显著拉长死元组长时间无法回收对于 TB 级别大表单独设置autovacuum_work_mem通常比继续提高maintenance_work_mem更有效。-- 查看各表的 VACUUM 历史和死元组情况 SELECT schemaname, relname, n_dead_tup, last_vacuum, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC;4. effective_cache_size —— 告知优化器可用缓存总量effective_cache_size 48GB # 物理内存的 75%作用不分配任何物理内存仅作为提示值影响查询优化器的计划选择。effective_cache_size表示优化器认为可用于缓存数据页的总缓存容量包括PostgreSQL shared_buffers操作系统页缓存Page Cache实用取值方法专用数据库服务器建议设置为物理内存的 50% 75%混合部署服务器应扣除其他服务实际占用内存后估算不要简单根据当前时刻free -h的buff/cache数值直接计算因为该值会随系统运行状态动态变化。IO 与查询规划参数5. random_page_cost —— 随机 IO 代价系数SSD 必须修改# NVMe SSD推荐保守起步 random_page_cost 1.5 # SATA SSD random_page_cost 1.5–2.0 # HDD默认 4.0 random_page_cost 4.0作用告知优化器随机磁盘访问相对于顺序访问的代价倍数。顺序访问的基准值seq_page_cost默认为1.0。为何 SSD 环境必须调低默认值4.0是机械硬盘时代的经验值。在 NVMe SSD 上随机读取与顺序读取的延迟差距极小沿用默认值会导致优化器倾向于选择全表扫描而放弃更优的索引扫描。⚠️ 必须执行的验证步骤-- 1. 先更新目标表的统计信息 ANALYZE target_table; -- 2. 对比两种计划的真实执行性能 EXPLAIN (ANALYZE, BUFFERS) SELECT ...; -- 重点观察 actual time 与 buffers 的实际读/命中情况而非仅看计划形状风险提示NVMe 环境下设为1.0过于激进会使优化器认为随机访问与顺序访问代价完全一致。建议从 1.5 起步结合压测结果逐步微调。6. effective_io_concurrency —— 并发 IO 能力# NVMe SSD effective_io_concurrency 100 # SATA SSD effective_io_concurrency 50–100 # HDD effective_io_concurrency 2作用控制 Bitmap Heap Scan 节点可同时发起的异步 IO 请求数量。对于高性能企业级 NVMe实际生产环境中经常设置 200、256 甚至 300。具体取值应结合存储队列深度、内核异步 IO 能力和实际压测结果来持续验证。设置超过硬件最大队列深度时超出部分会被内核排队表现为收益递减但通常不会造成负面拥堵。-- 若业务负载中 Bitmap Heap Scan 极少出现调优此参数收益不大 SELECT schemaname, relname, seq_scan, idx_scan FROM pg_stat_user_tables WHERE seq_scan 0;WAL 与 Checkpoint 参数7. wal_buffers —— WAL 写入缓冲区wal_buffers -1 # 自动计算通常无需修改wal_buffers -1时PostgreSQL 自动计算规则为wal_buffers shared_buffers / 32同时受以下硬性限制最小值64KB最大值16MB因此只有在shared_buffers极小约小于 2MB时才会退化为最小值 64KB。现代生产环境通常保持默认值即可。-- 在大事务或逻辑复制等场景中监控 WAL 写入情况 SELECT wal_records, wal_fpi, wal_bytes FROM pg_stat_wal; -- 结合系统层监控综合判断 -- iostat观察磁盘写入延迟与队列深度 -- vmstat观察 IO 阻塞进程数量 -- PG16 可使用 pg_stat_io 获得更精细的 WAL 写入统计手动调大 wal_buffers如 32–64MB应在有明确监控证据的前提下进行无依据的调大只会浪费内存。8. checkpoint 相关参数 —— 平衡写入平滑度与恢复时间checkpoint_timeout 10min checkpoint_completion_target 0.9 max_wal_size 根据 WAL 产生速率计算 min_wal_size 4GB checkpoint_warning 30s # 默认值建议保留PostgreSQL 默认已启用checkpoint_warning 30s生产环境建议保留该默认值。若两次检查点间隔小于 30 秒PostgreSQL 将输出警告日志。核心权衡间隔较长 → 脏页写入更平滑IO 尖峰更少但崩溃恢复时间更长间隔较短 → IO 尖峰频繁但崩溃恢复更快max_wal_size 的计算方法-- 先估算 WAL 产生速率 SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), 0/0) / 1024.0 / 1024 / 1024 AS wal_gb_since_start; -- 或持续监控 pg_stat_wal 的 wal_bytes 增量经验上max_wal_size应明显大于一个 checkpoint 周期内产生的 WAL 量。实际生产环境通常预留1.5 3 倍缓冲空间避免 WAL 容量提前触发 checkpoint。例如预估一个周期产生 20GB WAL则max_wal_size可设为 30 60GB。⚠️max_wal_size设置过小会导致 WAL 频繁触及上限而强制触发检查点使checkpoint_timeout设置失效。DBA 必查监控项-- PG16 推荐使用 pg_stat_io可精细区分各类 IO 来源 SELECT backend_type, io_context, writes, fsyncs FROM pg_stat_io WHERE backend_type IN (background writer, checkpointer) ORDER BY writes DESC; -- pg_stat_bgwriter 主要用于兼容历史监控体系 SELECT checkpoints_timed, checkpoints_req, checkpoint_write_time, checkpoint_sync_time FROM pg_stat_bgwriter;重点观察如果checkpoints_req持续增长说明 WAL 提前达到max_wal_size当前checkpoint_timeout实际上并未生效。此时应优先扩大max_wal_size而非继续提高checkpoint_timeout。checkpoint_completion_target 0.9 -- 将脏页刷新分散到检查点间隔的 90% 时间内完成避免最后时刻集中刷盘引发 IO 尖峰配合 bgwriter 平滑写入曲线bgwriter_delay 200ms # 默认值后台写入进程轮询间隔 bgwriter_lru_maxpages 200 # 每轮最大刷盘页数从默认 100 适度调大bgwriter_lru_maxpages决定脏页在被检查点集中刷写前由后台写入进程先行清理的速度。若checkpoint_completion_target 0.9仍不足以平滑 IO适当调高此值可进一步分散写入压力。连接与并行参数9. max_connections —— 连接数非越大越好max_connections 200PostgreSQL 采用进程模型每个连接 fork 一个独立进程资源开销远大于线程模型的数据库。连接数过高的代价进程上下文切换开销急剧上升每连接额外占用 5–10MB 内存含连接私有缓存锁竞争与快照管理开销增加最佳实践# 数据库端保守设置 max_connections 100–300 # 前端部署 PgBouncer 连接池PgBouncer 配置示例pool_mode transaction # 事务级复用兼容性最佳 default_pool_size 20–50 # 按实际数据库承载能力调整非固定值 max_client_conn 1000 # 客户端到 PgBouncer 的最大连接数通过连接池将数千客户端请求收敛为少量数据库连接吞吐量不降反升。10. parallel workers —— 并行查询max_parallel_workers_per_gather 2 # PG 14 默认值通常无需修改 max_parallel_workers 8 max_parallel_maintenance_workers 4关键关系max_parallel_workers全局并行 worker 进程池上限max_parallel_workers_per_gather单个查询最多可从池中获取的 worker 数量若系统中通常有 3–4 个查询同时请求并行执行则max_parallel_workers至少应为per_gather × 预期并发数否则 worker 池会被耗尽后续查询降级为串行执行。验证并行是否实际生效EXPLAIN (ANALYZE, VERBOSE) SELECT ...; -- 在计划节点中出现 Workers Planned: X 且 Workers Launched: X 且 X 0说明并行生效11. synchronous_commit —— 写入持久性与性能的平衡synchronous_commit on # 默认值保证 ACID 的持久性作用控制事务提交时是否需要等待 WAL 刷新到磁盘后才向客户端返回成功。⚠️off或remote_write不影响数据最终持久化只影响事务返回客户端的时机。off模式下崩溃时最多可能丢失3 × wal_writer_delay默认 200ms即 600ms窗口内的事务。# 对延迟敏感的批量写入场景可全局设置 synchronous_commit off也可按会话级别精细控制SET synchronous_commit off; -- 执行批量导入或日志写入 RESET synchronous_commit;JITOLTP 环境下需谨慎评估的“优化”jit on # PG 11 默认启用JITJust-In-Time 编译主要提升聚合计算、分析型查询、数据仓库场景的性能。PG14 17 中 JIT 默认开启。对于高频短 SQL、高并发 OLTP 场景JIT 编译开销可能超过直接执行解释器计划的代价往往收益有限。建议通过pg_stat_statements和EXPLAIN ANALYZE观察实际收益后决定不要仅因为是 OLTP 就直接关闭首先监控高耗时 SQL 的执行计划观察 JIT 编译耗时占比如果确认 JIT 开销大于收益可全局关闭jit off若为混合负载可会话级按需启用SET jit on; -- 执行分析型大查询 RESET jit;pg_stat_statements比 auto_explain 更重要的扩展shared_preload_libraries pg_stat_statements, auto_explain生产环境定位性能问题的优先级不要直接开启大量 auto_explain 日志否则可能造成日志膨胀尤其在 OLTP 高并发场景下。-- 启用 pg_stat_statements CREATE EXTENSION pg_stat_statements; -- 快速定位 Top 5 高耗时 SQL SELECT queryid, calls, mean_exec_time, total_exec_time, query FROM pg_stat_statements ORDERBY total_exec_time DESC LIMIT5; -- 定位消耗临时文件最多的 SQL SELECT queryid, calls, temp_blks_written, query FROM pg_stat_statements ORDERBY temp_blks_written DESC LIMIT5;pg_stat_statements是生产环境日常巡检和应急排查的第一入口DBA 应确保该扩展始终启用。PostgreSQL 16/17 IO 监控体系pg_stat_ioPG16 开始引入pg_stat_io视图。相比pg_stat_bgwriter和pg_stat_database它可以更精细地观察各类 IO 操作的统计信息已逐渐成为现代 PostgreSQL 调优的核心监控视图SELECT * FROM pg_stat_io;pg_stat_io 的关键分类维度常用查询示例-- 按后端类型汇总 IO 读写量 SELECT backend_type, sum(reads) AS total_reads, sum(writes) AS total_writes, sum(extends) AS total_extends, sum(fsyncs) AS total_fsyncs FROM pg_stat_io GROUPBY backend_type ORDERBY total_writes DESC; -- 查看 autovacuum 的 IO 活动 SELECT io_context, reads, writes, extends, fsyncs FROM pg_stat_io WHERE backend_type autovacuum worker; -- 查看 WAL 写入统计 SELECT io_object, io_context, writes, fsyncs FROM pg_stat_io WHERE io_object wal;它能清晰展示 shared buffer 命中、WAL 写入、Checkpoint 写入、Backend 写入、Autovacuum 写入等各类 IO 的分布情况帮助 DBA 在优化 IO 参数时做到有的放矢。pg_stat_bgwriter建议作为兼容历史监控体系的补充视图。5 个常见误区误区一shared_buffers 设为物理内存的 75%❌错误将 MySQL InnoDB 配置经验直接照搬到 PostgreSQL。✅正解PostgreSQL 采用双层缓存模型。64GB 内存服务器设为 16–24GB 更为合理。可借助pg_buffercache查看实际缓存使用率来精准调优。误区二不加区分地全局调小 autovacuum 参数autovacuum_vacuum_scale_factor 0.2 # 默认20% 的表行变化才触发一张 1000 万行的表需要 200 万行变更才会触发 VACUUM这对大表过于迟缓。但全局调至 0.02 又会使小表被过度 VACUUM浪费 IO 资源。✅正解全局保留默认值仅对大表单独设置ALTER TABLE large_table SET ( autovacuum_vacuum_scale_factor 0.01, autovacuum_analyze_scale_factor 0.005, autovacuum_vacuum_cost_delay 0 -- 详见下方注意事项 ); -- 对超级大表推荐使用阈值替代百分比 ALTER TABLE huge_table SET ( autovacuum_vacuum_threshold 50000, autovacuum_vacuum_scale_factor 0 );关于autovacuum_vacuum_cost_delay 0仅建议用于专用数据库服务器、SSD/NVMe 环境且已完成压测验证的场景。在共享存储或 IO 资源紧张的环境下过于激进的 VACUUM 可能导致业务查询抖动、Checkpoint 延迟、磁盘队列积压。生产环境需谨慎评估。误区三work_mem 全局设置过大❌错误全局设置 256MB以为越大性能越好。✅正解work_mem 是每个操作的上限一个查询中多个排序/联接操作会叠加。全局保守设置 8–16MB对特定用户或会话按需调大用完即恢复。误区四max_connections 设得越大越安全❌错误为应对峰值直接设置 2000 个连接。✅正解实测 2000 连接下的吞吐量远低于 200 连接 PgBouncer 池化方案。控制数据库端连接数在 100–300由连接池管理客户端突发流量。误区五看到 Seq Scan 就盲目加索引❌错误执行计划中出现全表扫描Seq Scan就直接建索引。✅正解先执行ANALYZE确保统计信息是最新的使用EXPLAIN (ANALYZE, BUFFERS)查看实际执行时间与 IO 情况若查询返回表中超过 20% 的行Seq Scan 通常比索引回表更快关于 20% 阈值的重要说明20% 只是经验值。真实决策受random_page_cost、effective_cache_size、数据分布、SSD/HDD 类型、表聚簇程度等因素共同影响。不要机械套用固定比例而应以实际执行时间为准。关注Buffers: shared hit比例——若大部分是内存命中且执行时间可接受保持现状不要以计划形状替代实际性能数据作为判断依据。十、调优方法论参数调优永远排在 SQL 优化、索引设计、表结构设计之后。如果一个 SQL 原本需要扫描 1 亿行数据无论如何调整 shared_buffers、work_mem、random_page_cost都无法获得数量级性能提升。生产环境中80% 以上的性能问题来自 SQL 与数据模型设计而非 postgresql.conf 参数本身。调优五步法⚠️ 严禁一次性修改多个参数出现问题后无法定位根因。监控指标速查表生产环境必备检查清单安全底线必须设置# 1. 空闲事务超时 —— 防止长时间空闲事务导致表膨胀 idle_in_transaction_session_timeout 300000 # 5 分钟毫秒 # 2. 语句超时 —— 防止慢查询长期占用资源拖垮系统 statement_timeout 300000 # 5 分钟毫秒按业务最长语句时间调整 # 3. 锁超时 —— 防止 DDL/DML 被长时间阻塞 lock_timeout 60000 # 60 秒毫秒这三个超时参数是生产环境必须配置的安全底线。未提交的事务中空闲的连接会持有锁并阻止 VACUUM 清理死元组是生产环境最常见的表膨胀根源。完整的 postgresql.conf 参考# # PostgreSQL 14–17 生产环境配置参考64GB 内存NVMe SSD # ⚠️ 所有数值须结合自身负载通过压测验证 # ⚠️ shared_preload_libraries 中多个库以逗号分隔 # # ---------- 内存 ---------- shared_buffers 16GB huge_pages try work_mem 16MB maintenance_work_mem 512MB autovacuum_work_mem 1GB effective_cache_size 48GB # ---------- IO 代价 ---------- random_page_cost 1.5 effective_io_concurrency 100 # ---------- 连接 ---------- max_connections 200 # ---------- WAL 与 Checkpoint ---------- wal_buffers -1 checkpoint_timeout 10min checkpoint_completion_target 0.9 max_wal_size 60GB # 须根据实际 WAL 产生速率计算 min_wal_size 4GB checkpoint_warning 30s # 默认值建议保留 # ---------- 后台写入 ---------- bgwriter_delay 200ms bgwriter_lru_maxpages 200 # ---------- 并行 ---------- max_parallel_workers_per_gather 2 max_parallel_workers 8 max_parallel_maintenance_workers 4 # ---------- JIT ---------- jit on # 建议通过 pg_stat_statements 评估后决策 # ---------- 写入持久性 ---------- synchronous_commit on # 允许少量数据丢失的场景可设为 off # ---------- 超时安全底线 ---------- idle_in_transaction_session_timeout 300000 statement_timeout 300000 lock_timeout 60000 # ---------- 日志与扩展 ---------- log_min_duration_statement 1000 shared_preload_libraries pg_stat_statements, auto_explain auto_explain.log_min_duration 1000 auto_explain.log_analyze on auto_explain.log_buffers on调优效果验证# 初始化基准测试数据 pgbench -i -s 100 testdb # 运行基准测试32 客户端8 线程持续 5 分钟 pgbench -c 32 -j 8 -T 300 testdb # 对比调优前后的 TPS含连接建立开销和延迟分布总结PostgreSQL 没有万能参数 需根据具体机器配置应用业务特点进行调整。 PG18 的优化 1. 连接池:别让 PostgreSQL 当保姆症状: TPS 卡住不动,CPU 却很闲,延迟抖动厉害。解决方案:把 max_connections 控制在合理范围(200-400)在 PostgreSQL 前面加 PgBouncer,用 transaction 模式为什么有效: PostgreSQL 擅长执行查询,不擅长管理成千上万个空闲连接。先用连接池,再谈其他优化。2. Autovacuum 调优:比那些神奇参数更重要监控指标:查看 pg_stat_user_tables 的 n_dead_tup用 pg_total_relation_size vs pg_relation_size 检查膨胀关键配置:autovacuum_vacuum_scale_factor 0.05autovacuum_analyze_scale_factor 0.05autovacuum_max_workers 6autovacuum_naptime 10smaintenance_work_mem 2GB为什么有效: 及时的统计信息和更少的表膨胀,让每个查询计划都更聪明。3. Checkpoint 和 WAL:让 I/O 变得可预测平滑延迟的配置:wal_compression lz4max_wal_size 8GBcheckpoint_timeout 15minsynchronous_commit on为什么有效: 更大、更平缓的 checkpoint 和压缩的 WAL 减少了写入突刺。如果你用的是 NVMe,这个改动能明显降低 P99 延迟。4. work_mem:更快的排序,更少的临时文件经验法则: 按并发的排序/关联来设置,不是为单个查询设置。从 64MB 开始测试。判断依据: 用 EXPLAIN (ANALYZE, BUFFERS) 看是否有临时文件溢出,如果有就提高 work_mem。5. 并行查询:在该用的地方用读取场景配置:max_parallel_workers_per_gather 4max_parallel_workers 8max_worker_processes 16何时启用: 大范围扫描和聚合查询。何时关闭: 大量微小语句的 OLTP — 并行启动成本可能超过收益。6. JIT:分析场景开,OLTP 场景关简单规则:微查询的 OLTP → JIT 关闭复杂表达式的分析 → JIT 开启(默认),实测验证jit onjit_above_cost 200000 # OLTP 场景可以调高7. 缓存三角:共享缓存、OS 缓存、有效缓存配置示例:shared_buffers 8GB # RAM 的 25% 是安全起点effective_cache_size 24GB # 给规划器的提示,包含 OS 缓存为什么重要: 合理的大小能告诉查询规划器,索引计划是否真的能保持热度。8. 索引维护:比硬件升级更有效反复验证有效的做法:为热点读取添加覆盖索引(INCLUDE 列)对时间追加表(日志、事件)使用 BRIN 索引如果删除旧数据,按时间分区 — VACUUM 变得轻松对倾斜谓词大胆使用部分索引9. 查询优化:最后 20% 的工作,感觉像 80% 的提升三个快速修复:把 SELECT * 替换为具体列名在应用层消灭意外的 N1 查询对重复查询使用预编译语句10. 存储和内核:设置一次,长期受益Linux 默认值检查清单:文件系统:xfs 或 ext4,在 NVMe 上都很稳I/O 调度器:快速 SSD 用 none大页:关闭透明大页,保证可预测性CPU 调速器:专用数据库节点用 performancePostgreSQL 18 的实际改进更智能的读取路径: PostgreSQL 18 在大扫描和混合流量下更稳定,不容易抖动。实测中,用相同配置从早期版本升级后,吞吐量更平稳。更安全的默认值: 容易踩坑的地方变少了,意味着更少的为什么卡住了?的深夜排查。规划器和并行优化: 在统计信息新鲜的情况下,宽查询的并行计划选择更自信。配合调优的 work_mem,大查询无需改代码就能加速。(但仍然需要良好的统计信息和 vacuum)一周见效的最小化方案在前面加 PgBouncer(transaction 模式)处理嘈杂的应用调优 Autovacuum:降低 scale factor,提高 worker 数量平缓 Checkpoint:更大的 max_wal_size, LZ4 压缩合理分配内存:shared_buffers 和 work_mem 消除溢出JIT 开关:微查询关,分析开适度并行:在分析节点上尝试,监控 P95补上缺失的索引:pg_stat_statements 里最耗时的查询在呼唤它如何验证效果找到真正的问题查询:SELECT query, calls, total_exec_time, mean_exec_time, rowsFROM pg_stat_statementsORDER BY total_exec_time DESCLIMIT 10;证明执行计划是好是坏:EXPLAIN (ANALYZE, BUFFERS, VERBOSE)SELECT ... ;捕获溢出:SHOW work_mem;-- 逐步提高-- 在 EXPLAIN ANALYZE 中查找 Disk: 行观察 Autovacuum 工作:SELECT relname, n_dead_tup, vacuum_count, autovacuum_countFROM pg_stat_user_tablesORDER BY n_dead_tup DESCLIMIT 15;postgresql.conf 起步配置# 连接max_connections 300# 内存shared_buffers 8GBwork_mem 64MBmaintenance_work_mem 2GBeffective_cache_size 24GB# WAL 和 Checkpointwal_compression lz4max_wal_size 8GBcheckpoint_timeout 15minsynchronous_commit on# 并行max_parallel_workers_per_gather 4max_parallel_workers 8max_worker_processes 16# JIT(根据负载调整)jit onjit_above_cost 200000每次只改一个参数,重复测试三次。