一、如何看待MySQL版本升級(jí)

關(guān)于數(shù)據(jù)庫(kù)版本升級(jí)，一直都是熱議話題，對(duì)于升級(jí)的緣由各家也有所不同，有業(yè)務(wù)驅(qū)動(dòng)的，有DBA自發(fā)驅(qū)動(dòng)的，有規(guī)劃導(dǎo)向也有方向指引的……拋開各種原因，當(dāng)升級(jí)這個(gè)決定落下來的時(shí)候，對(duì)于DBA手頭的幾百幾千套數(shù)據(jù)庫(kù)來說，就好比是一場(chǎng)動(dòng)物大遷徙，滿滿的畫面感。

從Oracle發(fā)布的版本生命周期規(guī)劃可以看到，MySQL5.7已經(jīng)走到了生命周期的終點(diǎn)，意味著后續(xù)將不再為 MySQL 5.7 提供官方更新、錯(cuò)誤修復(fù)或安全補(bǔ)丁。

圖片

阿里云和AWS都在官方公布了版本支持計(jì)劃，MySQL 5.7版本已經(jīng)開始了倒計(jì)時(shí)。

圖片

而要想讓這件事情獲得研發(fā)同學(xué)的大力支持，就需要平滑升級(jí)或者最低成本的改動(dòng)。所以對(duì)于這場(chǎng)遷移的基本要求，我在心里默默對(duì)自己提了要求：零故障，平滑升級(jí)。

（一）行業(yè)內(nèi)的MySQL版本數(shù)據(jù)情況

我在2022年底左右調(diào)研了下行業(yè)內(nèi)的一些公司的MySQL數(shù)據(jù)庫(kù)版本情況，列表如下：

圖片

可以看到大部分的公司還是在MySQL 5.7這個(gè)版本，而且從服務(wù)規(guī)模來看，越是規(guī)模大的公司，要想做整體升級(jí)這個(gè)事情的復(fù)雜度就會(huì)高出幾個(gè)數(shù)量級(jí)。

（二）我們做數(shù)據(jù)庫(kù)版本升級(jí)的理由

我們做這件事情是從規(guī)劃導(dǎo)向來切入的，也有一部分DBA自驅(qū)的因素。說是規(guī)劃導(dǎo)向，轉(zhuǎn)義過來就是不打無準(zhǔn)備之仗，MySQL后續(xù)的整體架構(gòu)是構(gòu)建在基礎(chǔ)存儲(chǔ)之上的，如果基礎(chǔ)存儲(chǔ)存在瓶頸，對(duì)于后續(xù)的架構(gòu)演進(jìn)也存在明顯短板，所以我們?cè)?019年底就開始調(diào)研并小范圍在新業(yè)務(wù)中試點(diǎn)MySQL 8.0了。

如下是早期調(diào)研中對(duì)于MySQL 8.0和MySQL 5.7使用sysbench壓測(cè)的一些信息供參考，可以看到MySQL 8.0是有明顯性能提升的。至于MySQL 8.0的版本，我們的考慮是和驗(yàn)證測(cè)試的8.0.19保持一致，在后期支持新版本的無縫升級(jí)。

圖片

從功能上來說，開發(fā)特性更加豐富，SQL優(yōu)化效果和運(yùn)維功能上都有明顯的提升，在兼容性方面會(huì)更加嚴(yán)格（兼容性嚴(yán)格具有兩面性）。

圖片

在經(jīng)過了一個(gè)相對(duì)穩(wěn)定的周期驗(yàn)證之后，無論從穩(wěn)定性、性能和功能方面確實(shí)達(dá)到了預(yù)期的效果，有一些特性確實(shí)解決了當(dāng)時(shí)的一些運(yùn)維問題。

