MySQL內核大牛解密騰訊數據庫關鍵技術點

本文嘉賓：賴錚，騰訊TEG基礎架構部數據庫團隊專家工程師，負責騰訊TXSQL數據庫內核的研發，數據庫系統開發老將，專注數據庫內核開發十余年，先后就職于達夢、Teradata、北大方正以及MySQL InnoDB存儲引擎團隊，是達夢數據庫內核、方正XML數據庫以及InnoDB的GIS支持，加密功能的主要開發者，并獲得多項數據庫領域的專利。

本文是騰訊TEG基礎架構部數據庫團隊專家工程師賴錚在騰訊云與3306π聯合舉辦的數據庫技術沙龍上的演講實錄。

今天分享時長四十分鐘左右，詳細解釋騰訊云數據庫內核TXSQL的新功能和特性。主要包括三個部分：

第一個部分是騰訊云CDB介紹，CDB是云數據庫服務Cloud DataBase Service的縮寫。

第二部分主要介紹CDB新版本的新功能和新優化。

第三部分主要介紹CDB企業級特性。

賴錚演講視頻（與本文內容一致）

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

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

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

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

現在在騰訊云上提供的最新版本是5.7版本，5.7除了剛才講的東西，還提供了一些企業級的特性，比如說加密，審計，還有線程池。現在正在研發的是8.0版本。8.0版本我們的團隊現在已經基本完成，應該在近期就會發布。8.0版本中我們會加入更多的新特性，而不光是剛才介紹的這些特性。其實8.0大家都應該知道，就官方本身來講就加入了非常多的特性，比如說數據庫字典的優化，對redo log的優化，優化器的重構。8.0可以說算是MySQL近期的里程碑式的版本，所以將來的主流的MySQL數據庫服務都會往8.0上遷，我們騰訊的8.0的版本不光是提供官方版本這些特性，還有我們自己的一些特性，我相信大家應該會感興趣。因為我參與了8.0版本的規劃，我想這個版本應該會給大家帶來驚喜，敬請期待。

以上我們簡單介紹了一下騰訊云整個數據庫服務的一些情況， 現在講一下TXSQL最近版本里面提供的新特性。

一、異步刪除大表

在TXSQL之前的版本就已經有了這個功能，新版本是對這個功能進行了一些優化。它主要是解決一個什么問題呢，我相信大家都或多或少碰到過這個問題，就是在我們drop database或drop table的時候，當這個表特別大的時候，因為原來的MySQL是直接去刪除掉那個IDB文件的，而當這個IDB文件特別大的時候就會產生一個IO尖刺，這個尖刺有的客戶是無法接受的，因為可能有些業務會很受影響。為了解決這個問題，我們做了這個異步刪除大表的功能。它是怎做的呢？做drop table 、 drop database的時候會把刪除文件的工作通過后臺線程來做，后臺線程每一次會truncate掉128M，然后一直到刪除這個IBD文件。

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

二、CATS事務調度算法

CATS（Contention-Aware Transaction Scheduling) 熱點感知事務調度

我們知道MySQL 原來的事務調度是FCFS（First Come First Served）先到先得，就是看誰先來誰先去執行，新的事務調度算法是一個怎么的算法呢？它是根據你當前熱點或者叫阻塞的情況來判斷究竟應該調用哪個事務。舉一個簡單的例子：就像有一條公路，大家都往這條公路上走，公路上有摩托車，小汽車，大巴，當發生堵車的時候，我們應該讓哪一種車先走，是不是應該先讓大巴先走？因為大巴車上人多，當大巴車過去的越多，人就過去的越多，這就是這個算法的基本原理。

如圖所示先執行的將會是t1，因為它阻塞的事務個數是四個，而t2只有三個。所以判斷是基于阻塞的事務個數，而不是鎖的個數，因為會遇到事務拿到了很多行鎖，但是這些行鎖沒有被別人請求的情況，所以它雖然拿了行鎖但沒有其他事務在等它，也就沒必要讓它先執行。做MySQL優化有時候還是蠻有意思的，發現一些很簡單的優化點就可以做到很大的性能提升。

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

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

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

AUTO超過預定設置的值它就會調用這個事務調度算法，現在我們是超過32個線程在等待的時候就會使用這個新的調度算法

三、無主鍵表復制的優化

不知道大家有沒有碰到這種情況，就是發現主備份延遲非常嚴重，后來一查是因為有一張表沒有建立主鍵，而且沒有任何的唯一索引，這種情況就只能怎么辦，加主鍵或者創建唯一索引對不對，這樣的話可以明顯看到主備延遲在減少，這是為什么，這是因為對于無主鍵的表，備機做binlog回放的時候會進行全表掃描，當這個表數據量很大的時候，全表掃描的速度就會很慢，自然主備就會延遲的很嚴重。針對這樣的情況，我們提出了一個自己的方案， 如果沒有建立主鍵，會自動建立一個隱藏列，并且在這個列上建立一個唯一索引，這樣的話我們就可以在做回放的時候，使用上這個唯一索引，來找到需要update的數據，從而減少主備延遲的情況。

我們也有兩個參數來進行控制這個功能：

1、參數開關cdb_hidden_key_col，默認為off，無主鍵表添加隱藏列和隱藏索引功能總開關

2、參數開關cdb_show_ipk_info，默認為off，是否隱藏系統添加的隱藏列，用戶可見

cdb_hidden_key_col 缺省的情況是關閉，因為我們正在做一些灰度測試，暫時是關閉的，以后的可能會把它打開，打開后，會對無主鍵表加上一個隱藏列和索引。

cdb_show_ipk_info這個參數是用戶可不可以看到這個隱藏的列和索引，當打開這個參數的時候通過show create table 就可以看到這個隱藏列，還有它的二級索引。

四、GTID復制功能擴展

這個擴展有兩個部分：

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

參數開關cdb_more_gtid_feature_supported，默認為off

當gtid_mode=ON、enforce_gtid_consistency=ON 復制支持如下用法：

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;

第二個部分是允許gtid 5.7 同非gtid 5.7建立主從關系，非gtid5.7事務同步到gtid 5.7實例上生成匿名事務，同樣有一個參數進行設置：

參數開關cdb_allow_gtid_rep_non，默認為off

注：請在DTS遷移過程中使用，任務完成，請關閉該參數

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

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

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

二. 即將加入修復event定時任務不按時執行的問題

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

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

接下來我們講一些TXSQL內核的企業級特性。

一、TXSQL線程池

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

二、TXSQL審計

審計功能一般情況下大家不會用到，但是當發現問題的時候你就會發現有這樣的一個功能該有多好。當你發現我不知道誰把表刪掉了或者drop databases的時候，有審計就可以追蹤到是誰在什么時候做了一個這樣的操作。TXSQL的審計大概的架構圖如圖：

可能大家會擔心打開審計對性能有影響，實際上它對性能的影響非常小，為什么呢？因為我們是把它放在后臺，就是有一個Flush thread的后臺線程在不停地去刷Auditfile 這樣一個文件，把當前的操作記錄到一個文件中然后再通過Audit Agent存到一個時序數據庫CTSDB里，所以對整個數據庫原有的服務影響非常非常小，就我們測試，打開審計和不打開審計只有5%以內的性能損失。

三、TXSQL數據加密

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

推薦閱讀

騰訊對分布式數據庫技術的深度思考與實踐

3個DBA和1個不可能完成的任務