互聯(lián)網(wǎng)IDC圈9月2日?qǐng)?bào)道，8月29日-30日在上海國(guó)際時(shí)尚中心舉行的D-Future數(shù)據(jù)時(shí)代峰會(huì)是七牛為大家?guī)淼囊粓?chǎng)數(shù)據(jù)盛筵，匯聚了業(yè)界領(lǐng)袖、行業(yè)專家，他們將從產(chǎn)業(yè)的角度和技術(shù)的角度來解讀數(shù)據(jù)從何而來，數(shù)據(jù)如何應(yīng)用，數(shù)據(jù)重新構(gòu)未來。

創(chuàng)新互聯(lián)公司是一家專業(yè)提供馬龍企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、H5建站、小程序制作等業(yè)務(wù)。10年已為馬龍眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進(jìn)行中。

數(shù)據(jù)庫(kù)優(yōu)化是一個(gè)很大的問題，迄今為止一直困擾著所有的數(shù)據(jù)庫(kù)管理員和程序員。會(huì)上美圖網(wǎng)的楊尚剛跟大家分享了數(shù)據(jù)庫(kù)運(yùn)維和性能優(yōu)化方面的內(nèi)容。

楊尚剛

以下是楊尚剛演講內(nèi)容（根據(jù)速記整理）：

楊尚剛：我今天最后一場(chǎng)，我今天主要講的數(shù)據(jù)庫(kù)運(yùn)維和性能優(yōu)化的一些東西。下面是我的微博，有興趣可以加一下。

我2011年加入新浪，在新浪待了四年，主要是負(fù)責(zé)新浪微博的一些核心數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)，還有新浪數(shù)據(jù)平臺(tái)底層軟件優(yōu)化，今年加入了美圖，美圖大家都知道，美圖現(xiàn)在兩款產(chǎn)品，一個(gè)美圖秀秀還有一個(gè)美拍，現(xiàn)在用的人也非常多，這邊我也是負(fù)責(zé)后數(shù)據(jù)存儲(chǔ)的平臺(tái)建設(shè)。下面兩張圖比較形象，相當(dāng)于好多人都認(rèn)為從左邊這張圖開始干，理想是右邊，或者是更高級(jí)別的人物。

MySQL優(yōu)點(diǎn)使用更簡(jiǎn)單，第二個(gè)免費(fèi)。這兩個(gè)是MySQL現(xiàn)在應(yīng)用非常廣泛的原因。第三個(gè)擴(kuò)展性好，當(dāng)然這個(gè)擴(kuò)展性加引號(hào)，但是一旦你的規(guī)模達(dá)到上百萬、上千臺(tái)的時(shí)候，擴(kuò)展因素打一個(gè)折扣，面臨著一些挑戰(zhàn)。第四個(gè)社區(qū)比較活躍，這個(gè)非常顯然，這也是為什么現(xiàn)在PG沒有比MySQL更廣泛的原因，PG我也承認(rèn)肯定比MySQL要好，但是你的社區(qū)一旦做得不好的話，還是非常不好的，酒香不怕巷子深。社區(qū)活躍是一個(gè)非常重要的點(diǎn)。最后一個(gè)MySQL雖然有非常多的問題，但是在現(xiàn)有的情況下MySQL還是依然能夠滿足我們現(xiàn)在大多數(shù)用戶的需求。

說完它的優(yōu)點(diǎn)再說它的缺點(diǎn)，第一它對(duì)復(fù)雜所謂支持不好，MySQL還是挺差的，之前我不知道有沒有人看到，對(duì)一個(gè)語句，40條或者200條，肯定是40條快一些，反饋200條快一些這就是MySQL比較坑人的地方。第二對(duì)于SQL標(biāo)準(zhǔn)。第三個(gè)大規(guī)模集群方案不成熟，主要是知識(shí)面的支持上，官方?jīng)]有一個(gè)很好的支持，還需要很多開元的二次開放才能支持好。下面這幾個(gè)，ID生成器這個(gè)也不是那么重要。這個(gè)和方案相比，還是相對(duì)差一些。下面就是Online DDL這也是MySQL比較大的一個(gè)痛點(diǎn)，MySQL就會(huì)比較麻煩。下面是HA方案，MySQL沒有一個(gè)非?？煽康姆桨?，很多還需要依賴第三方工具。下面就是備份恢復(fù)這個(gè)也是比較復(fù)雜，展示機(jī)構(gòu)少，這個(gè)時(shí)候比較被動(dòng)，下面就是分支。

