干了大半辈子数据库运维，我最深的体会是：PostgreSQL这东西，配置好了是头顺毛驴，配置不好那就是头倔驴，踢你一脚你还得忍着。很多人上来就照搬网上的"优化模板"，sharedbuffers调成4G，workmem调到64M，结果跑起来比原来还慢，为啥？因为每台机器的硬件、每个业务场景的负载模型都不一样，你拿别人的药方给自己看病，不出事才怪。
先说说最容易被忽视的sharedbuffers。这参数决定了PostgreSQL在内存里缓存多少数据，但绝不是越大越好。我见过一台128G内存的服务器，运维大哥直接给干到64G，结果内核swap疯狂报警，查询延迟飙到几秒。为啥？因为PostgreSQL做checkpoint的时候要把脏页刷到磁盘，sharedbuffers太大，刷盘时间就长，期间所有写操作都得排队等着。我的经验是，这个值别超过物理内存的25%，而且一定要配合walbuffers、checkpointcompletiontarget一起调。你要是只动这一个参数，其他都不管，那等于换了轮胎没换轮毂，跑快了准散架。
再说workmem，这玩意儿是最容易"坑队友"的。它控制每个排序、哈希操作能用的内存，你要是给到几十M，那几十个并发连接同时排序，内存瞬间被吃干抹净。但你要是给太小，比如默认的4M，一个稍微大点的查询就得疯狂写临时文件，磁盘IO直接拉满。我一般建议从16M起步，然后观察pgstatdatabase里的tempfiles指标，如果临时文件数量持续增长，说明workmem偏小了，得往上加。但记住，这个参数是"每个操作"的内存限额，不是全局的，你算算最坏情况下并发连接数乘以操作数，别把内存算爆了。
maxconnections这个参数，很多人默认100就觉得够了，但真到了业务高峰期，连接数一上来，系统负载直接飙升。我碰到过最夸张的一次，应用层用了连接池，但连接池配置不对，实际撑起了300多个连接，PostgreSQL默认100早就爆了，一堆报错"too many connections"。解决办法不是简单调大这个值，而是先想清楚你的应用到底需要多少并发。如果你用PgBouncer之类的连接池，那数据库层可以小一点，比如200；如果应用直连，那得按峰值流量乘上1.5倍来设。但调大maxconnections的同时，你得同步检查内核的进程数限制、内存锁限制，否则PostgreSQL起都起不来。
还有个容易被坑的是checkpoint相关参数。默认的checkpointsegments（旧版）或者现在的maxwalsize，设置得太小，会导致checkpoint频繁触发，每次触发都要刷一堆脏页，性能抖动特别明显。我见过一个业务，每5分钟就卡顿一次，查了半天发现是checkpoint每5分钟触发一次，刷盘时间长达4秒，期间所有写操作全部阻塞。后来我把maxwalsize调大到4G，checkpointtimeout调到15分钟，加上checkpointcompletiontarget调到0.9，卡顿瞬间消失。但要注意，调大maxwalsize意味着崩溃恢复时间变长，你得在性能和可靠性之间找个平衡点。
effectivecachesize这个参数，很多人压根不知道它是干啥的。它告诉PostgreSQL操作系统层面能提供多少文件缓存，这直接影响查询规划器判断走索引还是全表扫描。如果你机器有64G内存，PostgreSQL的sharedbuffers只用了8G，那effectivecachesize可以设到48G左右。设得太小，规划器以为缓存不够，很多本该走索引的查询被优化成全表扫描；设得太大，规划器过于乐观，反而选错执行计划。我一般用这个公式：总内存减去sharedbuffers减去其他程序占用，再打个八折，基本靠谱。
还有autovacuum的配置，这玩意儿是PostgreSQL的"清洁工"，不配置好，表膨胀能把你磁盘塞满。默认的autovacuumscalefactor是0.2，意味着表里有20%的死元组才会触发清理。对一个大表来说，这20%可能就是几百万条记录，清理一次要跑好久，期间还跟业务抢IO。我习惯把scalefactor降到0.05，同时把autovacuumcostlimit调高到2000，让清理任务跑得更快。但你要注意，清理太频繁也会增加CPU和IO开销，所以得观察pgstatusertables里的lastautovacuum时间，找到合适的节奏。
说说日志和监控配置。很多人忽略logmindurationstatement这个参数，导致慢查询日志里全是垃圾信息。我建议设成1000ms，只记录超过1秒的查询，然后定期分析这些慢查询，看看是不是缺索引或者执行计划有问题。还有loglockwaits这个参数，把它打开，能帮你发现锁等待导致的性能瓶颈。我上次排查一个死锁问题，就是靠这个参数抓到了两个事务互相等锁的证据，否则光靠猜，得猜一整天。
回头再看整个配置过程，其实核心就一句话：别迷信参数模板，要理解每个参数背后的权衡逻辑。sharedbuffers是给缓存用的，workmem是给操作用的，max_connections是给并发用的，checkpoint是给持久化用的，每个参数都在跟你机器的物理资源博弈。你把每个参数都当成一个"旋钮"，先搞清楚它拧紧或者拧松会带来什么后果，再根据你的硬件和业务去调整。PostgreSQL的配置优化不是一锤子买卖，而是一个持续观察、持续调优的过程——你今天调的参数，可能明天业务模型变了就不合适了。所以，保持监控，保持记录，别怕折腾，这比任何现成的优化脚本都管用。
