MySQL 是全球最受歡迎的開(kāi)源數(shù)據(jù)庫(kù)，長(zhǎng)期位于 DB-Engines Ranking 排行榜第二名，在世界范圍內(nèi)擁有數(shù)量龐大的企業(yè)用戶(hù)和開(kāi)發(fā)者。然而，隨著時(shí)間的推移，MySQL 用戶(hù)正面臨新挑戰(zhàn)。Oracle 官宣將在 2023 年 10 月終止 MySQL 5.7 版本的官方技術(shù)支持。據(jù)第三方統(tǒng)計(jì)顯示，目前仍有超過(guò)一半的 MySQL 服務(wù)器運(yùn)行在 5.7 版本。在未來(lái)幾個(gè)月，大量的 MySQL 實(shí)例必須升級(jí)至 8.0 及更高版本，否則將無(wú)法享受 Oracle 提供的技術(shù)支持和重要補(bǔ)丁更新，企業(yè)級(jí)用戶(hù)將面臨重大考驗(yàn)。

TiDB 作為新一代分布式關(guān)系型數(shù)據(jù)庫(kù)，從誕生第一天起擁抱 MySQL 生態(tài)，不斷地兼容 MySQL 5.7 和 MySQL 8.0，為用戶(hù)帶來(lái)更加順暢的遷移和使用體驗(yàn)。本文將介紹 TiDB 7.4 DMR 在 MySQL 8.0 兼容方面的新進(jìn)展，探討 TiDB 如何從根本上解決 MySQL 用戶(hù)面臨的各種挑戰(zhàn)。

○ 升級(jí)影響業(yè)務(wù)連續(xù)性。單實(shí)例或 "主從模式" 運(yùn)行的 MySQL 升級(jí)時(shí)會(huì)造成數(shù)據(jù)庫(kù)服務(wù)的停機(jī)，可能會(huì)對(duì)業(yè)務(wù)運(yùn)營(yíng)造成沖擊。運(yùn)行著大量 MySQL 實(shí)例的企業(yè)級(jí)用戶(hù)，為了應(yīng)對(duì)升級(jí)存在的潛在風(fēng)險(xiǎn)，需要投入大量的人力、物力進(jìn)行測(cè)試和演練。

○ 業(yè)務(wù)規(guī)模擴(kuò)展困難。隨著業(yè)務(wù)規(guī)模的擴(kuò)大和數(shù)據(jù)使用場(chǎng)景的增多，用戶(hù)通常需要在單機(jī)容量限制和分片管理復(fù)雜度之間進(jìn)行權(quán)衡，數(shù)據(jù)庫(kù)擴(kuò)展的難度制約了業(yè)務(wù)規(guī)模和發(fā)展速度。

○ 缺乏極致高可用方案。對(duì)于支撐核心業(yè)務(wù)場(chǎng)景的 MySQL 數(shù)據(jù)庫(kù)來(lái)說(shuō)，如果遇到不可預(yù)測(cè)的宕機(jī)事件，恢復(fù)業(yè)務(wù)變得復(fù)雜，達(dá)成極低的恢復(fù)時(shí)間目標(biāo)（RTO）成為數(shù)據(jù)庫(kù)管理員的挑戰(zhàn)。

○ 實(shí)時(shí)分析能力不足。MySQL 在處理大規(guī)模數(shù)據(jù)實(shí)時(shí)分析時(shí)性能不如在 OLTP（聯(lián)機(jī)事務(wù)處理）場(chǎng)景下出色。這對(duì)于需要進(jìn)行復(fù)雜查詢(xún)和數(shù)據(jù)分析的業(yè)務(wù)是一個(gè)挑戰(zhàn)。

○ 原廠托管服務(wù)受限。雖然云服務(wù)商都會(huì)提供 MySQL 托管服務(wù)，但大多缺乏 Oracle 原廠的官方支持。這意味著在處理深層次的產(chǎn)品問(wèn)題和發(fā)現(xiàn)通用功能需求時(shí)，用戶(hù)無(wú)法獲得來(lái)自數(shù)據(jù)庫(kù)原廠的快速反饋和支持。

因此，遷移到一個(gè)成熟的產(chǎn)品并一舉解決上述難題，無(wú)疑是明智之舉。TiDB 就是 MySQL 全面升級(jí)的理想之選。選擇 TiDB，不僅可以擺脫 MySQL 升級(jí)和擴(kuò)展性的困境，還能夠享受 HTAP、數(shù)據(jù)庫(kù)整合等多方面的額外收益。

