大家用Oracle數(shù)據(jù)庫(kù)的時(shí)候，根本不需要過(guò)多的去考慮數(shù)據(jù)庫(kù)物理結(jié)構(gòu)以及OS物理結(jié)構(gòu)方面的優(yōu)化。因?yàn)镺racle把一切都幫我們做好了，只需要交給Oracle足夠容量，足夠能力的物理資源就一切OK了。不過(guò)作為三十年前就開(kāi)始使用Oracle數(shù)據(jù)庫(kù)的我們這一代DBA，還是經(jīng)歷過(guò)很多這樣的優(yōu)化案例的。在那個(gè)年代，曾經(jīng)通過(guò)底層存儲(chǔ)的重新條帶化設(shè)計(jì)，讓一套IO負(fù)載極高的數(shù)據(jù)庫(kù)系統(tǒng)的批處理作業(yè)性能提高數(shù)倍。

現(xiàn)在我們?nèi)绻皇褂肙racle數(shù)據(jù)庫(kù)了，我們要把應(yīng)用從Oracle遷移到國(guó)產(chǎn)數(shù)據(jù)庫(kù)上了，那么這些老手藝可能又有些作用了。不過(guò)與那個(gè)時(shí)代不同的是，現(xiàn)在硬件的能力已經(jīng)百倍的提升了，存儲(chǔ)系統(tǒng)的全局IO打散能力也成為了標(biāo)配，因此再也不需要像我在二十多年前那樣為了一點(diǎn)點(diǎn)的IOPS去精打細(xì)算了。

今天這個(gè)話題雖然我已經(jīng)把討論范圍縮小到了物理結(jié)構(gòu)優(yōu)化上，不過(guò)還是太大，我不大可能在一個(gè)一千多字的文章里把所有的問(wèn)題都講清楚，因此我們今天還是縮小到一個(gè)比較小的話題上吧，那就是如何通過(guò)底層物理結(jié)構(gòu)的優(yōu)化讓關(guān)鍵業(yè)務(wù)系統(tǒng)在PG類數(shù)據(jù)庫(kù)上平穩(wěn)運(yùn)行。這里講的是PG類數(shù)據(jù)，除了社區(qū)版的PG外，還有大量基于PG的開(kāi)源、國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)品，包括華為的GAUSSDB系列，瀚高、金倉(cāng)、神通、優(yōu)炫、亞信ANTDB、中國(guó)移動(dòng)磐維等，都是PG類數(shù)據(jù)庫(kù)。甚至今天我討論的部分內(nèi)容對(duì)于MYSQL、達(dá)夢(mèng)、SQL SERVER等沒(méi)有使用DIO的數(shù)據(jù)庫(kù)也是有一定作用的。

最近我經(jīng)常聽(tīng)說(shuō)某些客戶把數(shù)據(jù)庫(kù)從Oracle遷移到國(guó)產(chǎn)數(shù)據(jù)庫(kù)上后，一些關(guān)鍵業(yè)務(wù)忽快忽慢，檢查執(zhí)行計(jì)劃也沒(méi)啥問(wèn)題，操作系統(tǒng)層面也沒(méi)有明顯的瓶頸或者慢的因素。實(shí)際上這與數(shù)據(jù)庫(kù)沒(méi)有使用DIO有很大的關(guān)系。對(duì)于沒(méi)有使用DIO的系統(tǒng)，當(dāng)數(shù)據(jù)沒(méi)有在DB CACHE中命中的時(shí)候，會(huì)產(chǎn)生物理讀。不過(guò)這個(gè)物理讀并不一定真正的從物理存儲(chǔ)介質(zhì)上讀取，如果數(shù)據(jù)在LINUX的OS CACHE里，那么可以直接從CACHE中獲取，這種物理讀是很快的，如果OS CACHE沒(méi)有命中，那么就只能真正的從物理存儲(chǔ)介質(zhì)中去讀取了，相對(duì)于直接從內(nèi)存中讀取，這種物理讀是較慢的。因?yàn)镺S CACHE沒(méi)辦法按照我們的數(shù)據(jù)庫(kù)訪問(wèn)需求去緩沖數(shù)據(jù)，因此OS CACHE的目的性并不強(qiáng)。這種忽快忽慢大多數(shù)集中在讀操作上的，不過(guò)有時(shí)候?qū)懸矔?huì)出現(xiàn)抖動(dòng)，那是因?yàn)镺S層面的的后臺(tái)進(jìn)程、檢查點(diǎn)以及WAL或者文件寫(xiě)的FSYNC都會(huì)讓OS產(chǎn)生一個(gè)抖動(dòng)，從而對(duì)事務(wù)提交或者索引更新產(chǎn)生性能影響。在并發(fā)量較大、存在熱點(diǎn)寫(xiě)數(shù)據(jù)的應(yīng)用中，就很可能會(huì)產(chǎn)生一定的影響了。

我們無(wú)法去改變上面所說(shuō)的DOUBLE BUFFERING的問(wèn)題，這只能通過(guò)國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商的努力在自己的數(shù)據(jù)庫(kù)產(chǎn)品里全面引入DIO來(lái)解決了。實(shí)際上目前為止只有Oracle能夠比較好的把控DIO，除此之外，哪怕是SQL SERVER這種老牌的商用數(shù)據(jù)庫(kù)，雖然可以支持DIO，但是也不建議啟用DIO。

