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

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

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

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

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

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

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

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

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

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

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

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

3.1 公共表表達式（CTE）

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

比如表 authers保存了作家的信息，book_authors 記錄了作家 id 與其所編寫書籍 id 的對應(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， 能夠很容易編寫出 SQL，列出最年長的 50 位作家分別編寫過多少書籍。

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ù)， 在對數(shù)據(jù)進行分析、匯總、排序時會被用到。窗口函數(shù)能夠以 SQL 形式的寫法，來完成一些復(fù)雜的數(shù)據(jù)整理工作，協(xié)助用戶發(fā)掘數(shù)據(jù)價值。例如，數(shù)據(jù)分組排序， 變化趨勢分析等。

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

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

3.3 資源管控

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

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

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

● 預(yù)估集群容量

mysql>?CALIBRATE?RESOURCE

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

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

● 將用戶與資源組關(guān)聯(lián)，?usr1?的會話自動關(guān)聯(lián)到資源組?app1

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

也可以修改會話所屬的資源組

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

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

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)，可以簡化權(quán)限管理的工作，并降低了出錯的風險。通過將權(quán)限與角色相關(guān)聯(lián)，可以更好地控制數(shù)據(jù)庫的訪問。客戶可以將不同場景的工作進行分類，創(chuàng)建對應(yīng)角色，并把角色授予有權(quán)限的數(shù)據(jù)庫用戶， 數(shù)據(jù)庫用戶在實際操作時，根據(jù)場景不同，切換角色，降低誤操作的可能。

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

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

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

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

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

● 將兩個角色授予用戶 dev_adm_usr

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

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

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

● 當?dev_adm_usr?需要修改數(shù)據(jù)時，啟用角色?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 增強 uft8mb4 字符集

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

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

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

set?global?default_collation_for_utf8mb4='utf8mb4_0900_ai_ci';

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

set?global?default_collation_for_utf8mb4='utf8mb4_general_ci';

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

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

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

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

當我們需要檢索哪些客戶在北京時，如果沒有多值索引，這個查詢需要掃描整張表。

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

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

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

和普通索引一樣， 當優(yōu)化器沒有選擇到多值索引時，可以利用優(yōu)化器提示 USE_INDEX() 或 USE_INDEX_MERGE() 強制優(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 修改會話變量的 hint ( SET_VAR())

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

比如，針對大表的分析處理，適當增加 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;

你也可以利用這個 hint 強制剛才的查詢選擇 TiFlash，而其他查詢保持不變。

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 約束 是一致性約束檢查的一種，用來維護數(shù)據(jù)的準確性。CHECK 約束可以用于限制表中某個字段的值必須滿足指定條件。當為表添加 CHECK 約束后，在插入或者更新數(shù)據(jù)時，TiDB 會檢查約束條件是否滿足，如果不滿足，則會報錯。

MySQL 在 8.0 之前只支持 CHECK 約束的語法，在實際運行中并不會真正去檢查， 在 8.0 之后才全面支持。TiDB 在新版本中也添加了這個功能， 為了防止客戶的 DDL 中有殘存的 CHECK 條件，可能會因為這個特性產(chǎn)生問題，TiDB 默認并不會開啟 CHECK 約束的檢查，而是通過變量 tidb_enable_check_constraint 手工開啟， 這充分體現(xiàn)了 TiDB 同時兼容 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

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

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