直播回顧|丁奇剖析數(shù)據(jù)庫性能-創(chuàng)新互聯(lián)

騰訊云數(shù)據(jù)庫國產(chǎn)數(shù)據(jù)庫專題線上技術(shù)沙龍正在火熱進(jìn)行中，3月5日林曉斌（丁奇）的2020首場(chǎng)分享已經(jīng)結(jié)束，沒來得及參與的小伙伴不用擔(dān)心，下面就給大家奉上直播視頻全程回顧，流量傷不起的小伙伴們也可以看由騰訊云數(shù)據(jù)庫整理好的文字稿，干貨滿滿，保證讓你有所收獲。

公司主營(yíng)業(yè)務(wù)：網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出千陽免費(fèi)做網(wǎng)站回饋大家。

關(guān)注“騰訊云數(shù)據(jù)庫”公眾號(hào)，回復(fù)“0305丁奇”，即可下載直播分享PPT。

點(diǎn)擊查看完整直播回放

圖文直播回顧

大家好！我是騰訊云數(shù)據(jù)庫的林曉斌，在社區(qū)活動(dòng)的時(shí)候網(wǎng)名叫丁奇，跟比較多的同學(xué)互相認(rèn)識(shí)，今天跟大家就是找個(gè)機(jī)會(huì)聊一下數(shù)據(jù)庫的基礎(chǔ)，還有騰訊自研數(shù)據(jù)庫的技術(shù)演進(jìn)，我相信來聽的同學(xué)應(yīng)該都是對(duì)數(shù)據(jù)庫都比較熟悉，前面的內(nèi)容會(huì)比較快地過，主要還是講我對(duì)數(shù)據(jù)庫典型架構(gòu)的一些理解，當(dāng)然我知道MySQL的分享有很多，所以今天的大部分內(nèi)容可能很多人都比較熟了，但是如果有一兩個(gè)點(diǎn)，你覺得好像是個(gè)新東西，我覺得我們就成功了。

首先先說數(shù)據(jù)庫的基本概念，實(shí)際上其實(shí)如果我們只是要一個(gè)數(shù)據(jù)庫的話，數(shù)據(jù)庫就是拿來存東西的，存跟取就是它的基本功能。

在這里可以舉一個(gè)暴露年齡的例子——就是我21世紀(jì)初讀大學(xué)的時(shí)候，給老師課程網(wǎng)站和外面公司做信息管理系統(tǒng)都用的是Access，那個(gè)時(shí)候就覺得只要我會(huì)建了索引數(shù)據(jù)庫就都掌握了，數(shù)據(jù)庫挺簡(jiǎn)單的。當(dāng)然后面事實(shí)證明是我自己太簡(jiǎn)單了，后來工作有機(jī)會(huì)接觸Oracle和MySQL這些工業(yè)數(shù)據(jù)庫，才算是知道了什么是真正的數(shù)據(jù)庫。

實(shí)際上我們說數(shù)據(jù)庫發(fā)展到現(xiàn)在，一直會(huì)有這么幾個(gè)挑戰(zhàn)——可靠性、可用性、安全性、性能和成本等，因?yàn)榻裉鞎r(shí)間的關(guān)系也很難全部講，所以今天我們就講一個(gè)點(diǎn)—— 性能。

那么性能的問題是怎么來的？

如果數(shù)據(jù)量很小，訪問量也很小，其實(shí)一個(gè)Access就夠了，甚至如果更小一點(diǎn)，搞不好一個(gè)Excel就夠了是吧？實(shí)際上真正給性能問題帶來挑戰(zhàn)的，主要是以下3個(gè)方面的原因：

1.大數(shù)據(jù)量。數(shù)據(jù)量特別大，存跟取影響了性能；

2.大并發(fā)。比如有很多個(gè)請(qǐng)求或者很多個(gè)客戶端一起來訪問；

3.讀寫模式。讀寫模式什么意思呢？雖然是同一份數(shù)據(jù)，但是我們?cè)诓樵兊臅r(shí)候，會(huì)有不同的查詢需求，比如說以前論壇的帖子列表，如果你只是按順序顯示出來，那是比較簡(jiǎn)單的；如果你要在里面搜東西那會(huì)難一點(diǎn)；如果你還要做一些統(tǒng)計(jì)和做一些分析，那就更難了。不同的讀模式，對(duì)數(shù)據(jù)庫的查詢壓力是不同的。越復(fù)雜的，比如剛才說的搜索或者說分析等這樣的操作本身對(duì)數(shù)據(jù)庫的讀的壓力就跟普通的按行讀取不一樣，所以這些是我們真正需要去解決的數(shù)據(jù)庫性能問題。

說到這里就需要談到MySQL的基本架構(gòu)，它在解決不同的讀寫模式上面剛好有優(yōu)勢(shì)。下面這個(gè)圖大家應(yīng)該比較熟悉了，這是MySQL的基本架構(gòu)。MySQL是分成上下兩層的，上面這個(gè)框我們叫做server層，就是服務(wù)器層，負(fù)責(zé)跟客戶端做連接，做分析器、優(yōu)化器、執(zhí)行器，下面會(huì)分成多種類型的引擎，這是MySQL相比于其它的數(shù)據(jù)庫特有的一個(gè)特性， 可以接不同的引擎，每一種引擎可以設(shè)定自己的讀寫存取模式和索引的構(gòu)建方式，來應(yīng)對(duì)不同的查詢需求。

常見的MySQL引擎有很多，比如說MyISAM，就是MySQL原生的一個(gè)引擎，在MySQL5.5之前是默認(rèn)的存儲(chǔ)引擎，但是它的問題是不支持事務(wù)，也不支持crash-safe，就是主機(jī)斷電的時(shí)候可能會(huì)丟數(shù)據(jù)，所以后面用得越來越少了。

Innodb現(xiàn)在是最主流的關(guān)系數(shù)據(jù)庫引擎，它解決了什么問題呢？首先它能支持事務(wù)的ACID特性，也支持崩潰恢復(fù)，所以變成現(xiàn)在最主流的MySQL引擎了。

Memory引擎用得也挺多的，早期版本Innodb的性能還沒那么好的時(shí)候，我們有時(shí)候會(huì)想用內(nèi)存引擎來替代Innodb，這樣的話可能會(huì)快一點(diǎn)。當(dāng)然我們知道Memory引擎重啟以后數(shù)據(jù)會(huì)丟失，但是有時(shí)候純粹就把它拿來當(dāng)緩存服務(wù)用，有些公司的dba會(huì)喜歡用Memory，實(shí)際上Innodb發(fā)展到現(xiàn)在，其實(shí)已經(jīng)可以不需要Memory引擎了。數(shù)據(jù)量小的話，放在Innodb里面基本上都是可以全部緩存的。