可能有些朋友覺(jué)得偶爾出現(xiàn)幾條SQL執(zhí)行變慢沒(méi)啥所謂，這可能和你看到的應(yīng)用場(chǎng)景有關(guān)。如果是股票交易或者銀行交易出現(xiàn)了某個(gè)時(shí)段幾百筆交易延時(shí)異常，那么對(duì)于這個(gè)企業(yè)來(lái)說(shuō)就是運(yùn)維事故了。如果一條核心交易的SQL，平時(shí)執(zhí)行只需要5毫秒，抖動(dòng)時(shí)就可能變成三四十毫秒，現(xiàn)在網(wǎng)聯(lián)對(duì)金融機(jī)構(gòu)的交易超時(shí)監(jiān)控十分嚴(yán)格，一次這樣的抖動(dòng)足以產(chǎn)生一次告警了。

要想避免此類抖動(dòng)，必須在物理結(jié)構(gòu)上做好優(yōu)化。我今天提出幾點(diǎn)優(yōu)化的建議。首先是對(duì)底層存儲(chǔ)的優(yōu)化，如果不是使用集中式存儲(chǔ)，那么還需要考慮512E和4KN等現(xiàn)代磁盤扇區(qū)大小的問(wèn)題以及相關(guān)的對(duì)齊問(wèn)題。今天篇幅有限，就不展開(kāi)討論了，有興趣的朋友可以參考我以前寫(xiě)過(guò)的一篇文章《原來(lái)ADVANCED FORMAT HDD已經(jīng)普及了》（https://mp.weixin.qq.com/s?__biz=MzA5MzQxNjk1NQ==&mid=2647848163&idx=1&sn=0f27f69e5d337a3873d6f3cdaa841a24&chksm=88786877bf0fe161178bed2cc05c2db84265ae3356ade0847e81b2e331e299d580c89dc31c9f&token=1445168299&lang=zh_CN#rd）。

除此之外，怕抖動(dòng)的核心交易系統(tǒng)盡可能使用比較快的存儲(chǔ)介質(zhì)，比如NVME SSD，盡可能降低平均IO延時(shí)是從根本上降低IO抖動(dòng)帶來(lái)的問(wèn)題的最便宜的方法，不要覺(jué)得SSD很貴，實(shí)際上在這里多花點(diǎn)錢可以在其他地方少花更多的錢。

第二個(gè)需要關(guān)注的就是存儲(chǔ)的規(guī)劃，通過(guò)使用獨(dú)立的表空間和文件系統(tǒng)，讓相互影響，可能導(dǎo)致運(yùn)行毛刺的應(yīng)用之間的沖突盡可能地減少。如果系統(tǒng)不重要，或者抖動(dòng)無(wú)所謂，那么不需要做這方面的優(yōu)化，而如果這個(gè)系統(tǒng)是十分關(guān)鍵的核心系統(tǒng)，那么在這方面做再多的工作都是值得的。在二十多年前，搞Oracle 7的時(shí)候，這些手段我也都用過(guò)。

對(duì)于寫(xiě)入十分重的系統(tǒng)，WAL盡可能獨(dú)立存儲(chǔ)于高性能的獨(dú)立磁盤上，避免與其他讀寫(xiě)IO沖突。小型熱表也可以存儲(chǔ)于獨(dú)立的表空間里。相對(duì)靜態(tài)，但是會(huì)大規(guī)模掃描的冷數(shù)據(jù)獨(dú)立存儲(chǔ)，訪問(wèn)十分頻繁的表的索引與數(shù)據(jù)分開(kāi)等都是可以采取的IO隔離手段。具體要根據(jù)業(yè)務(wù)的特點(diǎn)去做規(guī)劃。前面討論的都是從本地磁盤的角度去考慮的，實(shí)際上目前大多數(shù)系統(tǒng)使用集中式存儲(chǔ)，很多IO延時(shí)穩(wěn)定性的問(wèn)題可能要考慮后端存儲(chǔ)的規(guī)劃與優(yōu)化，大家要注意這個(gè)問(wèn)題。后端存儲(chǔ)分過(guò)來(lái)的盤和實(shí)際的物理盤是不同的。

第三個(gè)需要關(guān)注的問(wèn)題是OS層面針對(duì)性的優(yōu)化，這一點(diǎn)大家可以參考我的另外一篇文章《Postgresql數(shù)據(jù)庫(kù)優(yōu)化上該考慮些什么》（https://mp.weixin.qq.com/s?__biz=MzA5MzQxNjk1NQ==&mid=2647849429&idx=1&sn=2776253a04b780d090bfe7a03784345c&chksm=88786541bf0fec573182c704e41c0adddc9d96ee0af694cea263d685ce51fb3f9b4aa7700f52&token=1445168299&lang=zh_CN#rd），這里我就不重復(fù)介紹了。

第四個(gè)要考慮的是SHARED_BUFFERS的設(shè)置，如果我們?cè)谶\(yùn)行一個(gè)十分關(guān)鍵的核心交易系統(tǒng)，那么建議還是配置大一點(diǎn)的物理內(nèi)存，并將SHARED BUFFFERS設(shè)置的足夠大，盡可能地讓熱點(diǎn)數(shù)據(jù)都能夠長(zhǎng)期緩沖在數(shù)據(jù)庫(kù)緩沖區(qū)里，從而穩(wěn)定關(guān)鍵業(yè)務(wù)地運(yùn)行效率。但是業(yè)務(wù)系統(tǒng)十分復(fù)雜，是不是也會(huì)產(chǎn)生一些對(duì)大型冷數(shù)據(jù)的掃描操作。這些操作盡可能地放到只讀備機(jī)上去做，而不要影響核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫(kù)緩沖。一種更好的設(shè)計(jì)是將這些可能對(duì)核心交易產(chǎn)生影響的數(shù)據(jù)從核心數(shù)據(jù)庫(kù)中剝離出去，另外建個(gè)庫(kù)，那樣的話對(duì)核心交易的影響就小多了。