下面再說雖然有這么多問題，MySQL還是很受歡迎。第一個(gè)可靠性，第二經(jīng)過大規(guī)模部署的驗(yàn)證，這種都已經(jīng)在線上通過大規(guī)模的生產(chǎn)考驗(yàn)，所以大家都是認(rèn)可的。下面這兩個(gè)是比較支持的，找踩坑，很多技術(shù)都是并不是說它怎么著，還是需要看一下其他人的經(jīng)驗(yàn)。這個(gè)就是DBAlife，比如像各種各樣開發(fā)需求，各種各樣的需求，你還得去滿足。各種各樣需求。下面就是SQL優(yōu)化，也是DBA工作人員很大一部分，下面就是各種救火和故障，你的主庫(kù)故障，各種各樣問題，都是需要DBA去介入的。下面就是一些各種業(yè)務(wù)，項(xiàng)目上線，還有日常的溝通。

怎樣能變得不苦呢？DBA涉及到各種更改和創(chuàng)建，它占了很多時(shí)間。如何去解放DBA的雙手，主要是兩個(gè)部分，第一建立數(shù)據(jù)庫(kù)開發(fā)規(guī)范，第二個(gè)把固化基本原則到自動(dòng)化審核流程里去，減少DBA的溝通成本和一些重復(fù)工作。

這是數(shù)據(jù)庫(kù)開發(fā)規(guī)范，現(xiàn)在網(wǎng)上也有很多，我就不細(xì)說了，說說它的意義，數(shù)據(jù)庫(kù)開發(fā)規(guī)范，保證線上的規(guī)模是統(tǒng)一的，是遵守創(chuàng)業(yè)規(guī)范的。這樣對(duì)于你后面一些都是非常有好處的。這個(gè)開發(fā)規(guī)范如何去遵守，這個(gè)也是需要DBA去投入經(jīng)歷的，這個(gè)東西，雖然開發(fā)者會(huì)去看這個(gè)東西，這個(gè)就需要DBA主動(dòng)去推這個(gè)東西，定期給開發(fā)培訓(xùn)，開發(fā)能夠認(rèn)識(shí)到規(guī)范一個(gè)重要性，也能減少DBA后續(xù)運(yùn)維的一個(gè)成本。

這是一個(gè)簡(jiǎn)單的規(guī)范示例，主要是一些表情選擇，還有定義，當(dāng)然肯定比這個(gè)復(fù)雜多，如果你把規(guī)范定得很詳細(xì)的話。

DDL自動(dòng)化有三個(gè)部分，建表、審表和改表這都是日常的需求。這是一個(gè)主要流程，提交DDL，首先你系統(tǒng)里面會(huì)做一些語法檢測(cè)，肯定還是要打回去要重新去改，語法通過，這些動(dòng)作如果沒自動(dòng)化就需要DDL打電話發(fā)郵件，這部分工作就是看它是否符合開發(fā)規(guī)范，剛才提到的自己的選擇，這部分不過的話，也是需要開發(fā)再去修改，開發(fā)修改的話，可以去線上支持。當(dāng)然這里還會(huì)設(shè)置關(guān)于操作，比如你去做表還是發(fā)表一些創(chuàng)建的操作，要區(qū)分這個(gè)東西，這個(gè)操作還是盡量讓開發(fā)直接去搞，開發(fā)肯定意識(shí)到了操作，如果是的話可能就需要DDL的選擇，做一些提前預(yù)案這些東西。

當(dāng)然剛才提的問題也是DDL的問題，MySQL是內(nèi)部不支持的，960的DDL，很多實(shí)際在生產(chǎn)上用的話，還是有比較大的距離。為什么MySQL會(huì)有非常大的問題呢？它需要一個(gè)鎖，一旦你去執(zhí)行這些操作的時(shí)候，都是要組織表，而組織這個(gè)過程中，你不能再往里面寫數(shù)據(jù)。你的業(yè)務(wù)數(shù)據(jù)是不能服務(wù)的，這樣一般產(chǎn)品是不能接受的，所以這個(gè)是MySQL一個(gè)比較大的問題。

當(dāng)然現(xiàn)在也有一些方案，比如像基于FacebookOSC的原理，下面表格主要和做對(duì)比，其他兩個(gè)5.6的是不支持的，官方內(nèi)置的這些東西，但是它的問題還是比較多的。包括解決不了DDL延時(shí)問題，還有用了也會(huì)有影響。比較多的是基于FacebookOSC的延伸體。