那寫的能力呢？如果說Innodb是磁盤型的，寫的時(shí)候要落盤，其實(shí)性能一方面是現(xiàn)在的SSD硬盤普及也快了，另外一個(gè)很重要的原因是因?yàn)镸emory不支持并發(fā)，你看上去單個(gè)線程的讀寫很快，但是如果你有兩個(gè)線程一起要更新同一張表的時(shí)候，它就要排隊(duì)，不像Innodb一樣支持行鎖。所以現(xiàn)在從總體看通用的使用場(chǎng)景的話，Memory其實(shí)是不如Innodb的，所以慢慢用的比較少，像騰訊云的CDB現(xiàn)在直接不建議也不允許用戶創(chuàng)建內(nèi)存引擎了。infobright可能也是老玩家才知道的，就是一個(gè)列存引擎，可以做OLAP業(yè)務(wù)的一個(gè)引擎。

blackhole是一個(gè)黑洞引擎，是什么意思呢？只有表結(jié)構(gòu)，往里面寫的數(shù)據(jù)都不存，直接就沒了，也不會(huì)給你訪問報(bào)錯(cuò)，只會(huì)告訴你執(zhí)行成功，看上去像個(gè)黑洞，一會(huì)我們也會(huì)介紹一下這種引擎的使用場(chǎng)景。

federated是一個(gè)遠(yuǎn)程鏈接的引擎，你在這邊建一個(gè)表，但實(shí)際上數(shù)據(jù)不是存在本地，可以讓你定義數(shù)據(jù)源在哪里，然后到另外一個(gè)地方去取。

還有RocksDB和TokuDB引擎，是基于LSM或者fractal tree，不是基于B+tree的一個(gè)支持事務(wù)的引擎，這兩個(gè)引擎比較明顯的特點(diǎn)是壓縮率比Innodb高，主要原因是壓縮塊比較大，我們知道Innodb里面16K一個(gè)塊來壓縮的，越大的單位數(shù)據(jù)壓縮效果會(huì)越好，像TokuDB是4M一個(gè)塊來壓縮的，所以它的壓縮比高，當(dāng)然它帶來問題就是讀的時(shí)候CPU消耗多一點(diǎn)。

比較常見的是這些引擎，當(dāng)然你可能還可以列出別的，但基本上社區(qū)用的比較多的是這一些。

那么MySQL有這種多引擎的架構(gòu)，有什么好處？剛才我們說了，當(dāng)一個(gè)業(yè)務(wù)既需要TP型的業(yè)務(wù)，但是又需要做列存和分析時(shí)，如果是換別的數(shù)據(jù)庫，比如說postgresql或者Oracle，本身就很難同時(shí)兼容這兩種能力。而MySQL可以不走引擎，我可以表A創(chuàng)建出一個(gè)Innodb表，表B創(chuàng)建一個(gè)infobright表，然后數(shù)據(jù)在里面做同步，以后我如果要做oltp的查詢，就找Innodb表查，AP的查詢就找infobright查，至少它的架構(gòu)可以這么做。有的同學(xué)會(huì)覺得很奇葩，混合引擎這種是不是很少見？其實(shí)并不是，MySQL天然就這么干的，默認(rèn)的存儲(chǔ)引擎我們現(xiàn)在都用Innodb，實(shí)際上MySQL自己的系統(tǒng)庫在5.6和5.7及以前的版本都是用的MyISAM，如user表，這個(gè)是存用戶的表、還有存庫名的表等，其實(shí)就是放在MyISAM里面，所以MySQL本身就在踐行混合引擎，當(dāng)然是需要特別謹(jǐn)慎的。

舉個(gè)例子，比如跨引擎事務(wù)的一致性問題。我們知道Innodb是支持事務(wù)的，而MyISAM是不支持的，假設(shè)說現(xiàn)在有一個(gè)庫，里面有兩個(gè)表，T1是MyISAM表，T2是Innodb表，如果你分別使用是沒有問題的，如果我們想要事務(wù)，begin啟動(dòng)一個(gè)事務(wù)，往T1表里面插入一行，再往T2表里插入一行，然后執(zhí)行一個(gè)rollback，我們認(rèn)為既然begin后面沒有提交，然后最后執(zhí)行的一個(gè)rollback，那就應(yīng)該T1跟T2這兩個(gè)插入都撤銷，這就是事務(wù)的原子性，要么都成功，要么都失敗。

但是因?yàn)镸yISAM不支持事務(wù)，也就是說insert into T1執(zhí)行完以后，馬上就持久化了，就寫到數(shù)據(jù)里面去了，所以這一個(gè)序列執(zhí)行完成以后，在數(shù)據(jù)庫里就會(huì)看到T1里的那條數(shù)據(jù)還在，T2里面的這條又不在了，這個(gè)是違反了事務(wù)的原子性規(guī)則的，對(duì)，但不是引擎的問題，這是因?yàn)槲覀儗懛ū旧碛袉栴}。這樣你也會(huì)更明確知道：原來事務(wù)的特性是實(shí)現(xiàn)在引擎里的，支持的引擎就支持，不支持的引擎它就只好忽略。我自己之前在應(yīng)用的一些場(chǎng)景里面也用過，同一個(gè)數(shù)據(jù)庫里面有不同引擎的表是OK的，但是當(dāng)你要用到一些引擎的特性的時(shí)候，像事務(wù)，或者說savepoint、全文檢索這種比較特殊的特性，或者全文檢索的時(shí)候，就要去關(guān)注引擎到底支不支持，如果不支持那就不能做，不能混用。

這種場(chǎng)景大家可能會(huì)說好像用的不太多，我們?cè)倏聪旅孢@個(gè)圖，把Innodb跟infobright放到一起，雖然MySQL天然就支持，但是它有個(gè)問題，感覺看上去不是很專業(yè)，還有比如說你在infobright上面跑AP的請(qǐng)求，雖然也可以，但是畢竟我們知道它們共用的server層是同一份，這樣的話會(huì)不會(huì)導(dǎo)致它們互相爭(zhēng)強(qiáng)CPU？其實(shí)是會(huì)的，那如果想要想剝離出來可以怎么做？那就是下面這個(gè)圖。

就是說你可以搭建兩個(gè)不同的MySQL實(shí)例，然后主實(shí)例用Innodb引擎。slave實(shí)例用infobright引擎。因?yàn)镸ySQL的主從同步是可以支持跨索引跨引擎的，也就是說假設(shè)左邊有一個(gè)表T1，它是Innodb表，而同步過來，slave上面的T1，手動(dòng)把它改成infobright或者別的引擎的表，這樣是可以同步的。也就是說往主庫里面做增刪改，都可以同步到從庫的infobright相同的表名里面，之后你要做AP型的查詢，就直接到從庫這里面來查，它是列存的，這種OLAP的請(qǐng)求就足夠快，這是其中的一種用法。

