MySQL內(nèi)核大牛解密騰訊數(shù)據(jù)庫關(guān)鍵技術(shù)點(diǎn)

本文嘉賓：賴錚，騰訊TEG基礎(chǔ)架構(gòu)部數(shù)據(jù)庫團(tuán)隊(duì)專家工程師，負(fù)責(zé)騰訊TXSQL數(shù)據(jù)庫內(nèi)核的研發(fā)，數(shù)據(jù)庫系統(tǒng)開發(fā)老將，專注數(shù)據(jù)庫內(nèi)核開發(fā)十余年，先后就職于達(dá)夢、Teradata、北大方正以及MySQL InnoDB存儲引擎團(tuán)隊(duì)，是達(dá)夢數(shù)據(jù)庫內(nèi)核、方正XML數(shù)據(jù)庫以及InnoDB的GIS支持，加密功能的主要開發(fā)者，并獲得多項(xiàng)數(shù)據(jù)庫領(lǐng)域的專利。

本文是騰訊TEG基礎(chǔ)架構(gòu)部數(shù)據(jù)庫團(tuán)隊(duì)專家工程師賴錚在騰訊云與3306π聯(lián)合舉辦的數(shù)據(jù)庫技術(shù)沙龍上的演講實(shí)錄。

今天分享時(shí)長四十分鐘左右，詳細(xì)解釋騰訊云數(shù)據(jù)庫內(nèi)核TXSQL的新功能和特性。主要包括三個(gè)部分：

第一個(gè)部分是騰訊云CDB介紹，CDB是云數(shù)據(jù)庫服務(wù)Cloud DataBase Service的縮寫。

第二部分主要介紹CDB新版本的新功能和新優(yōu)化。

第三部分主要介紹CDB企業(yè)級特性。

賴錚演講視頻（與本文內(nèi)容一致）

首先我們介紹一下我們騰訊云的CDB。大家應(yīng)該都知道騰訊云是國內(nèi)領(lǐng)先的云服務(wù)供應(yīng)商，像騰訊內(nèi)部的一些業(yè)務(wù)，qq、微信之類的一些內(nèi)部業(yè)務(wù)就是跑在騰訊云上的，當(dāng)然不是全部，其他未上云業(yè)務(wù)后續(xù)也會逐步遷移到騰訊云上。

騰訊云上運(yùn)行的這些數(shù)據(jù)庫服務(wù)統(tǒng)一都叫TencentDB也叫CDB。CDB提供了非常完善的數(shù)據(jù)庫服務(wù)，能夠讓用戶做一些自主可控的管理，同時(shí)針對很多應(yīng)用做了兼容和優(yōu)化。騰訊云數(shù)據(jù)庫服務(wù)也支持多種數(shù)據(jù)庫引擎。比如我們今天要講到的MySQL數(shù)據(jù)庫服務(wù)，還有Redis、MongoDB等其他數(shù)據(jù)引擎?，F(xiàn)在騰訊云數(shù)據(jù)庫的數(shù)據(jù)量非常大，就MySQL數(shù)據(jù)庫服務(wù)來說早已經(jīng)超過P級。

接下來，看看我們的現(xiàn)網(wǎng)客戶，包括拼多多，蘑菇街，WeBank，微信支付，搜狐暢游等都在使用我們的數(shù)據(jù)庫。而騰訊云數(shù)據(jù)庫服務(wù)的核心，也就是剛才介紹的TencentDB或者叫CDB的最主要的核心叫TXSQL也叫TengXunMySQL也叫TencentDB For MySQL。這個(gè)數(shù)據(jù)庫的內(nèi)核是騰訊自己自研的一個(gè)MySQL分支，它是基于官方MySQL版本的，它在我們整個(gè)騰訊云數(shù)據(jù)庫服務(wù)的核心位置。從這個(gè)架構(gòu)圖可以看出，首先上層是訪問集群 Access clusters，然后中間就是TXSQLInstance cluster 數(shù)據(jù)庫實(shí)例集群，下層是存儲集群。

接下來講一下騰訊云數(shù)據(jù)庫內(nèi)核TXSQL演進(jìn)的過程，最早的TXSQL是從MySQL5.1開始，因?yàn)槟菚r(shí)只有有限的資源，所以只做了 Bugfix。而到了之后的TXSQL5.5，除了Bugfix還做了一些 Features needed byOSS。OSS是什么呢？實(shí)際上就是我們騰訊云的管控平臺或者叫做云操作系統(tǒng)，云操作系統(tǒng)支持或者說管理騰訊云上面的數(shù)據(jù)庫。后來接著到了TXSQL5.6 ，我們做了更多的東西，比如說DBA管理需要的東西，商業(yè)化需要的特性，以及針對讀寫方面的優(yōu)化等等