TiDB 是由 PingCAP 自主研發(fā)的企業(yè)級(jí)分布式關(guān)系型數(shù)據(jù)庫(kù)，具備水平擴(kuò)縮容、金融級(jí)高可用、實(shí)時(shí) HTAP、云原生、兼容 MySQL 5.7 協(xié)議和生態(tài)等重要特性。TiDB 采用原生分布式架構(gòu)設(shè)計(jì)，具備靈活的彈性伸縮能力，整個(gè)過(guò)程對(duì)業(yè)務(wù)透明，無(wú)需人工干預(yù)。TiDB 的多副本存儲(chǔ)和 Multi-Raft 協(xié)議確保數(shù)據(jù)的強(qiáng)一致性和高可用性，在部分副本發(fā)生故障時(shí)不影響數(shù)據(jù)的可用性。TiDB 通過(guò)滾動(dòng)升級(jí)的方式使得版本更新的影響降至最低，此外可采用增加臨時(shí)節(jié)點(diǎn)的方式，確保 TiDB 在升級(jí)過(guò)程中的性能波動(dòng)和連接閃斷控制在 5% 以?xún)?nèi)，大幅降低升級(jí)對(duì)業(yè)務(wù)的影響。

另外，作為 TiDB 的締造者，PingCAP 基于全球領(lǐng)先云服務(wù)商推出數(shù)據(jù)庫(kù)托管服務(wù) TiDB Cloud，服務(wù)支持涵蓋復(fù)雜問(wèn)題診斷、升級(jí)支持、緊急救援等，充分體現(xiàn)了原廠服務(wù)的優(yōu)勢(shì)。

從項(xiàng)目初期開(kāi)始，TiDB 堅(jiān)持擁抱 MySQL 生態(tài)的產(chǎn)品戰(zhàn)略一直延續(xù)至今。TiDB 兼容 MySQL 的 wire protocol 和語(yǔ)法命令，這意味著 MySQL 客戶(hù)端、MySQL 驅(qū)動(dòng)程序以及部分 MySQL 工具可以直接在 TiDB 上運(yùn)行。對(duì)于絕大多數(shù)在 MySQL 上運(yùn)行的應(yīng)用程序來(lái)說(shuō)，幾乎不需要修改任何代碼。

隨著 MySQL 8.0 的發(fā)布，TiDB 在兼容 MySQL 5.7 的基礎(chǔ)之上，積極擴(kuò)展了對(duì) MySQL 8.0 的兼容。TiDB v7.4.0 版本發(fā)布了對(duì) MySQL 8.0 常用功能的支持，這使得平滑遷移 MySQL 8.0 的應(yīng)用變得輕而易舉。本文列舉了部分功能：

3.1 公共表表達(dá)式（CTE）

作為 MySQL 8.0 引入的重要能力， TiDB 從 5.1 版本開(kāi)始支持 ANSI SQL 99 標(biāo)準(zhǔn)的 CTE 及其遞歸的寫(xiě)法。在編寫(xiě)復(fù)雜查詢(xún)的時(shí)候，利用公共表表達(dá)式 (CTE) 可以構(gòu)建一個(gè)臨時(shí)的中間結(jié)果集，在 SQL 語(yǔ)句中引用多次，提高 SQL 語(yǔ)句編寫(xiě)效率，可讀性，執(zhí)行效率。目前版本中，TiFlash 也同樣支持 CTE。

比如表 authers保存了作家的信息，book_authors 記錄了作家 id 與其所編寫(xiě)書(shū)籍 id 的對(duì)應(yīng)關(guān)系。

mysql>?desc?authors;
+------------+--------------+------+------+---------+-------+
|?Field??????|?Type?????????|?Null?|?Key??|?Default?|?Extra?|
+------------+--------------+------+------+---------+-------+
|?id?????????|?bigint(20)???|?NO???|?PRI??|?NULL????|???????|
|?name???????|?varchar(100)?|?NO???|??????|?NULL????|???????|
|?gender?????|?tinyint(1)???|?YES??|??????|?NULL????|???????|
|?birth_year?|?smallint(6)??|?YES??|??????|?NULL????|???????|
|?death_year?|?smallint(6)??|?YES??|??????|?NULL????|???????|
+------------+--------------+------+------+---------+-------+mysql>?desc?book_authors;
+-----------+------------+------+------+---------+-------+
|?Field?????|?Type???????|?Null?|?Key??|?Default?|?Extra?|
+-----------+------------+------+------+---------+-------+
|?book_id???|?bigint(20)?|?NO???|?PRI??|?NULL????|???????|
|?author_id?|?bigint(20)?|?NO???|?PRI??|?NULL????|???????|
+-----------+------------+------+------+---------+-------+

