当前的项目，生产系统有一个报表库，每晚通过批量导入和更新数据，每个月的数据在4000万左右，经常CPU报警。
做了如下的优化：
- 索引，由于用户的检索方式基本都是重复性很高的。热点字段就两三个，做了索引，优化了一大截。
- 分区，通过分析，导致报警的语句，具有一个相同的特征，就是用户检索时间范围时，PostgreSQL无法命中索引（如果用to_char就可以命中）。暂时做了按时间分区，进而提升性能。
- 限制访问，通过限制并发数，保护数据库。
- 定时Vacuum和Analyze
前三项估计大家都很熟悉了，这里重点说一下Vacuum和Analyze。
Vacuum出现的原因是PostgreSQL不使用回滚段UNDO，而是直接在表数据文件中进行版本管理，导致表数据文件中出现大量的DEAD_TUP(可以通过pg_stat_*_tables来查看)。需要通过Vacuum进行空间回收和压缩。
有人说，这种设计的好处是宕机时，重启后，不需要对事务进行redo和undo操作，可以快速的进入工作状态。
这个好处的用处大家觉得大吗？很简单的道理，是数据库的增删改操作频繁，还是宕机频繁呢。
当然，PostgreSQL已经设计成这样了，那么只能在其规则下进行优化了。
接下来，通过测试数据对其进行分析。
报表库的特点就是，大批量操作进行数据初始化，之后数据就固定了，不会发生变化。
测试场景也模仿这样的设计：
创建100万条记录，然后并发事务进行数据更新，观察表数据文件的变化和查询语句的性能变化。
通过测试发现：
进行插入和大量更新操作之后，产生了大量的dead_tup。
postgreSQL的autovacuum和autoanalyze有一定效果，但是没有到极致。
SQL执行时间分别如下：
精准检索（索引扫描）：5ms
统计SQL（全表扫描）：15478ms
触发autovacuum之后
精准检索（索引扫描）：3.5ms
统计SQL（全表扫描）：78862ms（这个数据极其异常）
触发autoanalyze之后
精准检索（索引扫描）：3.3ms
统计SQL（全表扫描）：18920ms
可以看到，autovacuum和autoanalyze之后，命中索引的检索性能有所提升，但是全表扫描的统计SQL，性能反而下降了。
手动执行ANALYZE之后，性能又有所提升。
精准检索（索引扫描）：3.5ms
统计SQL（全表扫描）：8419ms
可以看到，全表扫描的这种情况已经大幅优化了。
手动执行VACUUM之后，性能又提升了很多。
精准检索（索引扫描）：3.4ms
统计SQL（全表扫描）：1552ms
至此，已经大幅提升了，PostgreSQL是不建议进行VACUUM FULL操作的，但既然保留了这个功能，肯定是有其存在的场景的。
所以，再尝试一下VACUUM FULL。
精准检索（索引扫描）：2.3ms
统计SQL（全表扫描）：875ms
通过观察，经过AUTOVACUUM和VACUUM操作后，文件空间是不会发生变化的。经过VACUUM后，文件空间直接被压缩了几倍（32GB -> 5GB）。
如果你的应用场景也是，批量导入和更新数据后，数据只是对外提供只读操作。
那么在批量程序运行完毕之后，进行一次VACUUM FULL和VACUUM以及ANALYZE，说不定会有惊喜。