說是DBA自驅(qū)的理由，是因?yàn)槲覀儽P點(diǎn)了一下近些年來的MySQL技術(shù)棧使用情況，發(fā)現(xiàn)實(shí)際的情況比我們預(yù)想的要差一些，比如MySQL 5.5我會(huì)定義為一個(gè)分支技術(shù)棧，以此類推，我們目前存在7個(gè)分支技術(shù)棧。 

圖片

在這些因素的基礎(chǔ)之上，我們以點(diǎn)帶面展開分析，發(fā)現(xiàn)多分支技術(shù)棧散亂只是表象，還有一些潛在問題和瓶頸問題：

1、MySQL版本過舊，架構(gòu)管理不一致，運(yùn)維復(fù)雜度較高

1) MySQL 5.5和5.6為過舊技術(shù)棧，官方已不再維護(hù)

2) 未來3年內(nèi)需要從MySQL 5.7升級(jí)至8.0，演進(jìn)復(fù)雜度高

3) 40%操作系統(tǒng)版本過舊，后續(xù)的數(shù)據(jù)庫(kù)版本升級(jí)存在風(fēng)險(xiǎn)

2、部分技術(shù)棧已閉源，服務(wù)異常時(shí)存在恢復(fù)風(fēng)險(xiǎn)

1) Infobright已轉(zhuǎn)為商業(yè)版維護(hù)

2) TokuDB已于2020年不再維護(hù)

3、數(shù)據(jù)庫(kù)規(guī)范和審核機(jī)制難以支撐現(xiàn)有的業(yè)務(wù)需求

1) SQL審核工具解決了早期的研發(fā)規(guī)范問題，后續(xù)閉源難以持續(xù)

2) 數(shù)據(jù)庫(kù)開發(fā)規(guī)范已4年未更新，部分開發(fā)規(guī)范已難以滿足業(yè)務(wù)需要

4、人員穩(wěn)定性和持續(xù)發(fā)展

1)DBA不可避免地在做一些重復(fù)勞動(dòng)，一些繁瑣的差異化操作勢(shì)必會(huì)削弱工作熱情，也會(huì)發(fā)生一些意料之外的異常

2)個(gè)人運(yùn)維經(jīng)驗(yàn)無法有效的沉淀轉(zhuǎn)化

所以這是一個(gè)綜合的問題，涉及到對(duì)技術(shù)、業(yè)務(wù)和人的管理，而且是環(huán)環(huán)相扣。

當(dāng)然對(duì)于一件事情的基本邏輯越簡(jiǎn)單，實(shí)現(xiàn)起來也更聚焦。所以我們進(jìn)一步提煉了一下目標(biāo)，7->2，即7個(gè)分支技術(shù)棧整合為2個(gè)，在這個(gè)基礎(chǔ)上進(jìn)行生態(tài)技術(shù)棧的補(bǔ)充和完善。

（三）數(shù)據(jù)庫(kù)版本升級(jí)的意義

做這件事情有什么好處呢，也就是所謂的意義，我覺得是：降本增效，提高整體業(yè)務(wù)穩(wěn)定性。主要體現(xiàn)在如下六個(gè)方面：

• 應(yīng)對(duì)未來3年內(nèi)的數(shù)據(jù)庫(kù)基礎(chǔ)服務(wù)風(fēng)險(xiǎn)，對(duì)后續(xù)的數(shù)據(jù)存儲(chǔ)平臺(tái)架構(gòu)迭代奠定基礎(chǔ)（這個(gè)需要由明確的規(guī)劃支撐）
• 通過版本升級(jí)提高整體業(yè)務(wù)性能和穩(wěn)定性
• 實(shí)現(xiàn)支持系統(tǒng)的一致性，提高基礎(chǔ)服務(wù)支撐能力
• 將單點(diǎn)業(yè)務(wù)遷移至MySQL主流技術(shù)棧，預(yù)防故障風(fēng)險(xiǎn)
• 對(duì)開發(fā)規(guī)范和SQL審核機(jī)制進(jìn)行規(guī)范化支持和落地
• 為后續(xù)的環(huán)境標(biāo)準(zhǔn)化建設(shè)提供實(shí)踐經(jīng)驗(yàn)

