數(shù)據(jù)庫用戶都會(huì)面臨這樣的問題，當(dāng)系統(tǒng)剛剛開發(fā)好的時(shí)候，一切都是OK的，數(shù)據(jù)庫也沒啥性能問題，應(yīng)用跑得杠杠的。半年后也許是一兩年后，事情發(fā)生變化了。過去在 100 毫秒內(nèi)運(yùn)行的查詢現(xiàn)在只需要一秒鐘甚至幾秒鐘，剛開始的時(shí)候開發(fā)人員還是能夠應(yīng)付這些情況的，不過很快研發(fā)人員搞不定了，這時(shí)候PG DBA就需要上場了。對于很多DBA來說，優(yōu)化規(guī)模擴(kuò)展了數(shù)倍甚至數(shù)十倍的PostgreSQL數(shù)據(jù)庫是一件具有挑戰(zhàn)性的工作。

一般情況下，大多數(shù)系統(tǒng)在剛剛開始的時(shí)候往往因?yàn)殚_發(fā)時(shí)索引設(shè)計(jì)不夠合理而產(chǎn)生了大多數(shù)的性能問題，最初的優(yōu)化工作可以基于慢SQL的處理，通過索引的優(yōu)化可以度過你最初的具有挑戰(zhàn)性的日子。當(dāng)然，如果你的PG服務(wù)器使用了虛擬機(jī) ，那么增加硬件資源也可以是應(yīng)急的選項(xiàng)之一。不過總是擴(kuò)展硬件并非解決之道，解決數(shù)據(jù)庫的根本問題才是王道。因此在此階段并不建議你立即擴(kuò)容服務(wù)器，而是先開始整治慢SQL。

很多DBA在此階段喜歡自己動(dòng)手去一個(gè)個(gè)優(yōu)化SQL，而在一個(gè)略大一些的組織中，如果應(yīng)用開發(fā)團(tuán)隊(duì)比較強(qiáng)大，那么DBA在這個(gè)階段最好的策略是教會(huì)研發(fā)團(tuán)隊(duì)中的關(guān)鍵人物SQL優(yōu)化的一些簡單的技巧，比如分析執(zhí)行計(jì)劃的合理性以及索引創(chuàng)建的規(guī)則。這樣研發(fā)團(tuán)隊(duì)會(huì)將一部分優(yōu)化工作承擔(dān)起來，而不是讓你陷入到這些枯燥并且不容易讓領(lǐng)導(dǎo)感受到你的價(jià)值的工作中，影響你在DBA本職中的工作效率。另外，由于研發(fā)人員更了解應(yīng)用的細(xì)節(jié)，讓他們更多參與初期的SQL優(yōu)化工作，可以讓這件事干得更有針對性，效果也會(huì)更好。

如果你們企業(yè)規(guī)模不大，從Oracle遷移到PG后DBA的工作量不夠飽滿，干這些工作有助于讓你的工作量飽滿起來，那么你承接這些SQL優(yōu)化的工作也是可以的。

在這個(gè)階段，你需要對數(shù)據(jù)庫的參數(shù)做一次重新評估，因?yàn)槟壳跋到y(tǒng)的規(guī)模和剛上線時(shí)候已經(jīng)有了較大差別，shared_buffers，work_mem、max_parallel_workers等參數(shù)的設(shè)置是否合理會(huì)影響到某些SQL的執(zhí)行效率。bgwriter、walwriter、checkpoint相關(guān)的參數(shù)設(shè)置的不合理可能會(huì)影響到高并發(fā)下的數(shù)據(jù)庫整體性能。操作系統(tǒng)相關(guān)的參數(shù)設(shè)置不合理可能會(huì)讓硬件資源無法發(fā)揮最大的效益。當(dāng)系統(tǒng)很小的時(shí)候，這些參數(shù)哪怕設(shè)置得不太合理，也問題不大。而當(dāng)系統(tǒng)規(guī)模比較大的時(shí)候，這些參數(shù)也就需要精細(xì)化調(diào)優(yōu)了。

除了上述常規(guī)的工作，你還需要找到系統(tǒng)中的比較大的表，通過數(shù)據(jù)增長量的情況來分析你是否需要優(yōu)化表的結(jié)構(gòu)，如果某些大表數(shù)據(jù)量增長很快，你要考慮開始優(yōu)化，將這些表改為分區(qū)表。在系統(tǒng)規(guī)模剛剛開始增大時(shí)，這種工作還不太費(fèi)勁，等到表超級大的時(shí)候，做起來就費(fèi)勁了。這項(xiàng)工作是開發(fā)團(tuán)隊(duì)往往會(huì)忽視的，也是體現(xiàn)DBA價(jià)值的，因此這項(xiàng)工作一定要做好。

對于一些熱表，經(jīng)常會(huì)有熱塊爭用的表，哪怕表不夠大，在業(yè)務(wù)訪問性能不受影響的情況下（比如沒有大量的順序讀?。梢钥紤]改為HASH 分區(qū)表，從而為今后的長期運(yùn)行排除掉一個(gè)地雷。如果該表不太適合HASH分區(qū)，那么適當(dāng)減小這張表的填充因子，緩解一下熱塊沖突的影響也是很不錯(cuò)的。

實(shí)際上在這個(gè)階段，你已經(jīng)有能力判斷這個(gè)系統(tǒng)今后的規(guī)模了，如果你的評估是今后系統(tǒng)可能會(huì)導(dǎo)致單機(jī)負(fù)載過高，那么你可以向領(lǐng)導(dǎo)提出未來容量發(fā)展的評估結(jié)果，并給出建議。未來一兩年系統(tǒng)的擴(kuò)容和硬件改造優(yōu)化雖然并不一定馬上會(huì)開展，但是你需要給領(lǐng)導(dǎo)提出一個(gè)建議。如果簡單擴(kuò)容無法解決問題，那么你可以建議優(yōu)化架構(gòu)，將系統(tǒng)改為讀寫分離架構(gòu)來滿足未來的需求。因?yàn)檫@個(gè)優(yōu)化需要應(yīng)用架構(gòu)上的大調(diào)整，因此對于DBA來說，這個(gè)建議的提出越早越好。

在這個(gè)階段，你還需要仔細(xì)考慮當(dāng)前系統(tǒng)的高可用架構(gòu)、備份策略等方面是否存在優(yōu)化的需求。系統(tǒng)變得更大，也會(huì)變得更加重要，通過流復(fù)制構(gòu)建只讀備庫，完善物理備份和邏輯備份的方案等，也是DBA的本職工作。做好這些不僅僅讓你在企業(yè)中獲得同僚的尊重，這些工種成果也會(huì)成為你運(yùn)維這套數(shù)據(jù)庫系統(tǒng)的有力保障，這些工作一定不要掉以輕心，必須做好。