利用 CTE， 能夠很容易編寫(xiě)出 SQL，列出最年長(zhǎng)的 50 位作家分別編寫(xiě)過(guò)多少書(shū)籍。

mysql>?WITH?top_50_eldest_authors_cte?AS?(->?????SELECT?a.id,?a.name,?(IFNULL(a.death_year,?YEAR(NOW()))?-?a.birth_year)?AS?age->?????FROM?authors?a->?????ORDER?BY?age?DESC->?????LIMIT?50->?)->?SELECT->?????ANY_VALUE(ta.id)?AS?author_id,->?????ANY_VALUE(ta.age)?AS?author_age,->?????ANY_VALUE(ta.name)?AS?author_name,->?????COUNT(*)?AS?books->?FROM?top_50_eldest_authors_cte?ta->?LEFT?JOIN?book_authors?ba?ON?ta.id?=?ba.author_id->?GROUP?BY?ta.id;
+-----------+------------+----------------------+-------+
|?author_id?|?author_age?|?author_name??????????|?books?|
+-----------+------------+----------------------+-------+
|?524470241?|?????????80?|?Alexie?Kirlin????????|?????7?|
|??67511645?|?????????80?|?Bridgette?Tromp??????|?????9?|
...
|??48355494?|?????????80?|?Audrey?Mayert????????|?????7?|
+-----------+------------+----------------------+-------+
50?rows?in?set?(0.23?sec)

• 相關(guān)文檔：https://docs.pingcap.com/zh/tidb/stable/dev-guide-use-common-table-expression

3.2 窗口函數(shù) (window function)

窗口函數(shù)(Window Function)，又被叫做分析函數(shù)， 在對(duì)數(shù)據(jù)進(jìn)行分析、匯總、排序時(shí)會(huì)被用到。窗口函數(shù)能夠以 SQL 形式的寫(xiě)法，來(lái)完成一些復(fù)雜的數(shù)據(jù)整理工作，協(xié)助用戶(hù)發(fā)掘數(shù)據(jù)價(jià)值。例如，數(shù)據(jù)分組排序， 變化趨勢(shì)分析等。

TiDB 目前已經(jīng)完整支持了 MySQL 8.0 提供的窗口函數(shù)，大部分可以下推到 TiFlash 運(yùn)行。

• 相關(guān)文檔：https://docs.pingcap.com/zh/tidb/stable/window-functions

3.3 資源管控

TiDB 在 7.1 版本引入了資源管控，目的是能夠?qū)嘿Y源做合理分配，提升數(shù)據(jù)庫(kù)的穩(wěn)定性，并降低數(shù)據(jù)庫(kù)的使用成本。在多個(gè)應(yīng)用共享一個(gè) TiDB 集群的場(chǎng)景下， 資源隔離可以有效降低應(yīng)用負(fù)載變化對(duì)其他應(yīng)用產(chǎn)生的影響， 資源管理還能解決批量作業(yè)及后臺(tái)任務(wù)對(duì)核心業(yè)務(wù)的影響，以及突發(fā)的 SQL 性能問(wèn)題拖慢整個(gè)集群，是提升大集群穩(wěn)定性的重要能力。

盡管和 MySQL 的實(shí)現(xiàn)方式有差別，TiDB 兼容了 MySQL 指定資源組的語(yǔ)法以及 hint，降低用戶(hù)學(xué)習(xí)成本和遷移成本。另外，TiDB 的資源隔離能夠更有效地對(duì)最重要的 I/O 資源進(jìn)行管控，達(dá)到和 MySQL 同等甚至更好的效果。

下面展示了利用資源管控，將 usr1 使用的所有資源控制在每秒 500 RU 以?xún)?nèi)。

● 預(yù)估集群容量

mysql>?CALIBRATE?RESOURCE

● 創(chuàng)建 app1 資源組，限額是每秒 500 RU

mysql>?CREATE?RESOURCE?GROUP?IF?NOT?EXISTS?app1?RU_PER_SEC?=?500;