現(xiàn)在在騰訊云上提供的最新版本是5.7版本，5.7除了剛才講的東西，還提供了一些企業(yè)級的特性，比如說加密，審計(jì)，還有線程池?，F(xiàn)在正在研發(fā)的是8.0版本。8.0版本我們的團(tuán)隊(duì)現(xiàn)在已經(jīng)基本完成，應(yīng)該在近期就會發(fā)布。8.0版本中我們會加入更多的新特性，而不光是剛才介紹的這些特性。其實(shí)8.0大家都應(yīng)該知道，就官方本身來講就加入了非常多的特性，比如說數(shù)據(jù)庫字典的優(yōu)化，對redo log的優(yōu)化，優(yōu)化器的重構(gòu)。8.0可以說算是MySQL近期的里程碑式的版本，所以將來的主流的MySQL數(shù)據(jù)庫服務(wù)都會往8.0上遷，我們騰訊的8.0的版本不光是提供官方版本這些特性，還有我們自己的一些特性，我相信大家應(yīng)該會感興趣。因?yàn)槲覅⑴c了8.0版本的規(guī)劃，我想這個(gè)版本應(yīng)該會給大家?guī)眢@喜，敬請期待。

以上我們簡單介紹了一下騰訊云整個(gè)數(shù)據(jù)庫服務(wù)的一些情況， 現(xiàn)在講一下TXSQL最近版本里面提供的新特性。

一、異步刪除大表

在TXSQL之前的版本就已經(jīng)有了這個(gè)功能，新版本是對這個(gè)功能進(jìn)行了一些優(yōu)化。它主要是解決一個(gè)什么問題呢，我相信大家都或多或少碰到過這個(gè)問題，就是在我們drop database或drop table的時(shí)候，當(dāng)這個(gè)表特別大的時(shí)候，因?yàn)樵瓉淼腗ySQL是直接去刪除掉那個(gè)IDB文件的，而當(dāng)這個(gè)IDB文件特別大的時(shí)候就會產(chǎn)生一個(gè)IO尖刺，這個(gè)尖刺有的客戶是無法接受的，因?yàn)榭赡苡行I(yè)務(wù)會很受影響。為了解決這個(gè)問題，我們做了這個(gè)異步刪除大表的功能。它是怎做的呢？做drop table 、 drop database的時(shí)候會把刪除文件的工作通過后臺線程來做，后臺線程每一次會truncate掉128M，然后一直到刪除這個(gè)IBD文件。

在我們最新的版本里對這個(gè)功能的參數(shù)支持了動(dòng)態(tài)設(shè)置，比如說可以配置臨時(shí)文件存放的目錄，還可以動(dòng)態(tài)打開或關(guān)閉這個(gè)功能，set global innodb_async_truncate_work_enabled = ON/OFF，新增drop table用異步刪除，存量用的還是老的邏輯。

二、CATS事務(wù)調(diào)度算法

CATS（Contention-Aware Transaction Scheduling) 熱點(diǎn)感知事務(wù)調(diào)度

我們知道MySQL 原來的事務(wù)調(diào)度是FCFS（First Come First Served）先到先得，就是看誰先來誰先去執(zhí)行，新的事務(wù)調(diào)度算法是一個(gè)怎么的算法呢？它是根據(jù)你當(dāng)前熱點(diǎn)或者叫阻塞的情況來判斷究竟應(yīng)該調(diào)用哪個(gè)事務(wù)。舉一個(gè)簡單的例子：就像有一條公路，大家都往這條公路上走，公路上有摩托車，小汽車，大巴，當(dāng)發(fā)生堵車的時(shí)候，我們應(yīng)該讓哪一種車先走，是不是應(yīng)該先讓大巴先走？因?yàn)榇蟀蛙嚿先硕啵?dāng)大巴車過去的越多，人就過去的越多，這就是這個(gè)算法的基本原理。

如圖所示先執(zhí)行的將會是t1，因?yàn)樗枞氖聞?wù)個(gè)數(shù)是四個(gè)，而t2只有三個(gè)。所以判斷是基于阻塞的事務(wù)個(gè)數(shù)，而不是鎖的個(gè)數(shù)，因?yàn)闀龅绞聞?wù)拿到了很多行鎖，但是這些行鎖沒有被別人請求的情況，所以它雖然拿了行鎖但沒有其他事務(wù)在等它，也就沒必要讓它先執(zhí)行。做MySQL優(yōu)化有時(shí)候還是蠻有意思的，發(fā)現(xiàn)一些很簡單的優(yōu)化點(diǎn)就可以做到很大的性能提升。