這個(gè)是OSC的原理，還是比較敞亮的。一開始核心是下面部分，調(diào)整塊大小，同步數(shù)據(jù)，根據(jù)覆負(fù)載調(diào)整進(jìn)度，一個(gè)比較核心。后面或者前面都是一些準(zhǔn)備步驟，或者是一些簡(jiǎn)單的操作?？匆幌翸ySQL另外一個(gè)，慢日志，如果你要去做的話，很多都要根據(jù)慢日志去做的，如果有一個(gè)系統(tǒng)的話，發(fā)現(xiàn)某一個(gè)你就得去判斷，看一下，有沒有慢日志，這個(gè)基本上是一個(gè)比較常規(guī)的過程。

而這個(gè)里面很多步驟都是可以去自動(dòng)化做掉的，這個(gè)的話，慢日志化系統(tǒng)，根據(jù)慢日志化系統(tǒng)開發(fā)，負(fù)責(zé)業(yè)務(wù)。

這個(gè)算一個(gè)基本系統(tǒng)架構(gòu)，基本上主要依賴這個(gè)是分析MySQL比較好的，分析的結(jié)果也是非常詳細(xì)，報(bào)表也是比較好用。

第二個(gè)Logstash，都可以。第三個(gè)Anemometer，開了一個(gè)系統(tǒng)，右邊這個(gè)圖就是基本的數(shù)據(jù)流程，也是非常簡(jiǎn)單，基本上就是數(shù)據(jù)和入庫(kù)各種展示。

這個(gè)就是簡(jiǎn)單的頁(yè)面，最上面是兩個(gè)時(shí)間段的情況。比如昨天某個(gè)時(shí)間，下面框就是它提供的哪些展示，也可以定制。中間這個(gè)根據(jù)IP都可以去調(diào)整。下面是一些展示的過程，一個(gè)例子。這個(gè)就是你點(diǎn)進(jìn)去某一個(gè)，它的變化曲線，在什么時(shí)候比較多都可以看到，包括也可以看到，在這可以直接點(diǎn)出來，它的結(jié)果，不需要再線上去看，掃描或者有沒有都可以在這里面看到。所以說還是比較方便的。

另外一個(gè)的變化就是備份系統(tǒng)，備份系統(tǒng)是做這個(gè)行業(yè)首先要保證的，首先性能不是最重要的，安全是最重要的。所以備份都是最重要的。悲憤意義，很簡(jiǎn)單就是我為了數(shù)據(jù)恢復(fù)。下面?zhèn)浞莸姆绞?，MySQL備份方式也非常多，沒有官方的一些支持，也是各種各樣，像全量、增量、熱備和冷備，物理和邏輯，延時(shí)，這種方式都是針對(duì)不同方式去做的。建立方式，基于熱備加物理是更好的。如果能做出來最好，不能做的話，熱備加物理也可以滿足很多需求。如果你一些非常和核心的業(yè)務(wù)，考慮用組合的方式。

M：這是備份系統(tǒng)數(shù)據(jù)，在新浪做的系統(tǒng)，每年備份數(shù)據(jù)，做7000加次擴(kuò)容，每年要做12加次數(shù)據(jù)恢復(fù)，當(dāng)然這個(gè)東西，實(shí)踐很多開發(fā)不注意，都可能導(dǎo)致不良的后果。數(shù)據(jù)量的話，每日志量每天3TB，數(shù)據(jù)總量在2PB，每天悲憤數(shù)據(jù)量百TB級(jí)。

備份優(yōu)化我們主要做下面幾個(gè)部分，第一主主要悲憤策略集中式調(diào)度管理，對(duì)格式化都不太好，還有熱備至四，統(tǒng)計(jì)分析，還有校驗(yàn)問題，最后采用分布式文件系統(tǒng)存儲(chǔ)備份。我們當(dāng)時(shí)也調(diào)研過其他的，最終權(quán)利選擇了這種。

當(dāng)然分布式文件系統(tǒng)，之所以要用也是有一些痛點(diǎn)，下面幾點(diǎn)，存儲(chǔ)分配的問題，當(dāng)時(shí)已經(jīng)存儲(chǔ)了六、七十臺(tái)左右，你在真的需要存儲(chǔ)管理容量，都需要人工去管理，能自動(dòng)化但是做的不是特別好，還是比較復(fù)雜。NFS這個(gè)還是導(dǎo)致經(jīng)常負(fù)載特別高，備份效率特別低，下面還是存儲(chǔ)集中式管理，最后數(shù)據(jù)可靠性更好，可能會(huì)比單點(diǎn)問題會(huì)有好處的。

