上周帮一个电商客户做数据库优化，他们在双11期间每小时要处理几百万笔订单，结果PostgreSQL扛不住了，查询响应时间从50毫秒飙到2秒多，慢查询日志里全是红色警报。老板急得拍桌子，DBA急得直冒汗。这种场景我见过太多，今天就把压箱底的优化经验全盘托出，从索引到配置，从查询到架构，一步步讲透。
先说索引这个最常见的坑。很多人以为建了索引就万事大吉，其实不然。我见过最离谱的是某金融系统，一张表上堆了17个索引，结果查询速度反而更慢。为什么？因为PostgreSQL的索引不是免费的午餐——每次插入、更新、删除都要重建索引，索引越多，写操作越慢。优化的关键在于精准打击：分析查询模式，找出最频繁的WHERE条件和JOIN字段，然后用B-tree索引覆盖它们。比如电商订单表，按时间查询占了80%，那就建一个的索引。但别贪心，一个复合索引胜过三个单列索引。记得用看看执行计划，索引命中率低于90%就得调整。
接下来是查询语句的优化，这是最立竿见影的环节。很多开发人员写SQL时根本不考虑数据库的感受，比如满天飞，明明只需要两三个字段，偏要把整张表拉出来。PostgreSQL的堆表结构决定了它读磁盘IO很贵，等于把整行数据从头扫到尾，内存和CPU都白费。还有更坑的：在WHERE条件里用函数包裹索引字段，比如，这会让索引失效，变成全表扫描。改成，索引就能派上用场。多表JOIN时，用小表驱动大表，避免笛卡尔积，这些基本功得刻进骨子里。
配置参数这块，很多人直接装完PostgreSQL就用默认设置，这等于开着一辆法拉利却在市区堵着。默认的只有128MB，对于生产环境来说杯水车薪。我一般建议设为服务器内存的25%，比如64GB内存的机器，给16GB。是每个排序操作可用的内存，太小会导致磁盘临时文件，太大又容易OOM，需要根据并发数动态计算。告诉查询规划器操作系统缓存有多大，设得合理能帮规划器选择更优的执行计划。影响VACUUM和索引重建速度，大表维护时调高到1GB以上，能省下大量时间。这些参数调完后，性能往往能提升30%以上。
连接池是个容易被忽视但杀伤力极大的问题。PostgreSQL是进程模型，每个连接对应一个进程，1000个并发连接意味着1000个进程在抢CPU和内存。我见过一个创业公司，服务器才8核16GB，却开了500个连接池，结果系统负载飙到20，查询卡成狗。正确的做法是用PgBouncer做连接池，把应用端的连接数控制在CPU核心数的2到4倍。比如8核服务器，连接池设成32个就够用了。这样既能充分利用硬件资源，又不会因为进程切换导致性能崩塌。别忘了调整参数，默认100太小，但也不要设成100，凡事得有度。
分区表是处理海量数据的利器。有个日志系统，每天产生2亿条数据，单表查询慢到没法用。我们用时间分区，按月创建子表，查询时只扫当月数据，速度提升了几十倍。PostgreSQL支持范围分区、列表分区和哈希分区，最常用的是按时间范围分区。创建分区表时要注意：主表定义好结构，子表用来创建，查询会自动路由到对应分区。还有一点，分区键必须出现在主键或唯一约束中，否则会报错。分区后的维护也简单，旧分区直接掉，不用删表，还能留着做历史归档。
VACUUM和ANALYZE这两个命令看似基础，但90%的DBA都没用好。PostgreSQL的MVCC机制意味着每次更新都会产生死元组，如果不及时清理，表会膨胀到原本的几倍大，查询性能直线下降。自动VACUUM默认配置太保守，是0.2，意味着20%的元组变脏后才触发，对于大表来说等得太久。我一般调成0.01或者直接设成固定阈值。ANALYZE更新统计信息，规划器依赖它做决策，如果统计信息过时，可能会选错索引甚至走全表扫描。建议在批量数据导入后手动执行一次，或者在业务低峰期用监控统计信息是否过期。
说个进阶技巧：物化视图。在报表查询中，经常有复杂的聚合计算，每次查询都要跑一遍，浪费大量资源。物化视图把结果存在磁盘上，查询时直接读，速度能快几个数量级。比如电商的每日销售额统计，用物化视图存储前一天的数据，每天凌晨刷新一次，白天查询时毫秒级响应。创建物化视图用，刷新用，这个并发刷新不会锁表，用户端无感知。但要注意，物化视图不是银弹，它适合写少读多的场景，如果数据变化频繁，刷新成本会很高。
其实PostgreSQL优化没有那么多玄学，套路就这些：索引精准、查询简洁、配置合理、连接控制、分区治理、定期维护。把这几点落到实处，大部分性能问题都能迎刃而解。记住一个原则：先做最小改动看效果，别一上来就大动干戈。比如先加个索引试试，如果不行再调参数，最后才考虑改架构。数据库优化就像修车，得一个一个零件排查，而不是直接换发动机。下次你的PostgreSQL卡顿，别急着怪硬件，先看看这些基本功做到位没有。