另外這種用法其實(shí)還是有比較多的引申版本，比如說中間這個(gè)通道，現(xiàn)在圖里面看到我這樣畫，其實(shí)就是MySQL天然的主從同步機(jī)制，當(dāng)然我們可以中間放一個(gè)數(shù)據(jù)傳輸組件DTS，然后從主庫拉日志到從庫去應(yīng)用，這個(gè)是類似的，這是一種場(chǎng)景，這種場(chǎng)景下面解決的是什么問題？主庫跟備庫的數(shù)據(jù)是一樣的，查詢的邏輯不太一樣，需要備庫提供更強(qiáng)的不同于Innodb的能力，這個(gè)時(shí)候就可以換一個(gè)引擎來用，這種場(chǎng)景還是偶爾會(huì)見到。

還有另外一個(gè)場(chǎng)景，黑洞引擎有什么用？

我們還是回到圖的左邊，左邊是一樣的，TP這個(gè)業(yè)務(wù)MySQL里面寫，里面是Innodb表，然后傳到從庫去，從庫把它改成blackhole引擎。我們剛才說到了blackhole引擎只有表結(jié)構(gòu)，數(shù)據(jù)寫進(jìn)來以后數(shù)據(jù)就沒了，那么你傳過來干嘛呢？傳過來存binlog。MySQL的機(jī)制是當(dāng)左邊寫了數(shù)據(jù)跟日志以后，如果要同步給從庫的話，它一定要把binlog傳過來給從庫，從庫收到日志以后做什么事？做兩件事，先把日志存在本地，再把本地的日志拿來應(yīng)用，應(yīng)用完以后，再從庫里面生成出一份相同的日志。如果你把它改成blackhole引擎，那后面那一步就沒有用了，拿到日志，后面的執(zhí)行就是空?qǐng)?zhí)行， 表雖然沒有，但是日志還在，那簡(jiǎn)單來說這個(gè)就可以用來存binlog，這樣話要備份binlog就不需要到主庫上面去拷了。去主庫上面拷也不實(shí)時(shí)，通過這種方式就可以實(shí)時(shí)拿到binlog。當(dāng)然現(xiàn)在這只是說MySQL天然支持這樣的機(jī)制，實(shí)際上現(xiàn)在社區(qū)也有不少比較優(yōu)秀軟件本身也可以做相同的事情，可以模擬binlogserver的行為，找主庫要binlog，要完以后也不應(yīng)用，就存在本地，只是說如果我們要搭建一個(gè)簡(jiǎn)單的binlog server，就可以讓從庫用blackhole引擎，其實(shí)用的也還挺多的。

有的同學(xué)說這看上去有點(diǎn)傻，還不如用像社區(qū)的那些方案，實(shí)際上如果可以再往前擴(kuò)展一下，還可以想到別的場(chǎng)景，比如說我們要做分布式的場(chǎng)景，一般要多個(gè)節(jié)點(diǎn)，因?yàn)橐鲞x舉對(duì)吧？比如說我們要做跨中心跨城市的高可用集群時(shí)候，集群節(jié)點(diǎn)可能很多，比如說在A城市有5個(gè)節(jié)點(diǎn)，B城市有4個(gè)節(jié)點(diǎn)，9個(gè)跑起來特別爽，是吧？掛了一個(gè)以后都可以選舉選出來，它有個(gè)問題是什么？成本比較高，因?yàn)槟忝總€(gè)地方都要放數(shù)據(jù)，這樣的話有沒有節(jié)約成本的方法？之前也有人踐行過這樣的方案，就是說這9個(gè)節(jié)點(diǎn)也不是真的要那么多數(shù)據(jù)，其中有一部分純粹就只是想?yún)⑴c選舉而已，甚至于你自己都不想被選成，只是參與投票而已，那就可以用blackhole引擎，它可以同步數(shù)據(jù)跟大家形成交互，然后參與投票，當(dāng)然它要把自己標(biāo)志成不能被選成主，這樣雖然你有9個(gè)節(jié)點(diǎn)的成本，但實(shí)際上你真正需要的存儲(chǔ)可能只有5個(gè)或者4個(gè)就可以了，其它的用binlog server來模擬，這個(gè)也是之前有踐行過的架構(gòu)。

反正在中國大批量使用MySQL到現(xiàn)在有十二三年了，中間各種各樣的架構(gòu)都出現(xiàn)過。再說到另外一個(gè)場(chǎng)景，誤刪了數(shù)據(jù)，然后這時(shí)候你要恢復(fù)，恢復(fù)有一種場(chǎng)景是這樣的，假設(shè)這個(gè)庫里面有業(yè)務(wù)數(shù)據(jù)表A，還有業(yè)務(wù)日志表B，一般來說日志表都比數(shù)據(jù)表比較大很多，因?yàn)橹虚g記了各種流水，我想恢復(fù)出一個(gè)庫，恢復(fù)數(shù)據(jù)是拿昨天的備份恢復(fù)的，然后拿到全量數(shù)據(jù)后應(yīng)用binlog追到我要的時(shí)間點(diǎn)。而如果現(xiàn)在特別著急的想要，又剛好昨天業(yè)務(wù)壓力大，所以日志表的更新量特別大，恢復(fù)出去全量備份以后，接下來你拿日志不停地應(yīng)用，然后你會(huì)發(fā)現(xiàn)多時(shí)間都在等日志表的回復(fù)，因?yàn)槿罩颈砀露唷Ｈ绻椰F(xiàn)在很明確，先暫時(shí)不要日志表，先把這個(gè)數(shù)據(jù)表給恢復(fù)出來，有什么方法？當(dāng)然方法有好多，我只是說如果用blackhole可以這么干，你就把日志表給它清空掉，或者說移走，然后創(chuàng)建一個(gè)同名的，引擎叫Blackhole的表，放在那邊是一個(gè)空表。接下來它開始追日志，它的好處是現(xiàn)在日志表追的特別快，因?yàn)檫@個(gè)引擎的特性是什么？你寫的時(shí)候它就一看我是blackhole引擎，命令過來，就直接跳過，這樣應(yīng)用就非?？?，這樣話你就可以快速達(dá)到恢復(fù)數(shù)據(jù)表的目的。所以支持引擎其實(shí)還是有點(diǎn)有趣的，雖然說它不是主流的應(yīng)用，但在單機(jī)的MySQL里面支持這樣的能力。

我們接著往下說MySQL的高可用架構(gòu)，大家都知道怎么做高可用，一般是一主兩備或者至少一主一備，然后往主庫寫，主庫掛了就切到從庫去。從左邊切到右邊就實(shí)現(xiàn)了一個(gè)HA，除非AB兩個(gè)一起掛，運(yùn)氣不好，但是概率小很多。如果一臺(tái)機(jī)器掛了是千分之一的概率，兩個(gè)一起掛就是百萬分之一的概率，這個(gè)已經(jīng)很小了，所以一般是這么做的。然后A跟B之間比較主流的實(shí)現(xiàn)會(huì)設(shè)置成互為雙組，這樣話切換的時(shí)候快一點(diǎn)，你只要把客戶當(dāng)成左邊切到右邊就可以了，這是典型的MySQL的高可用架構(gòu)，但這個(gè)不是我們今天描述的重點(diǎn)，只是說我們后面要講的時(shí)候，每講一個(gè)數(shù)據(jù)庫節(jié)點(diǎn)的時(shí)候，它默認(rèn)是帶著主從。