● 將用戶(hù)與資源組關(guān)聯(lián)，?usr1?的會(huì)話(huà)自動(dòng)關(guān)聯(lián)到資源組?app1

mysql>?ALTER?USER?usr1?RESOURCE?GROUP?app1;

也可以修改會(huì)話(huà)所屬的資源組

mysql>?SET?RESOURCE?GROUP?`app1`;

或者利用 hint RESOURCE_GROUP() 指定語(yǔ)句所屬的資源組

mysql>?SELECT?/*+?RESOURCE_GROUP(rg1)?*/?*?FROM?t?limit?10;

• 相關(guān)文檔：https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control

3.4 基于角色的權(quán)限管理

TiDB 支持 MySQL 兼容的角色管理?；诮巧氖跈?quán)，可以簡(jiǎn)化權(quán)限管理的工作，并降低了出錯(cuò)的風(fēng)險(xiǎn)。通過(guò)將權(quán)限與角色相關(guān)聯(lián)，可以更好地控制數(shù)據(jù)庫(kù)的訪問(wèn)?？蛻?hù)可以將不同場(chǎng)景的工作進(jìn)行分類(lèi)，創(chuàng)建對(duì)應(yīng)角色，并把角色授予有權(quán)限的數(shù)據(jù)庫(kù)用戶(hù)， 數(shù)據(jù)庫(kù)用戶(hù)在實(shí)際操作時(shí)，根據(jù)場(chǎng)景不同，切換角色，降低誤操作的可能。

這里舉一個(gè)利用角色拆分權(quán)限場(chǎng)景的例子。用戶(hù) dev_adm_usr 作為應(yīng)用管理員，要操作數(shù)據(jù)庫(kù) app_db的數(shù)據(jù)，多數(shù)情況下只是查詢(xún)，偶爾在需要做數(shù)據(jù)修正的時(shí)候才會(huì)做修改。為了防止 dev_adm_usr 的誤操作，我們將兩部分權(quán)限利用角色拆開(kāi)，只有必要的時(shí)候，才給自己賦予讀寫(xiě)的角色。

● 創(chuàng)建角色 app_read_role 和 app_write_role

mysql>?CREATE?ROLE?'app_read_role',?'app_write_role';

● 為角色授予對(duì)應(yīng)的權(quán)限，這里為兩個(gè)角色分別授予?app_db?的讀和寫(xiě)的權(quán)限

mysql>?GRANT?SELECT?ON?app_db.*?TO?'app_read_role'@'%';
mysql>?GRANT?INSERT,?UPDATE,?DELETE?ON?app_db.*?TO?'app_write_role'@'%';

● 將兩個(gè)角色授予用戶(hù) dev_adm_usr

mysql>?GRANT?'app_read_role','app_write_role'?TO?'dev_adm_usr'@'localhost';

● 把?app_read_role?設(shè)為?dev_adm_usr的默認(rèn)角色，這樣用戶(hù)dev_adm_usr?登錄時(shí)默認(rèn)是只讀權(quán)限

mysql>?SET?DEFAULT?ROLE?'app_read_role'?TO?'dev_adm_usr'@'localhost';

● 當(dāng)?dev_adm_usr?需要修改數(shù)據(jù)時(shí)，啟用角色?app_write_role

mysql>?SET?ROLE?app_read_role,app_write_role;

或者啟用所有角色

mysql>?SET?ROLE?ALL;

• 相關(guān)文檔：https://docs.pingcap.com/zh/tidb/stable/role-based-access-control

3.5 增強(qiáng) uft8mb4 字符集

MySQL 8.0 的一個(gè)重要變化是默認(rèn)字符集變成了更通用的 uft8mb4，默認(rèn)排序方式變?yōu)閡tf8mb4_0900_ai_ci。TiDB 在新版本里也加入了utf8mb4_0900_ai_ci的排序方式，以便更輕松地進(jìn)行系統(tǒng)遷移。

為了同時(shí)兼容 MySQL 5.7 和 MySQL 8.0，TiDB 支持了 MySQL 兼容的變量 default_collation_for_utf8mb4。允許用戶(hù)調(diào)整utf8mb4字符集的默認(rèn)排序方式。這個(gè)方式確保了 TiDB 在不同 MySQL 版本之間的平滑過(guò)渡，并能夠適應(yīng)不同應(yīng)用程序的需求。

如果從 MySQL 8.0 遷移，設(shè)為 8.0 默認(rèn)排序 utf8mb4_0900_ai_ci