我從公有云和私有云的視角盤點(diǎn)了下MySQL技術(shù)棧發(fā)展的情況，其實(shí)MySQL 8.0已經(jīng)成為了行業(yè)主流的基線版本，各種數(shù)據(jù)庫(kù)產(chǎn)品層出不窮，如果基線版本已經(jīng)落后了，后續(xù)勢(shì)必會(huì)有整合和返工，所以這也算是一個(gè)技術(shù)的戰(zhàn)略點(diǎn)。在協(xié)議兼容的前提下，還需要進(jìn)一步考慮到國(guó)產(chǎn)化數(shù)據(jù)庫(kù)的影子，當(dāng)然也可以有更多的選擇，重心在于協(xié)議和生態(tài)技術(shù)棧兼容。

畢竟數(shù)據(jù)庫(kù)的升級(jí)是一項(xiàng)大工程，大開大合，研發(fā)同學(xué)再配合支持也需要權(quán)衡，所以MySQL 8.0的大版本基礎(chǔ)之上，在滿足驅(qū)動(dòng)和協(xié)議兼容之后，后續(xù)的小版本和迭代升級(jí)計(jì)劃都是在8.0的體系之內(nèi)完全平滑閃斷完成，也就不需要研發(fā)同學(xué)全程跟進(jìn)了。 

（四）數(shù)據(jù)庫(kù)版本升級(jí)的潛在難點(diǎn)

當(dāng)然任何事情都得多面看，看到好處（意義），也需要看到難點(diǎn)：

• 跨中心多團(tuán)隊(duì)協(xié)作，周期較長(zhǎng)
• 開發(fā)語言技術(shù)棧有7個(gè)，MySQL 8.0的驅(qū)動(dòng)兼容性都需要充分考慮
• 部分升級(jí)改造需要研發(fā)側(cè)支持旁路數(shù)據(jù)雙寫
• 根據(jù)數(shù)據(jù)庫(kù)拓?fù)潢P(guān)聯(lián)主機(jī)業(yè)務(wù)的親和性，避免服務(wù)器故障
• 按照業(yè)務(wù)特點(diǎn)和優(yōu)先級(jí)制定差異化升級(jí)方案
• 基于滾動(dòng)模式的數(shù)據(jù)庫(kù)資源全量替換，避免資源冗余
• 制定平滑的MySQL集群遷移方案，對(duì)業(yè)務(wù)侵入性最低

因?yàn)槲覀兩?jí)的基調(diào)是平滑模式，所以基本是資源平替，快速切換的實(shí)現(xiàn)策略，在這種情況下，每一個(gè)數(shù)據(jù)庫(kù)實(shí)例都需要反復(fù)確認(rèn)，會(huì)有大量的溝通協(xié)調(diào)工作，況且業(yè)務(wù)不能停，因?yàn)閿?shù)據(jù)庫(kù)升級(jí)直接影響到業(yè)務(wù)使用，這件事情的性質(zhì)也就變了。 

二、通過五個(gè)方面保障數(shù)據(jù)庫(kù)升級(jí)的穩(wěn)定性

接下來我會(huì)從如下的幾個(gè)方面來保障整個(gè)升級(jí)過程的穩(wěn)定性。 

（一）梳理和確認(rèn)目標(biāo)和范圍

整個(gè)數(shù)據(jù)庫(kù)版本升級(jí)，不是單單有標(biāo)準(zhǔn)版的主從集群，還需要考慮到中間件集群，因?yàn)镹ewSQL集群上線已經(jīng)完成了兼容性測(cè)試，所以不在本次升級(jí)的考慮范圍之內(nèi)。

通過這項(xiàng)梳理也能夠基本明確其他分支技術(shù)棧該如何做方案設(shè)計(jì)。