當(dāng)然我們使用分布式系統(tǒng)我們也做了優(yōu)化，第一個(gè)采用Pbzip壓縮比能做到三分之一，降低多副本存儲(chǔ)帶來的存儲(chǔ)成本，第二個(gè)使用壓縮之后，降低網(wǎng)絡(luò)帶寬消耗。最后一個(gè)是erasure的方案調(diào)研，使用這種方案，也都比較成熟。右邊是一個(gè)簡(jiǎn)單的架構(gòu)圖。

提到MySQL版本問題，MySQL版本現(xiàn)在是說官方有兩個(gè)一個(gè)社區(qū)版、一個(gè)企業(yè)版，還有其他兩個(gè)，MariaDB版是MySQL去做的。各國(guó)內(nèi)來說還是用MySQL社區(qū)版比較多，MySQL企業(yè)版比較少，傳統(tǒng)行業(yè)有錢的可能會(huì)選且版。

下面是我的建議，你選MySQL社區(qū)版。但是如果對(duì)于大多數(shù)用戶來說，社區(qū)版穩(wěn)定，對(duì)于后期的支持肯定會(huì)比MySQL企業(yè)版更好一些。最后就是MariaDB在國(guó)內(nèi)用的非常少，而且優(yōu)化方向和社區(qū)版還是有一定的差距。

這個(gè)是MySQL主流版本，當(dāng)然之前那些都比較老了，5.0、4.幾現(xiàn)在主流的是5.0。現(xiàn)在主流的就是5.6和5.5，現(xiàn)在一般用5.6就可以了，也是一個(gè)比較穩(wěn)定的版本。5.5的話，是保守用5.5。

下面是MySQL復(fù)制問題，MySQL復(fù)制的話，好多人都會(huì)遇到一個(gè)比較坑，MySQL復(fù)制延遲問題和MySQL安全問題。

MySQL復(fù)制采用一些不可靠的投遞，不管有沒有執(zhí)行這些問題都會(huì)存在，所以說安全性還有延時(shí)問題被很多人詬病的一個(gè)點(diǎn)。

下面的圖就是它的一個(gè)框架，右面紅框里面就是瓶頸原因，使用或者概念。

這種概念的簡(jiǎn)化，現(xiàn)在也有很多了，像第一5.6的方案，5.6也是一個(gè)半成品的方案，也不能解決很多瓶頸，能解決一些特定的瓶頸。二個(gè)以為代表的第三方工具，還有sharding，把你的數(shù)據(jù)弄的更小這也是一個(gè)比較好的方案。

這是5.6和5.7的并行復(fù)制的優(yōu)化，5.6剛才提到一個(gè)比較麻煩的問題，假設(shè)我是一個(gè)，你就不能用了，5.6只能根據(jù)一個(gè)副題復(fù)制，我有十個(gè)我可以取十個(gè)點(diǎn)，這樣只有一個(gè)庫(kù)你開不開沒什么區(qū)別。另外一個(gè)5.7說起來比較復(fù)雜，5.7基于，這種方式是可以跳出副題復(fù)制的。它并行率是非常高的，5.7是一個(gè)相對(duì)比5.6好很多的并行復(fù)制解決方案。

MySQL除了復(fù)制，下面還有很多，很多人聽說過的幾類，這類似的方案有很多。怎么去選擇？從兩個(gè)方面去考慮，你需不需要支持，比如說如果你哪個(gè)不需要，用MySQL就可以了。如果你對(duì)這種需要多點(diǎn)寫入，類似于需要一些MySQL這種方式。對(duì)比這個(gè)，做這個(gè)圖可以去選擇，合適的復(fù)制方式。

這個(gè)是半同步，半同步的話，比原生復(fù)制多了一點(diǎn)，從這個(gè)時(shí)間里面可以看出來，上面就是原生，寫到從頭不管了，下面就是半同步，半同步是需要同步其中有一個(gè)同步，是需要返回的，所以安全性比較可靠的。

半同步復(fù)制優(yōu)化在5.6和5.7有很多的，5.6還是一個(gè)同步，5.7可以設(shè)置多個(gè)同步。這樣的話安全性可以更好地去保證。下面就是對(duì)半同步更好的優(yōu)化。最后通過改進(jìn)5.6的MySQL提升半同步的性能。

