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

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

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

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

在這個(gè)階段，你需要對(duì)數(shù)據(jù)庫(kù)的參數(shù)做一次重新評(píng)估，因?yàn)槟壳跋到y(tǒng)的規(guī)模和剛上線(xiàn)時(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ù)庫(kù)整體性能。操作系統(tǒng)相關(guān)的參數(shù)設(shè)置不合理可能會(huì)讓硬件資源無(wú)法發(fā)揮最大的效益。當(dāng)系統(tǒng)很小的時(shí)候，這些參數(shù)哪怕設(shè)置得不太合理，也問(wèn)題不大。而當(dāng)系統(tǒng)規(guī)模比較大的時(shí)候，這些參數(shù)也就需要精細(xì)化調(diào)優(yōu)了。

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

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

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

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