圖片

（二）制定升級(jí)策略

1、整體升級(jí)策略

這場(chǎng)數(shù)據(jù)庫(kù)版本升級(jí)的大遷徙，是從7個(gè)分支技術(shù)棧收縮為2個(gè)，所以需要對(duì)不同的分支技術(shù)棧規(guī)劃落地方案，整體上我們是傾向于讓MySQL 8.0承載盡可能完整的業(yè)務(wù)。

圖片

因?yàn)樯弦徊矫鞔_了數(shù)據(jù)庫(kù)版本升級(jí)的范圍是標(biāo)準(zhǔn)版和中間件集群和其他分支技術(shù)棧，則需要制定相應(yīng)的升級(jí)策略。 

2、標(biāo)準(zhǔn)版升級(jí)策略

對(duì)于標(biāo)準(zhǔn)版主從來說，如果是MySQL 5.5,5.6版本，需要先過渡到MySQL 5.7，完成兼容性測(cè)試之后，觀察一段時(shí)間之后，再次升級(jí)到MySQL 8.0；如果是MySQL 5.7版本，則可以直接升級(jí)到MySQL 8.0。

圖片

3、中間件集群升級(jí)策略

對(duì)于中間件集群來說，整體的思路還是做拓?fù)湎鲁粒赐ㄟ^級(jí)聯(lián)的方式，把從庫(kù)提升為主庫(kù)。

圖片

4、其他分支技術(shù)棧升級(jí)策略

對(duì)于其他的分支技術(shù)棧來說，這些技術(shù)棧早期也確實(shí)解決了一些業(yè)務(wù)厄待解決的問題，隨著MySQL 8.0的性能提升和集群技術(shù)的迭代，需要做一些整合。

• TokuDB遷移至TiDB
• Infobright遷移至MySQL 8.0
• 對(duì)于一些歷史遺留業(yè)務(wù)，還需要研發(fā)協(xié)助完成數(shù)據(jù)旁路雙寫

所以整體來上來看，數(shù)據(jù)庫(kù)版本升級(jí)不是單一升級(jí)到8.0，在策略上需要考慮完整。

（三）定制化升級(jí)列表

如果有成百上千個(gè)實(shí)例要落地升級(jí)計(jì)劃，顯然是一件龐大的工程，某個(gè)業(yè)務(wù)有幾十個(gè)實(shí)例，斷斷續(xù)續(xù)地溝通，研發(fā)同學(xué)也受不了，而且整體的進(jìn)度也不好控制，所以我們是從兩個(gè)維度來做梳理和整合的。 

• 先按照數(shù)據(jù)庫(kù)版本把所有業(yè)務(wù)的信息都梳理出來，比如MySQL 5.6,MySQL 5.7的，可以整理成不同的tab頁(yè)，按照業(yè)務(wù)負(fù)責(zé)人進(jìn)行匯總；
• 然后按照不同的業(yè)務(wù)大類或者業(yè)務(wù)負(fù)責(zé)人，把上面這個(gè)數(shù)據(jù)中的信息提取出來，這樣就形成了業(yè)務(wù)視角的數(shù)據(jù)庫(kù)升級(jí)計(jì)劃，基本就可以開始和研發(fā)同學(xué)溝通了；
• 當(dāng)然溝通也不能全靠嘴，還需要一些標(biāo)準(zhǔn)化的文檔，比如我們整理了不同版本升級(jí)需要注意的事項(xiàng)，把整個(gè)過程需要研發(fā)協(xié)助的事情都列清楚，避免重復(fù)的解釋和無效溝通；
• 最后是回退方案，這應(yīng)該是整個(gè)方案里面研發(fā)同學(xué)最關(guān)心的部分了，畢竟先把最壞的結(jié)果考慮到，一旦發(fā)現(xiàn)問題也能及時(shí)處理。

