数据库用户都会面临这样的问题，当系统刚刚开发好的时候，一切都是OK的，数据库也没啥性能问题，应用跑得杠杠的。半年后也许是一两年后，事情发生变化了。过去在 100 毫秒内运行的查询现在只需要一秒钟甚至几秒钟，刚开始的时候开发人员还是能够应付这些情况的，不过很快研发人员搞不定了，这时候PG DBA就需要上场了。对于很多DBA来说，优化规模扩展了数倍甚至数十倍的PostgreSQL数据库是一件具有挑战性的工作。
一般情况下，大多数系统在刚刚开始的时候往往因为开发时索引设计不够合理而产生了大多数的性能问题，最初的优化工作可以基于慢SQL的处理，通过索引的优化可以度过你最初的具有挑战性的日子。当然，如果你的PG『服务器』使用了虚拟机 ，那么增加硬件资源也可以是应急的选项之一。不过总是扩展硬件并非解决之道，解决数据库的根本问题才是王道。因此在此阶段并不建议你立即扩容『服务器』，而是先开始整治慢SQL。
很多DBA在此阶段喜欢自己动手去一个个优化SQL，而在一个略大一些的组织中，如果应用开发团队比较强大，那么DBA在这个阶段最好的策略是教会研发团队中的关键人物SQL优化的一些简单的技巧，比如分析执行计划的合理性以及索引创建的规则。这样研发团队会将一部分优化工作承担起来，而不是让你陷入到这些枯燥并且不容易让领导感受到你的价值的工作中，影响你在DBA本职中的工作效率。另外，由于研发人员更了解应用的细节，让他们更多参与初期的SQL优化工作，可以让这件事干得更有针对性，效果也会更好。
如果你们企业规模不大，从Oracle迁移到PG后DBA的工作量不够饱满，干这些工作有助于让你的工作量饱满起来，那么你承接这些SQL优化的工作也是可以的。
在这个阶段，你需要对数据库的参数做一次重新评估，因为目前系统的规模和刚上线时候已经有了较大差别，shared_buffers，work_mem、max_parallel_workers等参数的设置是否合理会影响到某些SQL的执行效率。bgwriter、walwriter、checkpoint相关的参数设置的不合理可能会影响到高并发下的数据库整体性能。操作系统相关的参数设置不合理可能会让硬件资源无法发挥最大的效益。当系统很小的时候，这些参数哪怕设置得不太合理，也问题不大。而当系统规模比较大的时候，这些参数也就需要精细化调优了。
除了上述常规的工作，你还需要找到系统中的比较大的表，通过数据增长量的情况来分析你是否需要优化表的结构，如果某些大表数据量增长很快，你要考虑开始优化，将这些表改为分区表。在系统规模刚刚开始增大时，这种工作还不太费劲，等到表超级大的时候，做起来就费劲了。这项工作是开发团队往往会忽视的，也是体现DBA价值的，因此这项工作一定要做好。
对于一些热表，经常会有热块争用的表，哪怕表不够大，在业务访问性能不受影响的情况下（比如没有大量的顺序读取），可以考虑改为HASH 分区表，从而为今后的长期运行排除掉一个地雷。如果该表不太适合HASH分区，那么适当减小这张表的填充因子，缓解一下热块冲突的影响也是很不错的。
实际上在这个阶段，你已经有能力判断这个系统今后的规模了，如果你的评估是今后系统可能会导致单机负载过高，那么你可以向领导提出未来容量发展的评估结果，并给出建议。未来一两年系统的扩容和硬件改造优化虽然并不一定马上会开展，但是你需要给领导提出一个建议。如果简单扩容无法解决问题，那么你可以建议优化架构，将系统改为读写分离架构来满足未来的需求。因为这个优化需要应用架构上的大调整，因此对于DBA来说，这个建议的提出越早越好。
在这个阶段，你还需要仔细考虑当前系统的高可用架构、备份策略等方面是否存在优化的需求。系统变得更大，也会变得更加重要，通过流复制构建只读备库，完善物理备份和逻辑备份的方案等，也是DBA的本职工作。做好这些不仅仅让你在企业中获得同僚的尊重，这些工种成果也会成为你运维这套数据库系统的有力保障，这些工作一定不要掉以轻心，必须做好。
