數據庫用戶都會面臨這樣的問題，當系統剛剛開發好的時候，一切都是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的本職工作。做好這些不僅僅讓你在企業中獲得同僚的尊重，這些工種成果也會成為你運維這套數據庫系統的有力保障，這些工作一定不要掉以輕心，必須做好。