我們還是回到性能這個(gè)問題，我們?cè)趺唇鉀Q讀性能的問題？加機(jī)器！DBA的核心技能兩點(diǎn)，第一個(gè)是重啟，第二個(gè)是加機(jī)器。（笑）

那么加機(jī)器加成什么樣的？我們看到一主好多從，圖中除了A跟A′是用來做主備做高可用的以外，像BCD本身沒有業(yè)務(wù)直接給它們寫數(shù)據(jù)，但是是從A這個(gè)節(jié)點(diǎn)里面把數(shù)據(jù)同步過來的，就是你寫一份A它會(huì)同步給A′做高可用，同時(shí)同步給BCD，BCD拿到日志應(yīng)用完以后，我們認(rèn)為BCD的數(shù)據(jù)跟A是一樣的，接下來客戶端就可以來找BCD來讀了。這樣如果A撐不住讀壓力，可以把讀請(qǐng)求分流分給BCD，這算是比較樸素的方案，在騰訊云MySQL里面有功能叫做RO組，比如說我現(xiàn)在有三個(gè)只讀實(shí)例，三個(gè)只讀節(jié)點(diǎn)，如果再創(chuàng)建一個(gè)，客戶端得改配置。實(shí)際上一般云服務(wù)都會(huì)提供這種能力， 把這些只讀實(shí)例設(shè)置成一個(gè)RO組，接著它們共享同一個(gè)訪問方式，或者同一個(gè)域名，或同一個(gè)IP，接下來寫只要寫一個(gè)，讀也只要讀一個(gè)，RO組會(huì)幫你做查詢的輪巡和流量的分擔(dān)。

但有的同學(xué)說看著還是麻煩，寫和讀難道就不能也湊成同一個(gè)IP嗎？這樣我還得知道寫是寫哪個(gè)，讀是讀哪一組，讀跟寫畢竟兩個(gè)IP，有沒有偷懶加機(jī)器的方法或者說透明加機(jī)器的方法？有！就是下面可以加個(gè)proxy。

下面加一個(gè)中間層以后其實(shí)底層的架構(gòu)是一樣的，只是說往proxy里面訪問的時(shí)候，proxy幫你做分流，如果是一個(gè)寫操作發(fā)給主庫，如果是讀操作發(fā)給下面其他讀節(jié)點(diǎn)，所以本質(zhì)上是差不多的，好處就是你可以省得自己去管了，并且也不需要考慮擴(kuò)容。

比如說騰訊的TDSQL就支持這個(gè)讀寫分離的模式，你要加節(jié)點(diǎn)的話，你也不用管了，就是下發(fā)一個(gè)加節(jié)點(diǎn)的需求，內(nèi)部它自己幫你復(fù)制出一個(gè)E節(jié)點(diǎn)，然后把數(shù)據(jù)全量的恢復(fù)完以后追日志，然后再跟A建立主從關(guān)系等等，做完以后你就做了一個(gè)節(jié)點(diǎn)了，這種方式可以解決我們的讀性能問題，那讀性能解決了，寫性能怎么辦？我們看到剛才這兩種模式，它們有個(gè)共同的特點(diǎn)——讀是可以讀好多個(gè)，能寫只能寫一個(gè)，如果寫A撐不住了怎么辦？分庫分表。所以我們說 寫性能就只能靠分布分表了，TDSQL也支持分庫分表的模式，就是你寫下來，然后做路由，當(dāng)然這個(gè)路由要事先和數(shù)據(jù)庫約定好分表的方式和分片的方式，比如說創(chuàng)建一個(gè)表，然后用戶ID取模，這樣的方式也是比較常見的分庫分表的模式。

現(xiàn)在還有一些比如計(jì)算存儲(chǔ)分離等模式，思路其實(shí)是差不多的，都是用來解決同一個(gè)問題，就是通過水平擴(kuò)展節(jié)點(diǎn)的方式來分?jǐn)傋x壓力或者寫壓力，然后提升我們整個(gè)系統(tǒng)的吞吐量。但是實(shí)際上MySQL也不是全能的，其實(shí)你想了各種方案，但是還是有支持不了的場(chǎng)景的。

舉個(gè)例子，比如說OLAP就不支持，像剛我們說的infobright還可以，但實(shí)際上infobright現(xiàn)在用的也不是那么多，真的做OLAP實(shí)際上是有專門的系統(tǒng)來做的，一會(huì)兒我們可以舉一個(gè)例子。

像圖這種關(guān)系數(shù)據(jù)庫，比如說MySQL，我們大家都知道是標(biāo)準(zhǔn)的二維表，要描述一個(gè)圖只能用這種遞歸查詢的方法，性能天然就有問題，你可以做，所有關(guān)系最后都表達(dá)一個(gè)二維表的關(guān)系，無非是這個(gè)關(guān)系處理比較蹩腳而已，速度會(huì)慢。

時(shí)序數(shù)據(jù)庫，能不能用一個(gè)InnoDB表來存時(shí)序表？當(dāng)然也可以，insert從一開始往后追加，然后查的時(shí)候也是，讀的時(shí)候也是，從一開始往后刪也是，看上去就是一個(gè)先進(jìn)先出的隊(duì)列，可以這么做，但是是浪費(fèi)的，因?yàn)橐粋€(gè)時(shí)序的場(chǎng)景只需要先進(jìn)先出這個(gè)功能，所以InnoDB提供了那么多中間數(shù)據(jù)的讀寫能力，其實(shí)是一個(gè)浪費(fèi)，而這種浪費(fèi)體現(xiàn)在時(shí)序數(shù)據(jù)庫應(yīng)用場(chǎng)景上面來說，在最簡(jiǎn)單的場(chǎng)景里，就是性能不行。

還有一個(gè)是搜索，雖然大家也知道最早MyISAM的引擎還支持一些全文檢索，后來Innodb為了替換掉MyISAM，官方也給Innodb加上了全文檢索的能力，但是據(jù)我所知，也沒有哪個(gè)公司真的要使用全文搜索能力的時(shí)候會(huì)大批量使用Innodb，而是會(huì)去搭建真正的像ES這樣的全文檢索引擎，圖也是一樣，OLAP有OLAP自己的系統(tǒng)，所以MySQL還是有它不適用的場(chǎng)景，核心的原因其實(shí)是數(shù)據(jù)結(jié)構(gòu)，我之前在《MySQL實(shí)戰(zhàn)45講》里面跟大家有提到，當(dāng)我們?nèi)?分析要選擇哪一個(gè)數(shù)據(jù)庫的時(shí)候，核心的點(diǎn)是要先考察數(shù)據(jù)結(jié)構(gòu)，如果它是一個(gè)列存的需求，每次查詢可能要查詢一個(gè)一億行，但是我就是要只查詢于其中一列，這種場(chǎng)景特別多，MySQL能不能做？能做，但是MySQL是行存，每次你要取一個(gè)一億行的第一列的時(shí)候，它就必須把那一行全部讀進(jìn)來，然后就浪費(fèi)了很多IO資源和不必要的CPU消耗。這個(gè)時(shí)候如果有一個(gè)專門做列存的，它有一個(gè)文件專門存了這一個(gè)表第一列的數(shù)據(jù)，讀的時(shí)候就直接讀出來，就減少了大量的IO消耗跟CPU消耗，這就是數(shù)據(jù)結(jié)構(gòu)帶來的優(yōu)勢(shì)。