如下是我們計(jì)劃和研發(fā)同學(xué)進(jìn)行的溝通的雙方協(xié)作的流程。

圖片

（四）研發(fā)驅(qū)動(dòng)兼容性/功能測(cè)試

1、數(shù)據(jù)庫(kù)驅(qū)動(dòng)兼容性測(cè)試

數(shù)據(jù)庫(kù)驅(qū)動(dòng)測(cè)試是升級(jí)的一個(gè)關(guān)鍵環(huán)節(jié)，而且涉及到很多開發(fā)語言，所以兼容性測(cè)試是重中之重。

為了避免走彎路，我們先期和一些研發(fā)同學(xué)一起梳理測(cè)試，整理了如下的驅(qū)動(dòng)兼容性列表，這樣后續(xù)的一些研發(fā)同學(xué)接入時(shí)，就可以參考了。

圖片

而對(duì)于C++、.NET、Python、PHP、Go、NodeJS等開發(fā)語言，兼容性變動(dòng)相對(duì)較小，總結(jié)如下：

圖片

除了驅(qū)動(dòng)型兼容測(cè)試，對(duì)于MySQL的不同分支版本，也需要進(jìn)一步測(cè)試SQL兼容性和其他注意事項(xiàng)。

2、MySQL 5.5,5.6升級(jí)到MySQL 8.0的兼容性測(cè)試：

1）針對(duì)group by語法、日期格式字段等有特定要求

如對(duì)于group by聚合操作，select列必須在group by中出現(xiàn)，若不在group by子句中，認(rèn)為不合法。示例：

mysql> select name,age from test group by name,age;
+------+------+
| name | age |
+------+------+
| aa | 18 |
+------+------+
1 row in set (0.00 sec)
mysql> select name,age from test group by name;
ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'test.test.age' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

對(duì)于group by聚合操作，order by 列必須在group by中出現(xiàn)

mysql> select name,age from test group by name,age order by name;
+------+------+
| name | age  |
+------+------+
| aa   |   18 |
+------+------+
1 row in set (0.00 sec)
mysql> select name,age from test group by name,age order by id;
ERROR 1055 (42000): Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'test.test.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
mysql>

• 解決方案1：研發(fā)側(cè)調(diào)整對(duì)應(yīng)的SQL語句
• 解決方案2：調(diào)整MySQL5.7/8.0的sql_mode參數(shù)，保證兼容MySQL5.5的語法

2）MyISAM存儲(chǔ)引擎的表可能存在潛在問題

解決方案：經(jīng)過排查，目前線上bbs的庫(kù)表均為innodb存儲(chǔ)引擎或者memory存儲(chǔ)引擎

3）部分SQL會(huì)出現(xiàn)執(zhí)行計(jì)劃發(fā)生改變，可能需要略微調(diào)整

解決方案：目前暫時(shí)沒有發(fā)現(xiàn)，后續(xù)有類似SQL，可以針對(duì)性處理

4）字符集驗(yàn)證

MySQL5.7默認(rèn)字符集是utf8字符集，如果是gbk等字符集需要調(diào)整并驗(yàn)證

解決方案：DBA側(cè)保證升級(jí)過后，不會(huì)出現(xiàn)亂碼等字符集報(bào)錯(cuò)信息

3、MySQL 5.7升級(jí)到MySQL8.0的補(bǔ)充兼容性測(cè)試：

1）表中需要包含主鍵

在8.0版本中會(huì)強(qiáng)制要求表中包含主鍵

2）timestamp數(shù)據(jù)類型默認(rèn)值

如果表結(jié)構(gòu)中有timestamp類型字段，并且設(shè)置了默認(rèn)值DEFAULT CURRENT_TIMESTAMP，建議將參數(shù)設(shè)置為off:

explicit_defaults_for_timestamp=OFF(8.0默認(rèn)為on)

否則有可能會(huì)出現(xiàn)：Error:1048 - Column ‘createTime‘ cannot be null