set?global?default_collation_for_utf8mb4='utf8mb4_0900_ai_ci';

如果從 MySQL 5.7 遷移，設(shè)為 5.7 為 utf8mb4 的默認(rèn)排序 utf8mb4_general_ci

set?global?default_collation_for_utf8mb4='utf8mb4_general_ci';

3.6 JSON 多值索引 (Multi-valued Index)

在支持了 MySQL 5.7 的完整函數(shù)之后，TiDB 在不斷添加對(duì) MySQL 8.0 新發(fā)布功能的支持。最近的版本支持了"多值索引"，允許對(duì) JSON 類(lèi)型中的某個(gè)"數(shù)組"進(jìn)行索引，從而提高了對(duì) JSON 數(shù)據(jù)的檢索效率。與 MySQL 用法完全相同，這意味著在遷移過(guò)程中，無(wú)需修改數(shù)據(jù)建?；驊?yīng)用程序，用戶(hù)可以繼續(xù)按照熟悉的方式操作 JSON 數(shù)據(jù)。

多值索引是對(duì)普通索引結(jié)構(gòu)的延伸。不同于普通索引與表 1:1 的對(duì)應(yīng)關(guān)系， 多值索引與表的對(duì)應(yīng)是 N:1。與 MySQL 相同， 條件中利用 MEMBER OF()，JSON_CONTAINS()，JSON_OVERLAPS() 這幾個(gè)函數(shù)檢索時(shí)，都可能會(huì)選擇到多值索引。

比如，我們假定有一張客戶(hù)信息表，所有詳細(xì)信息以 JSON 格式編入一個(gè) JSON 類(lèi)型的列中， 其中有一個(gè)數(shù)組結(jié)構(gòu)保存客戶(hù)所在的幾個(gè)城市。

當(dāng)我們需要檢索哪些客戶(hù)在北京時(shí)，如果沒(méi)有多值索引，這個(gè)查詢(xún)需要掃描整張表。

SELECT?name?FROM?customer
WHERE?'beijing'?MEMBER?OF?$.city;

這時(shí)我們可以針對(duì) city 這個(gè)數(shù)組創(chuàng)建多值索引，上述查詢(xún)就可以利用索引檢索符合的記錄，大幅提升查詢(xún)性能。

ALTER?TABLE?customers?add?index?idx_city?(name,?(CAST(custinfo->'$.city'?AS?char(20)?ARRAY)));

和普通索引一樣， 當(dāng)優(yōu)化器沒(méi)有選擇到多值索引時(shí)，可以利用優(yōu)化器提示 USE_INDEX() 或 USE_INDEX_MERGE() 強(qiáng)制優(yōu)化器做選擇。

• 相關(guān)文檔：https://docs.pingcap.com/zh/tidb/stable/choose-index#%E4%BD%BF%E7%94%A8%E5%A4%9A%E5%80%BC%E7%B4%A2%E5%BC%95

3.7 修改會(huì)話(huà)變量的 hint ( SET_VAR())

MySQL 8.0 引入了一個(gè)特殊的 hint SET_VAR()。利用這個(gè) hint，可以在語(yǔ)句運(yùn)行期間修改某個(gè)會(huì)話(huà)級(jí)系統(tǒng)變量。TiDB 在 v7.4.0 也支持了這個(gè) hint，提升了系統(tǒng)變量設(shè)置的靈活度， 能夠針對(duì) SQL 語(yǔ)句做“定制”。包括優(yōu)化器相關(guān)的，執(zhí)行時(shí)相關(guān)的多個(gè)變量都支持用 hint 修改。

比如，針對(duì)大表的分析處理，適當(dāng)增加 SQL 的執(zhí)行并行度。

SELECT?/*+?set_var(tidb_executor_concurrency=20)?*/l_orderkey,SUM(l_extendedprice?*?(1?-?l_discount))?AS?revenue,o_orderdate,o_shippriority
FROMcustomer,orders,lineitem
WHEREc_mktsegment?=?'BUILDING'
AND?c_custkey?=?o_custkey
AND?l_orderkey?=?o_orderkey
AND?o_orderdate?<?DATE?'1996-01-01'
AND?l_shipdate?>?DATE?'1996-02-01'
GROUP?BYl_orderkey,o_orderdate,o_shippriority
ORDER?BYrevenue?DESC,o_orderdate
limit?10;

