Oracle老鸟眼里的PostgreSQL运维那些事儿，聊聊优化和坑

（来源：墨天轮《Oracle老鸟眼里的PostgreSQL运维那些事儿，聊聊优化和坑》）

作为一个在Oracle数据库领域干了十多年的老手,刚开始接触PostgreSQL运维的时候，感觉就像是开惯了自动挡汽车的老司机，突然要去摆弄一辆手动挡，虽然都是四个轮子都能跑，但很多操作和感觉完全不一样，今天我就聊聊从Oracle转过来，看PostgreSQL运维时特别关注的优化点和遇到的那些“坑”。

首先得说最大的感受,PostgreSQL的架构和Oracle很不同，Oracle很多东西是“黑盒”，Oracle公司帮你做了很多底层决策，你主要是在外面调参数，但PostgreSQL更“白盒”，给你很多自由，但也意味着很多责任得自己扛。（来源：文中关于架构哲学的对比）在Oracle里，表空间管理、内存分配，引擎内部帮你优化了不少，而PostgreSQL里，你需要更清楚地知道数据在磁盘上是怎么存的，内存是怎么用的，这种自由度是双刃剑，玩得好性能飞起，玩不好就是给自己挖坑。

说到优化,我第一个想提的是内存配置，这和Oracle的思路差别很大，Oracle有个巨大的SGA（系统全局区），基本上重要的东西都往里塞，PostgreSQL的核心是共享缓冲区（shared_buffers），但它并不是缓存越多越好。（来源：文中关于shared_buffers的讨论）刚开始我习惯性地按Oracle的思路，把机器一大半内存都分给shared_buffers，结果性能反而上不去，后来才明白，PostgreSQL严重依赖操作系统自身的缓存（OS Cache），如果把大部分内存都给了shared_buffers，反而会挤占OS Cache的空间，导致磁盘IO变多，这个“坑”让我印象深刻，通常建议是shared_buffers设内存的25%左右，剩下的留给操作系统去高效缓存数据文件。

第二个优化重点是 vacuum，这是PostgreSQL特有的一个东西，也是从Oracle过来最需要适应的概念之一。（来源：文中对VACUUM机制的着重说明）Oracle用UNDO机制来处理数据更新和删除，旧版本数据放在专门的地方，读写互不干扰，但PostgreSQL用的是多版本并发控制（MVCC），当你更新或删除一行数据时，它并不是直接删掉旧数据，而是标记为“过期”，这些过期的“死元组”就留在了数据页里，需要靠VACUUM这个“清扫工”来回收空间，如果VACUUM不及时，表就会越来越“胖”（膨胀），不仅占地方，查询速度也会慢得像蜗牛。

这引出了运维中的一个大坑：忘记配置或没管好自动VACUUM（autovacuum），在Oracle里，你基本不用操心UNDO空间自动回收的事，但在PostgreSQL里，你必须把autovacuum调教好，我曾经遇到过一张频繁更新的大表，因为autovacuum的触发阈值设得不合适，它一直没自动清理，结果死元组堆积如山，一个简单的查询都要跑几分钟，最后不得不手动在业务低峰期搞了个大扫除（VACUUM FULL），才把表救回来，监控表的膨胀情况，根据业务特点调整autovacuum的参数（比如autovacuum_vacuum_scale_factor），是PostgreSQL运维的日常必修课。

第三个点是统计信息，和Oracle一样，PostgreSQL的查询优化器也依赖统计信息来生成好的执行计划，但PostgreSQL的自动统计信息收集（autovacuum进程也负责这个）可能不如Oracle的那么“激进”。（来源：文中提及的统计信息重要性）对于数据变化非常快的表，如果统计信息更新不及时，优化器可能会选错索引，或者用了糟糕的连接顺序，导致慢查询，这时候可能就需要手动去运行ANALYZE命令，或者调整表级的统计信息收集参数，这个“坑”提醒我，不能完全相信默认设置，要盯着点执行计划的变化。

最后聊聊备份恢复，Oracle有RMAN这么一套成熟的利器，PostgreSQL的物理备份靠的是基础备份（pg_basebackup）加上WAL（预写日志）归档，逻辑备份用pg_dump。（来源：文中对备份恢复工具的简述）概念上不难理解，但坑在于细节和测试，WAL日志归档的连续性非常重要，如果中间断了一截，你的时间点恢复就可能失败，又比如，用逻辑备份恢复海量数据时，时间可能长得超乎想象，一定要定期做恢复演练，确保你的备份是真的能用的，而不是纸上谈兵，从Oracle带来的“备份重于一切”的观念，在PostgreSQL这里同样适用，甚至更要加强，因为它的生态工具可能需要你更多的亲手配置。

从Oracle老鸟的角度看,PostgreSQL是一款非常强大且有趣的数据库，它的开源透明和扩展性让人眼前一亮，但它的运维需要更细致、更主动，你得理解其内部机制（比如MVCC），不能像用Oracle那样有时可以“傻瓜式”操作，优化和填坑的过程，其实就是不断学习和理解PostgreSQL设计哲学的过程，虽然一开始会有些不适应，但一旦摸透了它的脾气，你会发现它同样能支撑起稳定高效的业务系统。