3）執(zhí)行計(jì)劃變化

部分SQL會(huì)出現(xiàn)執(zhí)行計(jì)劃發(fā)生改變，可能需要略微調(diào)整

解決方案：跨版本升級(jí)中的SQL異常，可以通過提前交付只讀實(shí)例來進(jìn)行預(yù)先驗(yàn)證，并且抓取原庫(kù)的慢日志在8.0數(shù)據(jù)庫(kù)中進(jìn)行回放驗(yàn)證

4）MySQL8.0 新增關(guān)鍵字（如rank），可能導(dǎo)致查詢、寫入失敗

mysql> select rank from activity_public_log limit 1;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'from activity_public_log limit 1' at line 1

解決方案：改寫成 `rank`或者調(diào)整字段名

mysql> select `rank` from activity_public_log limit 1;

查詢方式：

select TABLE_SCHEMA,TABLE_NAME,COLUMN_NAME  from information_schema.COLUMNS where COLUMN_NAME="rank";

5）對(duì)于load權(quán)限的確認(rèn)

部分業(yè)務(wù)具有導(dǎo)入數(shù)據(jù)的權(quán)限，在默認(rèn)模板中參數(shù)secure_file_priv和local_infile是關(guān)閉的，需要和業(yè)務(wù)側(cè)確認(rèn)是否有該類需求，或者從定時(shí)任務(wù)中識(shí)別

6）存儲(chǔ)過程權(quán)限檢查

部分業(yè)務(wù)中存在存儲(chǔ)過程時(shí)，對(duì)于存儲(chǔ)過程的權(quán)限粒度 invoker和definer差異可能導(dǎo)致遷移后業(yè)務(wù)調(diào)用失敗，需要在遷移中進(jìn)行檢查

（五）制定資源申請(qǐng)和回收流程

有了前面的流程支持，整個(gè)過程基本可以跑起來了，還有一個(gè)風(fēng)險(xiǎn)則是采用資源平替的方案，也就意味著今天數(shù)據(jù)庫(kù)實(shí)例是業(yè)務(wù)A的主庫(kù)，完成升級(jí)之后我們會(huì)讓系統(tǒng)的同事重新格式化后交付給我們，很可能明天就變成業(yè)務(wù)B的從庫(kù)了，所以資源是以資源池的形式在反復(fù)利用，對(duì)于如何申請(qǐng)資源和下線資源就是關(guān)鍵，我們制定的流程是需要至少3次審核才可以下線，而且下線的過程中還需要有一定的觀察期窗口。

為此我們也指定了專人負(fù)責(zé)制度，即最終的下線操作只能由固定的一個(gè)人來操作，他需要對(duì)下線操作做最后的審核，并且負(fù)責(zé)。 

三、版本升級(jí)問題總結(jié)

具體實(shí)施的過程還是相對(duì)順利的，為此我們也儲(chǔ)備了一些標(biāo)準(zhǔn)化能力，比如平臺(tái)化搭建跨版本從庫(kù)的服務(wù)，保證每個(gè)人交付的質(zhì)量是基本一致的。 

所以結(jié)果整體上是預(yù)期中的，當(dāng)然也發(fā)現(xiàn)了一些潛在問題，通過梳理和總結(jié)，也在其他業(yè)務(wù)方向能夠參考借鑒，提高了整體服務(wù)升級(jí)的穩(wěn)定性和專業(yè)性。

圖片

版本升級(jí)的事情做完了，也盤點(diǎn)出了一些新的收獲：

（一）業(yè)務(wù)便于接入：通過大規(guī)模升級(jí)的過程對(duì)于多語言體系的兼容性支持做到了心中有數(shù)；

（二）數(shù)據(jù)庫(kù)子版本平滑升級(jí)：后續(xù)的子版本升級(jí)演變?yōu)樵诰€升級(jí)模式，就不需要研發(fā)做額外的溝通和測(cè)試；