MySQL雖然也支持，也有說往MySQL里面加一些引擎來支持，但是如果我們主流用Innodb，它就不適合做這個(gè)事。還有比如說搜索也是，我明明要的是一個(gè)倒排表，可是你非得給我個(gè)關(guān)系數(shù)據(jù)庫，所以它本質(zhì)一樣是一個(gè)數(shù)據(jù)結(jié)構(gòu)的問題。我覺得這樣才好，MySQL就要有這么多不適用的場(chǎng)景，不能有哪個(gè)數(shù)據(jù)庫可以通吃所有的場(chǎng)景，那樣才麻煩。我們舉個(gè)例子，比如HTAP這種場(chǎng)景，剛才我們前面有個(gè)圖說了，我用一個(gè)MySQL加了一個(gè)infobright也可以，但是不是最專業(yè)的，它畢竟還是一個(gè)單機(jī)版，其實(shí)現(xiàn)在比較主流的方式，把這里替換成一個(gè)專門做AP，在AP上面有很強(qiáng)能力的一個(gè)產(chǎn)品，這樣它天然就可以支持，而且中間的比如說往這里寫的TP還可以自己寫，然后數(shù)據(jù)傳輸留的通道也可以保持，只是你把下面這個(gè)核換成一個(gè)可以專門支持這種場(chǎng)景能力的產(chǎn)品，比如騰訊云TBase，它就可以專門支持這樣的場(chǎng)景然后來解決，這樣才好。

做一個(gè)小結(jié)，我們雖然只討論了性能問題，性能問題其實(shí)只是數(shù)據(jù)庫發(fā)展過程中碰到的各種復(fù)雜問題其中的一個(gè)，而且目前看來，甚至于它大多數(shù)時(shí)候不是最嚴(yán)重的，是吧？安全性、可靠性那些才是挺難的。另外，每一個(gè)方案都是妥協(xié)的結(jié)果，讀寫分離看上去很美，實(shí)際上它不能解決寫的問題，分庫分表看上去更美，但是中間proxy往往要處理SQL兼容性的問題，因?yàn)槟莻€(gè)時(shí)候你的proxy就需要做很多數(shù)據(jù)本身的操作，就會(huì)碰到語法兼容性的問題。數(shù)據(jù)庫后來就會(huì)碰到更多的挑戰(zhàn)了，在我看來接下來智能化運(yùn)維是重點(diǎn)方向之一，當(dāng)然現(xiàn)在大家基本上也是每個(gè)系統(tǒng)也做到了智能輔助，做到智能輔助就算不錯(cuò)了?，F(xiàn)在業(yè)務(wù)量越來越大，像我們?cè)谝咔槠陂g支持騰訊會(huì)議的時(shí)候，我們一些智能化的能力會(huì)減少DBA的工作量，并且提升線上的服務(wù)質(zhì)量，DBA的精力可以解放出來去做更有價(jià)值的事情。

QA環(huán)節(jié)

Q1：講講微盟的刪庫事件？

A1：我覺得只是微盟這次運(yùn)氣不好，碰到這個(gè)事情比較嚴(yán)重。說回我們?cè)隍v訊運(yùn)營(yíng)的服務(wù)過程中，經(jīng)常碰到這種客戶，需要回滾，恢復(fù)誤刪的數(shù)據(jù)。另外一個(gè)公司，也是比較有名的互聯(lián)網(wǎng)公司最近也碰到一個(gè)誤刪庫了，那這個(gè)怎么辦？如果你用云數(shù)據(jù)服務(wù)，碰到這種情況，之后就是一個(gè)常規(guī)操作，找一下昨天的備份，然后把日志下載再應(yīng)用就行了。有同學(xué)會(huì)說你放在云上，我是個(gè)黑客想惡意操作，進(jìn)去把數(shù)據(jù)和備份刪了，你不是一樣蒙圈？其實(shí)實(shí)際上云會(huì)考慮更多的點(diǎn)，騰訊云這邊假設(shè)你真的有操作數(shù)據(jù)庫、生產(chǎn)庫的權(quán)限，那么或者你可以把庫刪掉，但是備份是刪不了的。我們的備份有兩種，一個(gè)是定期備份，一個(gè)是用戶主動(dòng)生成的備份，定期備份的備份是不讓刪除的，比如說你配置了一天備一次保留7天，你只能把數(shù)據(jù)刪掉，這固定保留7天的備份是不能刪的，如果真的出現(xiàn)了這種情況的時(shí)候，我們會(huì)保證一定能夠恢復(fù)出來。那我們?cè)趦?nèi)部的工程師會(huì)不會(huì)有這樣的權(quán)限？也沒有。其實(shí)我們是分開的，可以管理生產(chǎn)服務(wù)器的工程師訪問不了備份。其實(shí)發(fā)展到現(xiàn)在每個(gè)公司對(duì)數(shù)據(jù)庫能力的理解不會(huì)差很多，尤其人才流動(dòng)，所以各個(gè)公司數(shù)據(jù)庫的leader其實(shí)我覺得水平都是差不太多的，而云的一個(gè)好處是以前碰到過各種突發(fā)情況的訓(xùn)練，通過不斷迭代，終于構(gòu)建出一個(gè)可以cover住大部分場(chǎng)景問題的解決方案。

Q2：TBase是基于PG演進(jìn)出來的HTAP數(shù)據(jù)庫，為什么不考慮在TDSQL中加入OLAP的能力呢？

A2：TDSQL我們會(huì)考慮，因?yàn)閯偛耪f了TDSQL本身上面的框架就可以支持讀寫分離，也可以支持分庫分表，中間那一層proxy，其實(shí)已經(jīng)可以認(rèn)為它已經(jīng)完全兼容了MySQL的協(xié)議，接下來下面如果要AP的，其實(shí)換成AP節(jié)點(diǎn)是可以的，實(shí)際上也在我們的路線里面，只是說目前還沒有把它產(chǎn)品化出來，就放到云上而已。

Q3：MySQL的分布分表有哪些成熟的可靠的方案？