我們來看一下官方的公布測試效果：

第一個(gè)圖，隨著并發(fā)數(shù)的增加性能有了近三倍的提升。不過，大家需要注意這個(gè)新的事務(wù)調(diào)度算法并不是萬能的，它只能適用某些場景。是哪些場景呢？就是某一部分?jǐn)?shù)據(jù)特別熱的場景，比如有20張表，每一張都有一千萬行數(shù)據(jù)，相對來講，它只會去做一些修改相對集中于一張表或者兩張表的記錄，這種情況下，這種事務(wù)算法才會比較有效。TXSQL新版本中，我們增加了一個(gè)新的參數(shù)，來讓用戶可以設(shè)置事務(wù)調(diào)度的方法：

innodb_trx_schedule_algorithm={AUTO, FCFS,CATS} 缺省為AUTO

AUTO超過預(yù)定設(shè)置的值它就會調(diào)用這個(gè)事務(wù)調(diào)度算法，現(xiàn)在我們是超過32個(gè)線程在等待的時(shí)候就會使用這個(gè)新的調(diào)度算法

三、無主鍵表復(fù)制的優(yōu)化

不知道大家有沒有碰到這種情況，就是發(fā)現(xiàn)主備份延遲非常嚴(yán)重，后來一查是因?yàn)橛幸粡埍頉]有建立主鍵，而且沒有任何的唯一索引，這種情況就只能怎么辦，加主鍵或者創(chuàng)建唯一索引對不對，這樣的話可以明顯看到主備延遲在減少，這是為什么，這是因?yàn)閷τ跓o主鍵的表，備機(jī)做binlog回放的時(shí)候會進(jìn)行全表掃描，當(dāng)這個(gè)表數(shù)據(jù)量很大的時(shí)候，全表掃描的速度就會很慢，自然主備就會延遲的很嚴(yán)重。針對這樣的情況，我們提出了一個(gè)自己的方案， 如果沒有建立主鍵，會自動(dòng)建立一個(gè)隱藏列，并且在這個(gè)列上建立一個(gè)唯一索引，這樣的話我們就可以在做回放的時(shí)候，使用上這個(gè)唯一索引，來找到需要update的數(shù)據(jù)，從而減少主備延遲的情況。

我們也有兩個(gè)參數(shù)來進(jìn)行控制這個(gè)功能：

1、參數(shù)開關(guān)cdb_hidden_key_col，默認(rèn)為off，無主鍵表添加隱藏列和隱藏索引功能總開關(guān)

2、參數(shù)開關(guān)cdb_show_ipk_info，默認(rèn)為off，是否隱藏系統(tǒng)添加的隱藏列，用戶可見

cdb_hidden_key_col 缺省的情況是關(guān)閉，因?yàn)槲覀冋谧鲆恍┗叶葴y試，暫時(shí)是關(guān)閉的，以后的可能會把它打開，打開后，會對無主鍵表加上一個(gè)隱藏列和索引。

cdb_show_ipk_info這個(gè)參數(shù)是用戶可不可以看到這個(gè)隱藏的列和索引，當(dāng)打開這個(gè)參數(shù)的時(shí)候通過show create table 就可以看到這個(gè)隱藏列，還有它的二級索引。

四、GTID復(fù)制功能擴(kuò)展

這個(gè)擴(kuò)展有兩個(gè)部分：

第一個(gè)部分是gtid模式下復(fù)制支持 create as select，create/droptemporary table。原來的MySQL官方是不支持這樣幾種語句在GTID模式下的復(fù)制的。有一些客戶給我們提了這個(gè)需求，所以我們在TXSQL新版本里面提供了這個(gè)功能。這個(gè)功能也是有相應(yīng)的設(shè)置進(jìn)行打開：

參數(shù)開關(guān)cdb_more_gtid_feature_supported，默認(rèn)為off

當(dāng)gtid_mode=ON、enforce_gtid_consistency=ON 復(fù)制支持如下用法：

create table t2 select * from t;

begin;

create temporary table xx (id int);

insert into xx select *from t2;

insert into t1 select * from xx;

commit;

第二個(gè)部分是允許gtid 5.7 同非gtid 5.7建立主從關(guān)系，非gtid5.7事務(wù)同步到gtid 5.7實(shí)例上生成匿名事務(wù)，同樣有一個(gè)參數(shù)進(jìn)行設(shè)置：