你也可以利用這個(gè) hint 強(qiáng)制剛才的查詢(xún)選擇 TiFlash，而其他查詢(xún)保持不變。

SELECT?/*+?set_var(tidb_isolation_read_engines='tidb,tiflash')?*/l_orderkey,SUM(l_extendedprice?*?(1?-?l_discount))?AS?revenue,o_orderdate,o_shippriority
FROMcustomer,orders,lineitem
WHEREc_mktsegment?=?'BUILDING'
AND?c_custkey?=?o_custkey
AND?l_orderkey?=?o_orderkey
AND?o_orderdate?<?DATE?'1996-01-01'
AND?l_shipdate?>?DATE?'1996-02-01'
GROUP?BYl_orderkey,o_orderdate,o_shippriority
ORDER?BYrevenue?DESC,o_orderdate
limit?10;

• 相關(guān)文檔：https://docs.pingcap.com/zh/tidb/v7.4/optimizer-hints#set_varvar_namevar_value

3.8 CHECK 約束

CHECK 約束 是一致性約束檢查的一種，用來(lái)維護(hù)數(shù)據(jù)的準(zhǔn)確性。CHECK 約束可以用于限制表中某個(gè)字段的值必須滿(mǎn)足指定條件。當(dāng)為表添加 CHECK 約束后，在插入或者更新數(shù)據(jù)時(shí)，TiDB 會(huì)檢查約束條件是否滿(mǎn)足，如果不滿(mǎn)足，則會(huì)報(bào)錯(cuò)。

MySQL 在 8.0 之前只支持 CHECK 約束的語(yǔ)法，在實(shí)際運(yùn)行中并不會(huì)真正去檢查， 在 8.0 之后才全面支持。TiDB 在新版本中也添加了這個(gè)功能， 為了防止客戶(hù)的 DDL 中有殘存的 CHECK 條件，可能會(huì)因?yàn)檫@個(gè)特性產(chǎn)生問(wèn)題，TiDB 默認(rèn)并不會(huì)開(kāi)啟 CHECK 約束的檢查，而是通過(guò)變量 tidb_enable_check_constraint 手工開(kāi)啟， 這充分體現(xiàn)了 TiDB 同時(shí)兼容 MySQL 5.7 和 8.0 的產(chǎn)品策略。

mysql>?set?global?tidb_enable_check_constraint=on;mysql>?CREATE?TABLE?t->?(?a?INT?CHECK(a?>?10)?NOT?ENFORCED,?--?不生效?check->???b?INT,->???c?INT,->???CONSTRAINT?c1?CHECK?(b?>?c)->?);mysql>?insert?into?t?values?(20,20,20);
ERROR?3819?(HY000):?Check?constraint?'c1'?is?violated.

• 相關(guān)文檔：https://docs.pingcap.com/zh/tidb/dev/constraints#check-%E7%BA%A6%E6%9D%9F

為了降低用戶(hù)數(shù)據(jù)遷移的復(fù)雜度，TiDB 推出了一款工具 TiDB Data Migration (DM) 。它能夠協(xié)助用戶(hù)從與 MySQL 協(xié)議兼容的數(shù)據(jù)庫(kù)（MySQL、MariaDB、Aurora MySQL）到 TiDB 的全量數(shù)據(jù)遷移和增量數(shù)據(jù)同步。DM 支持 DDL 同步，分庫(kù)分表合并，并內(nèi)置多種過(guò)濾器以靈活適應(yīng)不同場(chǎng)景，切實(shí)地提升了數(shù)據(jù)遷移的效率。

TiDB 7.4 將是 TiDB 7 系列最后一個(gè) DMR 版本，針對(duì) MySQL 8.0 做出了諸多優(yōu)化。作為 MySQL 的全面升級(jí)，TiDB 的技術(shù)領(lǐng)先性幫助用戶(hù)應(yīng)對(duì)不斷變化的業(yè)務(wù)數(shù)據(jù)挑戰(zhàn)，實(shí)現(xiàn)業(yè)務(wù)的持續(xù)增長(zhǎng)和創(chuàng)新。TiDB 在高度兼容 MySQL 5.7 和 MySQL 8.0 特性的同時(shí)，也將持續(xù)提供技術(shù)支持，確保用戶(hù)能夠平滑地遷移各類(lèi)業(yè)務(wù)應(yīng)用程序，從而減少遷移過(guò)程中的工作量和風(fēng)險(xiǎn)。