A3：其實(shí)我看到最成熟就是找個(gè)維度分表，取決于你的查詢模式。舉個(gè)例子，如果你是做在線教育的，然后假設(shè)你是一個(gè)學(xué)生表，你就按學(xué)生ID或者按學(xué)生城市做這樣的分表，基本上這樣就可以了，我感覺沒有很復(fù)雜的點(diǎn)。當(dāng)然你需要解決的問題是如果你按城市分的表，按城市分庫，這時(shí)候你要做一個(gè)查詢，這個(gè)查詢要統(tǒng)計(jì)所有9歲學(xué)生的情況，這個(gè)時(shí)候你就不得不給每一個(gè)分庫下發(fā)查詢，這樣成本消耗比較高，性能會(huì)差一點(diǎn)，當(dāng)然對(duì)應(yīng)的有一些解決方案了。你業(yè)務(wù)做了分布分表，假設(shè)一些統(tǒng)計(jì)類的需求，需要做這種不是基于分表索引的查詢的時(shí)候，你可以怎么做？可以有一個(gè)匯總的大庫，要把數(shù)據(jù)匯總回去，大庫里面就可以建各種索引，具體實(shí)施上可能有差異，大方向上場(chǎng)景就是這類架構(gòu)，好像發(fā)展這么多年也沒有搞出新花樣。

Q4：TDSQL的分庫分表模式，對(duì)MySQL語法支持如何？

A4：是這樣的，所有只要你用了分布分表模式的，我都會(huì)建議上來之前一定要做一次業(yè)務(wù)回歸，目前看來90%以上的客戶都是直接遷上來就能用，但如果你的語句里面有那種groupby大量數(shù)據(jù)的時(shí)候，其實(shí)也兼容，但是它的性能會(huì)差一點(diǎn)，或者說性能跟你在本地的時(shí)候不太一樣，這個(gè)時(shí)候就要經(jīng)過測(cè)試，而兼容性以我們目前的情況來說改造量還是比較小。

Q5：為什么基于中間件的分庫分表的方案，各家公司很少會(huì)去實(shí)現(xiàn)分布式事務(wù) 和 數(shù)據(jù)resharding ？

A5：不會(huì)啊，我們做得很多啊，實(shí)際上分布事務(wù)我所了解的幾個(gè)大的公司都在做，因?yàn)檫@個(gè)是繞不開的，畢竟分布分表是一種方向，而下面的節(jié)點(diǎn)之間做分布式事務(wù)是另外一個(gè)方向，而這個(gè)方向確實(shí)理論挑戰(zhàn)會(huì)更大一點(diǎn)，它有它的好處，就是proxy這一層可以做得很輕，甚至于proxy的兼容性問題就直接徹底被解決了。然后選主等就可以在底層自己做，實(shí)際上有在做像比如說目前在研發(fā)中的TDSQL3.0。我們現(xiàn)在在線上使用的TDSQL2.0其實(shí)就是標(biāo)準(zhǔn)的分庫分表的方案。

Q6：可以教教調(diào)試MySQL？

A6：調(diào)試MySQL要看碰到什么問題，如果是比較簡(jiǎn)單的，比如說索引，那比較簡(jiǎn)單，如果說是碰到語句都對(duì)但是性能慢的，這種比較偏于操作型的操作。如果是MySQL這種自己調(diào)優(yōu)的話，其實(shí)可以做一些基本的診斷、開慢查詢?nèi)罩?，像percona toolkit有一些工具，可以直接跑這個(gè)工具看到結(jié)論。當(dāng)然慢查詢?nèi)罩痉治龃嬖谝粋€(gè)問題，可能很多語句不是慢查詢，就是還不到高峰期的時(shí)候，它可能執(zhí)行200ms，一看慢查詢?cè)O(shè)置的是1s，所以會(huì)以為沒什么問題。但是呢，如果壓力一大就撐不住。這個(gè)時(shí)候如果能夠有個(gè)系統(tǒng)，把所有的語句執(zhí)行的情況都記錄起來，然后再去做診斷，那肯定比只有慢查詢要好。比如騰訊云MySQL就支持審計(jì)日志，你只要開了審計(jì)日志，那里面就會(huì)有所有的信息，當(dāng)然你也可以使用DBbrian直接去診斷一下，看看現(xiàn)在的數(shù)據(jù)庫里有什么問題，一般DBbrain會(huì)告訴你存在什么問題，應(yīng)該怎么加索引，可以通過這種方式去了解為什么要這樣做，了解它的原理。

Q7：TDSQL適用的行業(yè)和場(chǎng)景可以舉例說明一下嘛？

A7：MySQL高可用架構(gòu)可以適用很多場(chǎng)景，底層的安全配置也會(huì)在不同的場(chǎng)景不同的應(yīng)用。舉個(gè)例子，比如說TDSQL放在游戲里面，可能只要開啟一個(gè)異步就可以了，不用開全同步，但是像張家港銀行這種案例，TDSQL要放到銀行的核心系統(tǒng)里面去的時(shí)候，能不能用呢，可以。我們有個(gè)配置，必須是全同步，至少一主兩從，數(shù)據(jù)寫進(jìn)去后，另外兩個(gè)節(jié)點(diǎn)都不給我返回，我就不寫了，就會(huì)直接報(bào)錯(cuò)，至少有一個(gè)給我反饋說成功了，它才會(huì)往里面寫，所以現(xiàn)在像TDSQL，我們是定位在做金融數(shù)據(jù)庫上面的。那我想用普通的讀寫分離方法，能不能用TDSQL呢？可以，也沒有問題，最后由你來決定了，比如我不希望當(dāng)有兩個(gè)從節(jié)點(diǎn)都?jí)牧?，就不能寫。我希望還是可以正常讀寫，那你可以設(shè)置成退化的異步模式。適用場(chǎng)景還是蠻多的，行業(yè)不限，還是取決于數(shù)據(jù)的定位。

Q8：怎么判斷MySQL當(dāng)前需要分庫分表?通過什么參數(shù)可以看到嗎？

