聊到 PostgreSQL，很多人第一反应是“稳”，但稳不代表它天生就快。我见过不少团队，数据库装好就跑，默认配置一用到底，结果线上查询慢得像蜗牛爬，还怪 PostgreSQL 不行。其实这跟买车一样，出厂设置是为了适应各种路况，但你要天天跑赛道，总得调调悬挂和轮胎吧？默认配置下，PostgreSQL 的缓冲区只有 128 MB，共享内存分配得特别保守，连接数上限也就 100。这在开发环境还能凑合，生产环境一上并发，立马露馅。所以，优化第一步就是别犯懒，得把关键参数当成你的工具箱，一个个拧紧。
先说内存，这块最实在。PostgreSQL 有个核心参数叫 sharedbuffers，它决定了数据库能占多少内存来缓存数据。很多新手图省事，直接设成系统内存的 50%，结果把操作系统挤得喘不过气，反而不稳。我一般建议，如果机器有 16 GB 内存，sharedbuffers 设到 4 GB 左右就够了，留一半给操作系统和文件系统缓存。为什么？因为 PostgreSQL 依赖底层操作系统做 I/O，你全占了，系统自己没缓存，读写效率反而下降。还有一个参数叫 workmem，控制每个查询能用的临时内存，比如排序或哈希操作。这个值设太大，高并发时内存会爆掉；设太小，复杂查询就得写磁盘。经验是，先设成 4 MB 到 8 MB，跑跑业务看看，别一上来就搞 64 MB。记住，内存分配是平衡艺术，不是堆料。
磁盘 I/O 这块，很多人觉得现在都用 SSD 了，不用操心。但 PostgreSQL 的默认配置对磁盘并不友好。有个参数叫 effectiveioconcurrency，默认是 1，意思是它假设同时只能处理一个 I/O 请求。你用 SSD，完全可以把值提到 200 甚至更高，让数据库知道它能同时发起多个 I/O，这样并行扫描之类的操作就能跑起来。还有 randompagecost，默认是 4，这是针对传统机械硬盘的随机读取代价。换了 SSD，这个值可以降到 1.5 甚至 1.1，不然 PostgreSQL 会高估随机 I/O 的成本，导致它老走全表扫描的笨办法。我见过一个案例，调完这两个参数后，一个聚合查询从 15 秒缩到 3 秒，数据没变，只是让数据库“明白”了硬件的真实能力。
连接管理也是个坑。PostgreSQL 默认的 maxconnections 是 100，看起来够用，但每个连接都要消耗内存，尤其是排序和临时表。如果把连接数提到 500，光连接维护就能吃掉几 GB。更麻烦的是，连接数一多，上下文切换和锁争用会急剧上升，响应时间反而变慢。所以，别傻傻开高连接数，而是用连接池，比如 PgBouncer 或者应用层的连接池工具。把 maxconnections 设回 200 以内，让连接池在应用和数据库之间做缓冲。这样数据库的负担轻了，查询也能更专注。记住，数据库不是餐馆，不用每桌都配服务员，一个服务员管几桌效率才高。
查询计划是优化里最容易被忽略的软实力。PostgreSQL 默认的统计信息收集器是开着的，但它不会自动更新。你跑了大半年业务，数据量翻了几倍，统计信息还是半年前的，那查询优化器就像瞎子摸象，选错索引、走错路径。得定期跑 ANALYZE，或者调高 autovacuum 的采样率。有个参数叫 defaultstatisticstarget，默认是 100，你可以提到 500 甚至 1000，让统计信息更精确。代价是 ANALYZE 会慢一些，但换来的是查询计划更聪明。我调过一个系统，把统计目标提上去后，一个多表连接查询从 40 秒降到 6 秒，就是因为优化器终于知道哪张表数据分布更偏斜，选了正确的连接顺序。
WAL（预写日志）配置也值得聊几句。PostgreSQL 默认的 walbuffers 只有 16 MB，这对写入密集型业务来说太小了。如果写入量大，WAL 缓冲区很快填满，就得频繁刷盘，拖慢整体性能。我建议把 walbuffers 设到 64 MB 或者 128 MB，具体看你的写入负载。还有一个参数叫 checkpointcompletiontarget，默认是 0.5，意思是写检查点时尽量控制在 50% 的时间窗口内完成。你可以提到 0.9，让检查点写得更从容，减少磁盘 I/O 抖动。但别超过 0.9，不然两个检查点之间间隔太长，崩溃恢复时会很痛苦。记住，WAL 配置的核心是平衡写入吞吐和恢复速度，别光盯着性能，安全也得兜底。
自动化维护这块，很多人觉得 autovacuum 开着就完事了。但它的默认频率和强度对高负载业务来说往往不够。比如 autovacuumscalefactor 默认是 0.2，意思是表里 20% 的行变了才触发清理。这在大表上会导致死元组堆积，让查询变慢，甚至引发事务 ID 回卷风险。我习惯把 scalefactor 降到 0.05，同时设一个阈值，比如 1000 行，避免小表也等比例触发。还有一个参数是 autovacuumworkmem，默认是 -1，使用 work_mem 的值。如果清理工作内存不够，它会频繁读磁盘，拖慢整个系统。单独给它设个 64 MB 到 128 MB，让清理进程跑得顺畅。清理干净了，表膨胀就少，查询效率自然上来。
说个容易被忽视的细节：操作系统层面。PostgreSQL 依赖系统调用，比如内存分配和文件操作。如果系统的 vm.swappiness 设得太高，内核会把 PostgreSQL 的缓存页换到磁盘，造成严重抖动。我一般建议把 swappiness 降到 10，甚至 0，让数据库内存尽量留在物理内存里。还有透明大页（THP），很多 Linux 发行版默认开启，但 PostgreSQL 对这种大页管理并不友好，容易导致内存碎片和性能波动。建议直接关掉，使用传统的 4 KB 小页。文件系统选用 ext4 或 XFS，挂载参数加上 noatime，减少不必要的磁盘写操作。这些系统层的小调整，加起来的效果往往比单调数据库参数更明显。
优化这件事，说到底就是跟数据库“谈心”。你得告诉它你的硬件水平、业务是读多还是写多、数据长什么样。默认配置是万金油，但不是为你量身定做的。我见过太多人花大价钱升级硬件，结果数据库跑得一塌糊涂，才发现只是参数没调对。相反，有些团队在旧服务器上把参数拧到位，性能翻倍。所以，别指望一键优化工具，那玩意儿只能救急。真正靠谱的做法是：先监控、再调整、再验证。每次只改一两个参数，跑几天看看效果，别一次性全改完，出问题了也不知道是哪个惹的祸。毕竟，数据库优化不是百米冲刺，而是一场马拉松。