參數(shù)開關(guān)cdb_allow_gtid_rep_non，默認(rèn)為off

注：請?jiān)贒TS遷移過程中使用，任務(wù)完成，請關(guān)閉該參數(shù)

以上就是我們新版本加入的功能。我們來看下后續(xù)版本中我們會加入那些新的功能。

一. 即將加入秒加字段（instant add column）功能

這個(gè)功能我相信大家可能會非常感興趣，因?yàn)槲覀儸F(xiàn)網(wǎng)用戶做的最多的一個(gè)DDL操作除了建表就是加字段。加字段的時(shí)候，我們會碰到一個(gè)什么樣的問題？原來在MySQL8.0版本之前的時(shí)候，加字段是需要做數(shù)據(jù)拷貝的，加一個(gè)字段表結(jié)構(gòu)變了，需要從原來的舊表copy到另一張表上，需要一條一條插入，尤其是當(dāng)表的數(shù)據(jù)量特大的時(shí)候就會非常慢。那怎么解決這個(gè)問題呢，我們騰訊游戲團(tuán)體提供了一個(gè)解決方案，原來數(shù)據(jù)就讓它留在那里，我們只要給新的數(shù)據(jù)做一個(gè)標(biāo)記就好了，所以解決方案就是在新的數(shù)據(jù)上面打標(biāo)記的方案，就可以避免所有的數(shù)據(jù)拷貝。這個(gè)功能已經(jīng)被官方合并到8.0了，我們也把這個(gè)功能放到TXSQL 5.7版本中了，因?yàn)槲覀冇X得這個(gè)功能對5.7的用戶來說用的非常多，在做加列的時(shí)候只需指定一下你的這個(gè)算法是instant就能立馬完成，在幾毫秒的時(shí)間完成加字段的操作，只需要修改數(shù)據(jù)字典的信息，不需要數(shù)據(jù)拷貝。整個(gè)功能我們會在下一個(gè)5.7版本中發(fā)布。

二. 即將加入修復(fù)event定時(shí)任務(wù)不按時(shí)執(zhí)行的問題

接下來，我們再看一個(gè)很有意思的bug fix。這是我們剛剛發(fā)現(xiàn)的官方版本的一個(gè)bug。不知道大家是否現(xiàn)網(wǎng)在使用event這個(gè)功能。我們有一個(gè)客戶就大量的使用了event。每天晚上大概在十二點(diǎn)的時(shí)候會進(jìn)行一個(gè)抽獎(jiǎng)的操作，主要是通過設(shè)置在某個(gè)時(shí)間執(zhí)行MySQL的event來給某些用戶發(fā)放一些金幣。但客戶反饋說我明明設(shè)置了晚上12點(diǎn)10分這個(gè)時(shí)間執(zhí)行這個(gè)event，它為什么有時(shí)候就不做了呢，有時(shí)候會延遲一天，有時(shí)候會延遲兩天，有時(shí)候甚至一直不都執(zhí)行，這是為什么呢？很奇怪，而且由于他們有很多類似這樣的操作都是使用event來做的，所以碰到這種的問題特別頻繁。一開始我們也是一頭霧水，理論上應(yīng)該不會啊，我們看過源碼，很簡單，就是設(shè)置一個(gè)定時(shí)執(zhí)行的東西，到了那個(gè)時(shí)間點(diǎn)就會執(zhí)行。后來經(jīng)過長時(shí)間的追蹤，我們發(fā)現(xiàn)了問題，原因在于MySQL源碼中的小頂堆（Priority Queue）的刪除算法是有問題，我們看下面這個(gè)圖：