A8：一般說我們什么時(shí)候需要分庫分表，第一個(gè)很明顯的，如果你的數(shù)據(jù)量大，撐不住了可以使用，比如說一臺(tái)機(jī)器只有10T，但是一個(gè)庫快滿了，這時(shí)候分庫分表比較好理解，那如果是空間還沒到，但是性能撐不住了呢，就可以有幾個(gè)指標(biāo)，比如說一個(gè)是寫的RT，還有一個(gè)是讀寫的RT，還有一個(gè)是讀的命中率，因?yàn)槲覀冎繫ySQL是B+樹的結(jié)構(gòu)，那如果是層數(shù)比較少的時(shí)候，就是大多數(shù)的索引都在內(nèi)存里，那你每一次查詢都可以在內(nèi)存里完成，最后，隨著數(shù)據(jù)量的增大那是不可能了，所以你有1T的數(shù)據(jù)，100G的內(nèi)存，那么會(huì)有十分之一的數(shù)據(jù)直接在內(nèi)存里面，假設(shè)再更大一些，那你的命中率就會(huì)降低，這里有什么參數(shù)可以看呢，就是show engine innodb status這個(gè)命令里面有個(gè)內(nèi)存命中率，你一般看正常線上業(yè)務(wù)的命中率，如果是線上的OLAP，正常的命中率要為99%以上，99.2%、99.3% 這樣才算正常，比如說如果掉到了97%、95% 這種，那就可能就要考慮一下了，可能你還沒有發(fā)現(xiàn)這個(gè)問題，業(yè)務(wù)線來找你了，說為什么我的這個(gè)請(qǐng)求慢了。為什么會(huì)出現(xiàn)這種情況呢，就是因?yàn)槲覀冎繧nnoDB是B+tree組織的，你要訪問一個(gè)數(shù)據(jù)的時(shí)候，你從樹根開始找，要找好幾層才能找到，找到最下面那個(gè)葉子節(jié)點(diǎn)。雖然現(xiàn)在ssd快了，但是如果IO壓力大了，比如說10ms，那你有一次IO加載10ms還好點(diǎn)，如果樹很高，在索引遍歷的過程中需要去訪問磁盤了，那這個(gè)時(shí)候性能就慢下來了，所以呢，內(nèi)存命中率是一個(gè)比較重要的參考指標(biāo)，其實(shí)核心是慢查詢，就是業(yè)務(wù)的反饋。

Q9：您認(rèn)為目前云數(shù)據(jù)庫的痛點(diǎn)和難點(diǎn)分別是什么呢？

A9：我們分兩塊，先說用戶。比如說我是一個(gè)用戶，我用云數(shù)據(jù)庫，覺得首先的痛點(diǎn)就是要提升用戶使用這個(gè)產(chǎn)品的易用性。我是一個(gè)專業(yè)的DBA用這個(gè)數(shù)據(jù)庫能不能把我的能力發(fā)揮出來，在騰訊云數(shù)據(jù)庫現(xiàn)在可以看到好多監(jiān)控信息，但是我能不能更多一些？這個(gè)系統(tǒng)有沒有辦法幫我更多的去提供診斷能力？讓我能夠更快的定位問題？然后把精力省下來去解決我們公司內(nèi)部這種業(yè)務(wù)架構(gòu)問題、數(shù)據(jù)架構(gòu)問題，把我從一個(gè)DBA變成一個(gè)數(shù)據(jù)架構(gòu)師。

另一部分說云服務(wù)商，比如說騰訊云現(xiàn)在有很多的客戶，那每個(gè)客戶都來問數(shù)據(jù)庫為什么慢了，我們團(tuán)隊(duì)那十幾個(gè)DBA同學(xué)早也瘋了，我們系統(tǒng)要有這樣的能力，能夠不只是DBA能解決的了，我們的一線架構(gòu)師、售后甚至客服的同學(xué)用一套工具就能解決大部分的問題。有這個(gè)可診斷性，可以能讓很多能力發(fā)揮出來，可以讓后端解放，可以讓一線輕松，然后可以讓我們的客戶有工具了，可以診斷了，可以發(fā)揮個(gè)人的專業(yè)技能。

Q10：除了云數(shù)據(jù)庫平臺(tái)自己的備份，云主機(jī)自建數(shù)據(jù)庫的情況，平臺(tái)會(huì)自動(dòng)備份數(shù)據(jù)嗎？

A10：如果你是在云主機(jī)上面，就是虛擬機(jī)上面創(chuàng)建數(shù)據(jù)庫的話，虛擬機(jī)本身會(huì)有快照備份，但是這個(gè)快照只有點(diǎn)的快照。舉個(gè)例子，我今天下午五點(diǎn)不小心誤刪了數(shù)據(jù)，那我拿到今天凌晨12點(diǎn)那個(gè)備份可能不夠用，那我還需要中間的binglog，那這個(gè)時(shí)候呢，你做一個(gè)磁盤級(jí)別的鏡像未必有能力真的精確追到五點(diǎn)，如果你用數(shù)據(jù)庫就沒有這個(gè)問題，因?yàn)槲覀兪翘烊灰詫?shí)例級(jí)別和日志級(jí)別來備份的數(shù)據(jù)。

Q11：TDSQL考慮加入AP功能，那么TBASE和TDSQL的定位有什么不同？

A11：TDSQL加入AP能力就是看你要解決的問題有多大，我舉個(gè)例子，假設(shè)我要在TDSQL加一個(gè)搜索能力，那我除了用Innodb的全文檢索以外，還可以在里面放一個(gè)sphinxSE引擎，后面掛一個(gè)sphinx，也可以跑，但是你說我要用它來支撐，比如說這個(gè)騰訊首頁的搜索，那肯定撐不住。那時(shí)候就需要搭建一個(gè)專門的搜索引擎來支持。所以我們往TP系統(tǒng)里面加這種能力，它只能是解決跟我TP很接近，但是不需要那么大的計(jì)算量的搜索，我可以支持一下，其實(shí)這種場(chǎng)景使用已經(jīng)很多了，因?yàn)樗幸粋€(gè)好處是數(shù)據(jù)閉環(huán)，就是數(shù)據(jù)進(jìn)去TDSQL以后你不用出去，你在這里寫完后，我在這里分析，分析完以后，你直接拿走，這樣用戶的易用性高，但是這個(gè)方案會(huì)這樣設(shè)定為小型的AP系統(tǒng)，像這種AP系統(tǒng)場(chǎng)景有很多的，比如你要給老板做一個(gè)報(bào)表，日?qǐng)?bào)啊，運(yùn)營(yíng)分析系統(tǒng)啊，像這種在關(guān)系數(shù)據(jù)TP里面加上AP的能力這是可以的，那你說我想把它構(gòu)建成一個(gè)超級(jí)搜索引擎，那就不是來干這個(gè)的。

Q12：proxy 會(huì)不會(huì)有單點(diǎn)問題？

A12：不是一個(gè)，其實(shí)可以是有很多個(gè)，proxy其實(shí)是最不容易成為單點(diǎn)了，舉個(gè)例子，比如像我們的TDSQL默認(rèn)是三個(gè)proxy，騰訊云Redis默認(rèn)是五個(gè)proxy，實(shí)際上你會(huì)發(fā)現(xiàn)proxy才更好加節(jié)點(diǎn)，proxy沒有狀態(tài)，掛了一臺(tái)， 我直接找另一把它啟動(dòng)起來就行了，所以proxy不太會(huì)容易成為單點(diǎn)的。

Q13：TDSQL在一主一備模式下通過網(wǎng)關(guān)訪問數(shù)據(jù)庫，進(jìn)行查詢壓測(cè)時(shí)主節(jié)點(diǎn)的cpu使用率很高 備節(jié)點(diǎn)很低，可能是什么原因?qū)е碌哪兀?/strong>