這就是MySQL5.7，這個(gè)是官方提供的多主復(fù)制方案，現(xiàn)在5.7已經(jīng)有了，是可以達(dá)到多組同步復(fù)制化。如果說這個(gè)東西以后能做得好一點(diǎn)的話，會(huì)是一個(gè)比較好的方案。

下面是InnoDB的引擎優(yōu)化，ACID也是目前做得比較好的引用，包括一些特性或者變化，或者是MVCC的一些支持都是非常好的。一些主要參數(shù)，主要參數(shù)是跟性能有關(guān)的基本就這幾個(gè)，5.6加了一些，變化不是特別大。這個(gè)圖就是不同redo，這個(gè)圖左邊是redolog5.5限制不能超過4G，這樣的話，在這種壓力的時(shí)候可控還是有的，每一段時(shí)候會(huì)刷一次，就會(huì)有一次性能對(duì)比，大的時(shí)候，刷的頻率就會(huì)低很多，就會(huì)平穩(wěn)很多。

這個(gè)圖是SSD上的優(yōu)化，這也是不太需要優(yōu)化的。后面這幾點(diǎn)，InnoDB壓縮和cgroup這還是需要的使用單機(jī)多實(shí)例，都是非常有需要的。

這個(gè)是現(xiàn)在MySQL5.6最新5.7版本，它在一些比較重要的參數(shù)上都有一些重要改進(jìn)。說幾個(gè)，第一個(gè)在5.6的時(shí)候還是一樣，5.7已經(jīng)默認(rèn)。這樣安全性會(huì)比之前版本黑更好，而且是已經(jīng)默認(rèn)參數(shù)。下面還有一些預(yù)熱這部分也都是默認(rèn)，還有一個(gè)也比較全部改。下面一個(gè)也已經(jīng)改了，這樣數(shù)據(jù)安全性會(huì)更好。

下面再說一個(gè)，TokuDB。InnoDB的特點(diǎn)，是一種基于結(jié)構(gòu)，正是因?yàn)檫@個(gè)原因，所以寫入密集場(chǎng)景非常好，并且壓縮都是非常不錯(cuò)，也是原生支持，還是有很多吸引人的地方。下面就是主流分支都支持，官方目前最新版本應(yīng)該是這樣，已經(jīng)默認(rèn)了。

MySQL壓縮的我們做的一個(gè)對(duì)比，MySQL有三種。移動(dòng)也是壓縮，它壓縮是用到中間這種方式，右邊圖就是一個(gè)對(duì)比，可以看到，壓縮比是最好的黃色的，比另一個(gè)小好一些，好兩到三倍?，F(xiàn)在使用的時(shí)候，都會(huì)使用這種InnoDB來做，寫字優(yōu)化是非常好的。

這個(gè)就是我們之前做的一個(gè)MySQL寫入性能對(duì)比?？梢钥吹缴厦鎺讉€(gè)陡的都是InnoDB，一開始特別高的是另外一個(gè)。很多可以看到InnoDB一開始跟他只明白四、五千，而TokuDB在整個(gè)過程中都是非常穩(wěn)定。

TokuDB有一些問題，還是有不少漏洞，現(xiàn)在版本更新非?？?，所以更新面還是要謹(jǐn)慎使用。

最后說一下數(shù)據(jù)庫(kù)存儲(chǔ)變遷，近幾年也是變化非?？斓?，還有一個(gè)集中式分布式的演進(jìn)，這個(gè)東西也是一個(gè)過程，不是誰好誰壞的過程，也是一個(gè)相互演進(jìn)的過程。比如像最早的機(jī)械硬盤時(shí)代，從誕生到2001年之前都是在機(jī)械硬盤，機(jī)械硬盤也比較差，前三、四年發(fā)展，來適應(yīng)這種機(jī)械硬盤的讀寫特性，但是隨著互聯(lián)網(wǎng)的發(fā)展，它的瓶頸越來越明顯，當(dāng)時(shí)最多的一個(gè)上面，掛20多以上，全是機(jī)械硬盤，掛20多個(gè)一旦出現(xiàn)一些緩存問題，還是不行，單一性實(shí)在太差。這種性能問題，導(dǎo)致你需要批判，因?yàn)槟阈阅芴螅瑪?shù)據(jù)太小，滿足你業(yè)務(wù)的一個(gè)需求。