（三）操作系統(tǒng)無感升級(jí)：操作系統(tǒng)升級(jí)可以演變?yōu)槠交?jí)模式，CentOS 7后續(xù)的版本選型和支持都可以做一些調(diào)研測(cè)試；

（四）資源治理：通過升級(jí)也發(fā)現(xiàn)有一些服務(wù)資源使用率不足需要降配，后續(xù)可以開展容量治理。

四、小結(jié)

MySQL版本升級(jí)工作，從2022年上旬開始規(guī)劃到生態(tài)完善實(shí)施了近1年，得到了多個(gè)中心研發(fā)團(tuán)隊(duì)的大力支持和理解。MySQL數(shù)據(jù)庫(kù)也從原本的7個(gè)技術(shù)棧收縮為2個(gè)，挑戰(zhàn)和難度在落地時(shí)才發(fā)現(xiàn)比預(yù)期的要復(fù)雜不少，為了保證業(yè)務(wù)的穩(wěn)定性和研發(fā)工作的侵入度最低，DBA團(tuán)隊(duì)也制定了完整的數(shù)據(jù)升級(jí)流程和業(yè)務(wù)切換方案，并對(duì)業(yè)務(wù)異常的回退進(jìn)行了全流程準(zhǔn)備，整個(gè)過程零故障。

后續(xù)計(jì)劃在SQL云數(shù)據(jù)庫(kù)、SQL高可用體系，SQL分布式架構(gòu)體系和SQL資源標(biāo)準(zhǔn)化四個(gè)方面持續(xù)發(fā)展，并制定相應(yīng)的建設(shè)計(jì)劃。 

（一）SQL資源標(biāo)準(zhǔn)化：MySQL 8.0作為基線版本，為后續(xù)的運(yùn)維管理工作提供統(tǒng)一、標(biāo)準(zhǔn)的基礎(chǔ)服務(wù)支持，并對(duì)外提供一致性系統(tǒng)服務(wù)，后續(xù)提供平滑升級(jí)的平臺(tái)化方案；同時(shí)做一些資源治理，對(duì)一些使用率不足的業(yè)務(wù)可以在線降配。

（二）SQL分布式架構(gòu)體系演進(jìn)：隨著水平擴(kuò)展需求、信創(chuàng)、分布式事務(wù)方案的調(diào)研和業(yè)務(wù)落地演進(jìn)，未來可能會(huì)基于OceanBase等國(guó)產(chǎn)化數(shù)據(jù)庫(kù)進(jìn)行對(duì)比分析，適時(shí)引入；

（三）SQL高可用體系：SQL高可用體系對(duì)于標(biāo)準(zhǔn)版主從集群會(huì)基于MySQL 8.0版本作為基線，對(duì)于拓?fù)浒l(fā)現(xiàn)，數(shù)據(jù)管理模式會(huì)基于新的運(yùn)維命令和使用模式；

（四）SQL云數(shù)據(jù)庫(kù)服務(wù)支持：基于MySQL 8.0的服務(wù)體系會(huì)在功能和性能上面提供更加豐富，高性能的數(shù)據(jù)存儲(chǔ)支持，如對(duì)于JSON的格式解析和查詢等，對(duì)于SQL查詢優(yōu)化的優(yōu)化器支持等。

作者介紹

楊建榮，競(jìng)技世界數(shù)據(jù)庫(kù)專家、dbaplus社群聯(lián)合發(fā)起人，騰訊云TVP，Oracle ACE，《Oracle DBA工作筆記》和《MySQL DBA工作筆記》作者；現(xiàn)就職于競(jìng)技世界，擅長(zhǎng)數(shù)據(jù)管理、數(shù)據(jù)遷移、性能優(yōu)化，目前專注于開源技術(shù)、運(yùn)維自動(dòng)化和性能優(yōu)化，堅(jiān)持寫技術(shù)博客，已堅(jiān)持2400多天。