A13：如果你只有一主一備，你要確認(rèn)一下你的分庫規(guī)則，你可能把所有的請(qǐng)求都發(fā)給主庫了，但TDSQL是有監(jiān)控的，你可以看哪個(gè)主節(jié)點(diǎn)和備節(jié)點(diǎn)上面分別查詢的請(qǐng)求，舉個(gè)例子，如果查詢?nèi)谥鞴?jié)點(diǎn)，備節(jié)點(diǎn)沒有，那你可能要配置下你的路由規(guī)則。

Q14：MySQL雙主模型時(shí)，數(shù)據(jù)不一致怎么解決？

A14：我每次說到這個(gè)就要特別講一下，我們這個(gè)圖里面，說的雙主其實(shí)是，你在任何一個(gè)時(shí)刻一邊都是Readonly的，狀態(tài)1的時(shí)候B節(jié)點(diǎn)是Readonly然后狀態(tài)2的時(shí)候A是Readonly，這種就是比較常見的做法，但是有沒有這種多節(jié)點(diǎn)寫入的方案呢？有幾個(gè)，比如說像這種方案也可以多寫，也就是說客戶端既可以往A寫也可以往B寫，這種如果你用傳統(tǒng)的，比如說現(xiàn)在的MySQL的能力，那就要由業(yè)務(wù)方來保證我寫入的數(shù)據(jù)量?jī)蛇叢粵_突，左邊都寫一個(gè)城市數(shù)據(jù)，右邊都寫一個(gè)城市的數(shù)據(jù)，然后兩邊去同步，這樣不沖突，這是一種。那當(dāng)然有MRG還有比如Innodb cluster，它自己會(huì)做事務(wù)之間的沖突檢測(cè)，據(jù)我了解這個(gè)在國內(nèi)用的并不多，或者說不會(huì)把它當(dāng)為常態(tài)互相寫，畢竟你兩邊寫，即使你能做到兩邊不沖突，但是成本會(huì)很高。每次要寫一個(gè)事務(wù)的時(shí)候，都要去問下另外一個(gè)節(jié)點(diǎn)能不能寫，它告訴我能寫才寫，不能寫我就放棄，那這樣的話這個(gè)性能就會(huì)降下來，所以真正多寫的結(jié)構(gòu)，據(jù)我了解，有的公司是用在做切換的時(shí)候，當(dāng)我從A切換到B的時(shí)候，比如看圖中架構(gòu)，如果我從A切換到B的時(shí)候有一段時(shí)間內(nèi)是不可寫的，我要把A停寫，然后B同步完后，把請(qǐng)求連到B這邊，那如果你可以支持多寫，中間成本會(huì)高些，但是畢竟能寫，這樣的話我就可以同時(shí)往A和B同時(shí)寫，在很短的時(shí)間內(nèi)把A的更新去掉，這樣的業(yè)務(wù)的好處就是，業(yè)務(wù)發(fā)現(xiàn)完全不停機(jī)，不停寫，但是也只是用在這么一個(gè)短暫的時(shí)候，它本身天然就與物理規(guī)律有點(diǎn)沖突。

Q15：現(xiàn)在推不推薦上MYSQL8呢？

A15：推薦，已經(jīng)一年多了，我們自己在騰訊云測(cè)試環(huán)境上測(cè)試8.0的性能還是比5.7好不少，所以今年上半年我們應(yīng)該會(huì)推出MySQL8.0的版本。

Q16：原來業(yè)務(wù)用Oracle，單機(jī)能力很強(qiáng)，現(xiàn)在可以用TDSQL或TBase來替換嗎？

A16：我覺得ok，把oracle換成MySQL體系，這個(gè)事情呢已經(jīng)經(jīng)過證明了，能這么做。

Q17：主從復(fù)制是異步的，怎么保證讀取數(shù)據(jù)的一致性？

A17：這是個(gè)大問題，因?yàn)榻裉煳覀兇_實(shí)沒有時(shí)間提到這個(gè)，《MySQL實(shí)戰(zhàn)45講》里面有一篇專門講這個(gè)的，有一些方法，比如說，故意慢一點(diǎn)去讀，或者說查詢的時(shí)候有些請(qǐng)求有一定敏感請(qǐng)求放主庫等有各種方法，還有一些可以用GTID來解決。

Q18：怎么入門MySQL源碼？

A18：如果你真的想入MySQL源碼的話，你可以這樣，首先你得有一套MySQL源碼下載下來，然后你可以開debug日志，執(zhí)行一個(gè)簡(jiǎn)單語句，debug日志會(huì)列出所有調(diào)用的函數(shù)，然后你就照著函數(shù)去數(shù)據(jù)庫源碼里面找下看看在哪里，可以給自己一個(gè)問題。舉個(gè)例子，你執(zhí)行一個(gè)select1，當(dāng)然返回的就是1對(duì)不對(duì)，你先給自己一個(gè)需求，比如我現(xiàn)在想給它寫一個(gè)bug，這時(shí)候返回2，那我該怎么做，可以試試。當(dāng)然如果你開發(fā)功底不錯(cuò)可以考慮我們團(tuán)隊(duì)，我們團(tuán)隊(duì)天然干這個(gè)的。

Q19：讀寫分離的話，主從同步延遲很大，讀的是延后的數(shù)據(jù)，不是有損傷嗎，一些調(diào)優(yōu)的參數(shù)都試過了，這時(shí)是不是該分庫分表了？

A19：如果你的這個(gè)主庫和從庫的配置是一樣的，而主庫有讀寫，從庫上并沒有壓力的時(shí)候還有延遲，那很可能是因?yàn)槟愕牟⑿卸炔粔颍褪悄憧赡軟]有開啟并行復(fù)制，你可以開下并行復(fù)制試下。如果由于對(duì)從庫的查詢壓力過大，導(dǎo)致從庫cpu消耗過大，導(dǎo)致延遲，這種情況可以多加幾個(gè)從庫，分庫分表當(dāng)然也是一個(gè)解法。什么情況下說需要分庫分表呢，就是你主庫更新量太大了，大到MySQL開啟了并行復(fù)制都撐不住的時(shí)候，可能需要考慮，這個(gè)話題比較復(fù)雜，大家可以搜一些文章。

明晚直播預(yù)告

直播互動(dòng)福利：每晚直播間也同樣會(huì)送出多份騰訊公仔，更有騰訊徽章、騰訊云代金券等好禮送上！快快預(yù)約報(bào)名吧！

掃碼關(guān)注后回復(fù)「加群」提前加入沙龍交流群

網(wǎng)站名稱：直播回顧|丁奇剖析數(shù)據(jù)庫性能-創(chuàng)新互聯(lián)
地址分享：http://www.muchs.cn/article36/diejpg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、微信小程序、網(wǎng)站策劃、網(wǎng)站導(dǎo)航、外貿(mào)網(wǎng)站建設(shè)、全網(wǎng)營(yíng)銷推廣

廣告

聲明：本網(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)