后來就是閃存時(shí)代，最早是NAND技術(shù)出現(xiàn)，互聯(lián)網(wǎng)是最新開始吃螃蟹，在2001年的時(shí)候，成本高很多，每GB很高，它的也是非常明顯，有擊敗被的提升。所以說在當(dāng)時(shí)閃存剛剛起步的時(shí)候，主要性還是保持一個(gè)懷疑。后面再往下發(fā)展，混合存儲(chǔ)，閃存還是太貴了，手機(jī)成本節(jié)約，會(huì)出現(xiàn)混合存儲(chǔ)，代表性就是用SSD的緩沖來解決這樣一個(gè)問題。你的讀寫最好有比較明顯的熱點(diǎn)，微博這幾年也用過兩年多，當(dāng)然中間還是有很多問題。下面就說到問題，運(yùn)維SSD的壽命還是非常大。

責(zé)任就是現(xiàn)在的時(shí)代，閃存2.0時(shí)代都不是問題，成本低，基本上都采用SSD這種方式。

SSD肯定還會(huì)有人懷疑，隨著SSD出現(xiàn)就有問題，SSD壽命會(huì)不會(huì)有問題，肯定會(huì)有問題，有一個(gè)極限，如果你買SSD產(chǎn)品你寫80T都有限制，當(dāng)然這個(gè)東西對(duì)你業(yè)務(wù)來說你要算一下能夠扛多少年，你算算能寫好多年，這個(gè)壽命不太需要考慮。第二個(gè)SSD比HDD會(huì)不會(huì)更可靠，這是非常顯然的，肯定是可靠，因?yàn)樗囊恍﹩栴}，非常容易出現(xiàn)磁盤的損害，非常容易出現(xiàn)，整體比SSD低很多。第三故障率，很快剛才一樣比HDD要好很多，所以現(xiàn)在不用需要懷疑。

為什么要采用善存，因?yàn)檫@種人還是要比機(jī)器貴，人你要算工資，機(jī)械材料便宜。

最后說一下分布式存儲(chǔ)，這個(gè)我們之前也測(cè)試過，基于MySQL，我覺得它在未來這幾年也是一個(gè)不錯(cuò)的方向，它對(duì)于規(guī)律和數(shù)據(jù)庫(kù)的收縮性都是非常有好處的。當(dāng)然它的缺點(diǎn)或者它一個(gè)風(fēng)險(xiǎn)，你發(fā)現(xiàn)它放在一個(gè)里面，當(dāng)然技術(shù)發(fā)展這個(gè)問題肯定會(huì)逐漸解決的。

這就是之前好多人問的，我們當(dāng)時(shí)在微博上搞了60億表的問題，當(dāng)然數(shù)據(jù)也是比較核心，數(shù)據(jù)也都是這種粉飾。所以它單表的話，單表的數(shù)在60億以上，原因也有很多。DB比較懶，導(dǎo)致的問題，但是還有一個(gè)想看看極限，到底能到多少。這個(gè)東西其實(shí)不大，確實(shí)是有風(fēng)險(xiǎn)，我們也清楚，一個(gè)單表恢復(fù)，這個(gè)肯定有風(fēng)險(xiǎn)，但是你的方案足夠成熟，其實(shí)也都是可以接受的。這個(gè)東西在你當(dāng)前能解決問題的情況下，沒必要搞一些過于超前的方案。能解決問題的情況下，或者在你能力范疇之內(nèi)，能解決問題，就可以了。

最后就是總結(jié)，你整個(gè)數(shù)據(jù)庫(kù)的標(biāo)準(zhǔn)化或者自動(dòng)化，在早期都需要關(guān)注的，第二個(gè)平臺(tái)化和服務(wù)化也是做了一個(gè)基礎(chǔ)平臺(tái)主要目標(biāo)，優(yōu)化也是無止境的，還有適合自己才是最好的。所以說有時(shí)候拿著錘子不要看所有東西都是釘子，要選擇自己合適的，要選擇自己把控的東西，不要為了嘗試一些新技術(shù)而去嘗試，很多東西都是有成本的。

這是我的微博、微信，有興趣可以加一下。

新聞名稱：美圖網(wǎng)楊尚剛：數(shù)據(jù)庫(kù)運(yùn)維和性能優(yōu)化之路
當(dāng)前URL：http://jinyejixie.com/article22/sdcpjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、微信小程序、外貿(mào)網(wǎng)站建設(shè)、定制網(wǎng)站、商城網(wǎng)站、移動(dòng)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)