初始堆的情況是這個(gè)樣子的。大家應(yīng)該都知道小頂堆，最小的數(shù)在最上面，也就是在根節(jié)點(diǎn)。MySQL的event執(zhí)行順序是怎么樣的一個(gè)算法呢，每一次都去取這個(gè)根節(jié)點(diǎn)的event來執(zhí)行，因?yàn)檫@個(gè)event是離我時(shí)間最近的那個(gè)，然后把它取出來等，等到設(shè)定的那個(gè)時(shí)間去執(zhí)行。取出來一個(gè)，然后再把下面一個(gè)最近時(shí)間的event放到根節(jié)點(diǎn)。那我們看我們在做刪除一個(gè)元素（也就是drop一個(gè)event）的時(shí)候會發(fā)生一些什么樣的情況。比方說要?jiǎng)h除第一個(gè)圖中的7，刪除7這個(gè)動(dòng)作就會對應(yīng)MySQL里的drop event這樣一個(gè)操作。在做刪除7這個(gè)節(jié)點(diǎn)時(shí)，會把最后加進(jìn)去的元素3 放到7的這個(gè)位置上，做一個(gè)替換，就變成圖二的樣子。然后再去做排序，從刪的地方開始向下做排序，保證3這個(gè)節(jié)點(diǎn)一定比它下面的節(jié)點(diǎn)都要小。但我們發(fā)現(xiàn)有一個(gè)問題，比如說刪除的不是7這個(gè)節(jié)點(diǎn)，刪除的是10這個(gè)節(jié)點(diǎn)，會發(fā)生一種什么情況呢？把3替換到10的位置，就會成為圖三的這種情況，按照它原來的算法，它去調(diào)整它的子節(jié)點(diǎn)，但是因?yàn)?是沒有子節(jié)點(diǎn)的，它就不調(diào)整了，然后堆就會變成圖三的情況了。大家是不是可以看到，它已經(jīng)違反了小頂堆的原則，就是父節(jié)點(diǎn)永遠(yuǎn)比子節(jié)點(diǎn)小，因?yàn)閳D三中的3是子節(jié)點(diǎn)7是父節(jié)點(diǎn)，7比這個(gè)3要大所以它就錯(cuò)了。在后續(xù)排序的過程中就會出現(xiàn)問題，取下一個(gè)節(jié)點(diǎn)的時(shí)候，就會先取7這個(gè)節(jié)點(diǎn)而不會取這個(gè)3節(jié)點(diǎn)。這就造成到了執(zhí)行的時(shí)間點(diǎn)不去執(zhí)行，反而會去執(zhí)行另外一個(gè)節(jié)點(diǎn)。非常隱蔽的一個(gè)問題，這個(gè)問題我們花了很長時(shí)間來跟蹤，最終才解決了它。

接下來我們講一些TXSQL內(nèi)核的企業(yè)級特性。

一、TXSQL線程池

大家可能都用過線程池，如果你并發(fā)數(shù)很多的時(shí)候應(yīng)該要用到線程池，不然的話隨著并發(fā)數(shù)的增加數(shù)據(jù)庫的性能會急速下降。TXSQL也提供線程池的支持，而且TXSQL線程池對線程池做了優(yōu)化，我們避免了有請求被餓死的情況。讓低優(yōu)先級的用戶在等了很長時(shí)間后，到達(dá)一個(gè)預(yù)定的值的時(shí)候，我們會提升它的優(yōu)先級，讓它先執(zhí)行。

二、TXSQL審計(jì)

審計(jì)功能一般情況下大家不會用到，但是當(dāng)發(fā)現(xiàn)問題的時(shí)候你就會發(fā)現(xiàn)有這樣的一個(gè)功能該有多好。當(dāng)你發(fā)現(xiàn)我不知道誰把表刪掉了或者drop databases的時(shí)候，有審計(jì)就可以追蹤到是誰在什么時(shí)候做了一個(gè)這樣的操作。TXSQL的審計(jì)大概的架構(gòu)圖如圖：

可能大家會擔(dān)心打開審計(jì)對性能有影響，實(shí)際上它對性能的影響非常小，為什么呢？因?yàn)槲覀兪前阉旁诤笈_，就是有一個(gè)Flush thread的后臺線程在不停地去刷Auditfile 這樣一個(gè)文件，把當(dāng)前的操作記錄到一個(gè)文件中然后再通過Audit Agent存到一個(gè)時(shí)序數(shù)據(jù)庫CTSDB里，所以對整個(gè)數(shù)據(jù)庫原有的服務(wù)影響非常非常小，就我們測試，打開審計(jì)和不打開審計(jì)只有5%以內(nèi)的性能損失。

三、TXSQL數(shù)據(jù)加密

現(xiàn)在，大家越來越注重自己的數(shù)據(jù)安全了，不管客戶數(shù)據(jù)還是其他數(shù)據(jù)都不希望被別人拿到。我們的數(shù)據(jù)加密功能會針對所有的落盤數(shù)據(jù)，你的ibd文件，只要落盤我們都進(jìn)行了加密。這個(gè)加密是基于官方的TDE（透明數(shù)據(jù)加密）功能做的。騰訊云的加密基于官方的TDE，集成了騰訊的秘鑰管理插件KMS。加密的秘鑰是通過KMS Plugin插件來獲得的，所以不用擔(dān)心秘鑰被其他人獲取。

推薦閱讀

騰訊對分布式數(shù)據(jù)庫技術(shù)的深度思考與實(shí)踐

3個(gè)DBA和1個(gè)不可能完成的任務(wù)