一、前言

二、TiDB 架構

三、TiDB v7 版本新特性

四、TiDB升級之旅

    1. 當前存在的痛點

    2. 升級方案：升級方式

    3. 升級方案：集群調研

    4. 升級方案：升級前準備環境

    5. 升級方案：升級前驗證集群

    6. 升級方案：升級中流量遷移

    7. 升級方案：升級后銷毀集群

五、升級遇到的問題

    1. v7.5.x版本查詢 SQL 傾向全表掃描 

    2. v7.5.x版本聚合查詢執行計劃不準確 

六、升級帶來的收益

七、選擇TiDB的原因

八、總結

一、背景

得物DBA自2020年初開始自建TiDB，5年以來隨著NewSQL數據庫迭代發展、運維體系逐步完善、產品自身能力逐步提升，接入業務涵蓋了多個業務線和關鍵場景。從第一套TIDB v4.0.9 版本開始，到后來v4.0.11、v5.1.1、v5.3.0，在經歷了各種 BUG 踩坑、問題調試后，最終穩定在 TIDB 5.3.3 版本。伴隨著業務高速增長、數據量逐步增多，對 TiDB 的穩定性及性能也帶來更多挑戰和新的問題。為了應對這些問題，DBA團隊決定對 TiDB 進行一次版本升級，收斂版本到7.5.x。本文基于內部的實踐情況，從架構、新特性、升級方案及收益等幾個方向講述 TiDB 的升級之旅。

二、TiDB 架構

TiDB 是分布式關系型數據庫，高度強兼容 MySQL 協議和 MySQL 生態，穩定適配 MySQL 5.7 和MySQL 8.0常用的功能及語法。隨著版本的迭代，TiDB 在彈性擴展、分布式事務、強一致性基礎上進一步針對穩定性、性能、易用性等方面進行優化和增強。與傳統的單機數據庫相比，TiDB具有以下優勢：

• 分布式架構，擁有良好的擴展性，支持對業務透明靈活彈性的擴縮容能力，無需分片鍵設計以及開發運維。
• HTAP 架構支撐，支持在處理高并發事務操作的同時，對實時數據進行復雜分析，天然具備事務與分析物理隔離能力。
• 支持 SQL 完整生態，對外暴露 MySQL 的網絡協議，強兼容 MySQL 的語法/語義，在大多數場景下可以直接替換 MySQL。
• 默認支持自愈高可用，在少數副本失效的情況下，數據庫本身能夠自動進行數據修復和故障轉移，對業務無感。
• 支持 ACID 事務，對于一些有強一致需求的場景友好，滿足 RR 以及 RC 隔離級別，可以在通用開發框架完成業務開發迭代。

圖片

我們使用 SLB 來實現 TiDB 的高效負載均衡，通過調整 SLB 來管理訪問流量的分配以及節點的擴展和縮減。確保在不同流量負載下，TiDB 集群能夠始終保持穩定性能。在 TiDB 集群的部署方面，我們采用了單機單實例的架構設計。TiDB Server 和 PD Server 均選擇了無本地 SSD 的機型，以優化資源配置，并降低開支。TiKV Server則配置在本地 SSD 的機型上，充分利用其高速讀寫能力，提升數據存儲和檢索的性能。這樣的硬件配置不僅兼顧了系統的性能需求，又能降低集群成本。針對不同的業務需求，我們為各個組件量身定制了不同的服務器規格，以確保在多樣化的業務場景下，資源得到最佳的利用，進一步提升系統的運行效率和響應速度。

圖片

三、TiDB v7 版本新特性

新版本帶來了更強大的擴展能力和更快的性能，能夠支持超大規模的工作負載，優化資源利用率，從而提升集群的整體性能。在 SQL 功能方面，它提升了兼容性、靈活性和易用性，從而助力復雜查詢和現代應用程序的高效運行。此外，網絡 IO 也進行了優化，通過多種批處理方法減少網絡交互的次數，并支持更多的下推算子。同時，優化了Region 調度算法，顯著提升了性能和穩定性。

圖片

四、TiDB升級之旅

當前存在的痛點

• 集群版本過低：當前 TiDB 生產環境（現網）最新版本為 v5.3.3，目前官方已停止對 4.x 和 5.x 版本的維護及支持，TiDB 內核最新版本為 v8.5.3，而被用戶廣泛采用且最為穩定的版本是 v7.5.x。
• TiCDC組件存在風險：TiCDC 作為增量數據同步工具，在 v6.5.0 版本以前在運行穩定性方面存在一定問題，經常出現數據同步延遲問題或者 OOM 問題。
• 備份周期時間長：集群每天備份時間大于8小時，在此期間，數據庫備份會導致集群負載上升超過30%，當備份時間趕上業務高峰期，會導致應用RT上升。
• 集群偶發抖動及BUG：在低版本集群中，偶爾會出現基于唯一鍵查詢的慢查詢現象，同時低版本也存在一些影響可用性的BUG。比如在 TiDB v4.x 的集群中，TiKV 節點運行超過 2 年會導致節點自動重啟。

升級方案：升級方式

TiDB的常見升級方式為原地升級和遷移升級，我們所有的升級方案均采用遷移升級的方式。

原地升級

• 優勢：方式較為簡單，不需要額外的硬件，升級過程中集群仍然可以對外提供服務。
• 劣勢：該升級方案不支持回退、并且升級過程會有長時間的性能抖動。大版本（v4/v5 原地升級到 v7）跨度較大時，需要版本遞增升級，抖動時間翻倍。

遷移升級

• 優勢：業務影響時間較短、可灰度可回滾、不受版本跨度的影響。
• 劣勢：搭建新集群將產生額外的成本支出，同時，原集群還需要部署TiCDC組件用于增量同步。

圖片

升級方案：集群調研

圖片

升級方案：升級前準備環境

圖片

升級方案：升級前驗證集群

圖片

升級方案：升級中流量遷移

圖片

升級方案：升級后銷毀集群

圖片

五、升級遇到的問題

v7.5.x版本查詢SQL傾向全表掃描 

表中記錄數 215億，查詢 SQL存在合理的索引，但是優化器更傾向走全表掃描，重新收集表的統計信息后，執行計劃依然為全表掃描。

走全表掃描執行60秒超時KILL，強制綁定索引僅需0.4秒。

-- 查詢SQL
SELECT
  *
FROM
  fin_xxx_xxx
WHERE
  xxx_head_id = 1111111111111111
  AND xxx_type = 'XX0002'
  AND xxx_user_id = 11111111
  AND xxx_pay_way = 'XXX00000'
  AND is_del IN ('N', 'Y')
LIMIT
  1;


-- 涉及索引
KEY `idx_xxx` (`xxx_head_id`,`xxx_type`,`xxx_status`),

解決方案：

• 方式一：通過 SPM 進行 SQL 綁定。
• 方式二：調整集群參數 tidb_opt_prefer_range_scan，將該變量值設為 ON 后，優化器總是偏好區間掃描而不是全表掃描。

https://asktug.com/t/topic/1047626

v7.5.x版本聚合查詢執行計劃不準確 

集群升級后，在新集群上執行一些聚合查詢或者大范圍統計查詢時無法命中有效索引。而低版本v4.x、5.x集群，會根據統計信息選擇走合適的索引。

v4.0.11集群執行耗時：12秒，新集群執行耗時2分32.78秒

-- 查詢SQL
select 
    statistics_date,count(1) 
from 
    merchant_assessment_xxx 
where 
    create_time between '2025-08-20 00:00:00' and '2025-09-09 00:00:00' 
group by 
    statistics_date order by statistics_date;


-- 涉及索引
KEY `idx_create_time` (`create_time`)

解決方案：

方式一：調整集群參數tidb_opt_objective，該變量設為 determinate后，TiDB 在生成執行計劃時將不再使用實時統計信息，這會讓執行計劃相對穩定。

https://asktug.com/t/topic/1046610

六、升級帶來的收益

版本升級穩定性增強：v7.5.x 版本的 TiDB 提供了更高的穩定性和可靠性，高版本改進了SQL優化器、增強的分布式事務處理能力等，加快了響應速度和處理大量數據的能力。升級后相比之前整體性能提升40%。特別是在處理復雜 SQL 和多索引場景時，優化器的性能得到了極大的增強，減少了全表掃描的發生，從而顯著降低了 TiKV 的 CPU 消耗和 TiDB 的內存使用。

應用平均RT提升44.62%

圖片

原集群RT(平均16.9ms) 

新集群RT(平均9.36ms)

新集群平均RT提升50%，并且穩定性增加，毛刺大幅減少

圖片

老集群RT(平均250ms) 

圖片

新集群RT(平均125ms)

提升TiCDC同步性能：新版本在數據同步方面有了數十倍的提升，有效解決了之前版本中出現的同步延遲問題，提供更高的穩定性和可靠性。當下游需要訂閱數據至數倉或風控平臺時，可以使用TiCDC將數據實時同步至Kafka，提升數據處理的靈活性與響應能力。

縮短備份時間：數據庫備份通常會消耗大量的CPU和IO資源。此前，由于備份任務的結束時間恰逢業務高峰期，經常導致應用響應時間（RT）上升等問題。通過進行版本升級將備份效率提升了超過50%。

圖片

高壓縮存儲引擎：新版本采用了高效的數據壓縮算法，能夠顯著減少存儲占用。同時，通過優化存儲結構，能夠快速讀取和寫入數據，提升整體性能。相同數據在 TiDB 中的存儲占用空間更低，iDB 的3副本數據大小僅為 MySQL（主實例數據大小）的 55%。

圖片

完善的運維體驗：新版本引入更好的監控工具、更智能的故障診斷機制和更簡化的運維流程，提供了改進的 Dashboard 和 Top SQL 功能，使得慢查詢和問題 SQL 的識別更加直觀和便捷，降低 DBA 的工作負擔。

更秀更實用的新功能：TiDB 7.x版本提供了TTL定期自動刪除過期數據，實現行級別的生命周期控制策略。通過為表設置 TTL 屬性，TiDB 可以周期性地自動檢查并清理表中的過期數據。此功能在一些場景可以有效節省存儲空間、提升性能。TTL 常見的使用場景：

• 定期刪除驗證碼、短網址記錄
• 定期刪除不需要的歷史訂單
• 自動刪除計算的中間結果

https://docs.pingcap.com/zh/tidb/v7.5/time-to-live/

七、選擇 TiDB 的原因

我們不是為了使用TiDB而使用，而是去解決一些MySQL無法滿足的場景，關系型數據庫我們還是優先推薦MySQL。能用分庫分表能解決的問題盡量選擇MySQL，畢竟運維成本相對較低、數據庫版本更加穩定、單點查詢速度更快、單機QPS性能更高這些特性是分布式數據庫無法滿足的。

• 非分片查詢場景：上游 MySQL 采用了分庫分表的設計，但部分業務查詢無法利用分片。通過自建 DTS 將 MySQL 數據同步到 TiDB 集群，非分片/聚合查詢則使用 TiDB 處理，能夠在不依賴原始分片結構的情況下，實現高效的數據查詢和分析。
• 分析 SQL 多場景：業務邏輯比較復雜，往往存在并發查詢和分析查詢的需求。通過自建 DTS 將 MySQL 數據同步到 TiDB，復雜查詢在TiDB執行、點查在MySQL執行。TiDB支持水平擴展，其分布式計算和存儲能力使其能夠高效處理大量的并發查詢請求。既保障了MySQL的穩定性，又提升了整體的查詢能力。
• 磁盤使用大場景：在磁盤使用率較高的情況下，可能會出現 CPU 和內存使用率低，但磁盤容量已達到 MySQL 的瓶頸。TiDB 能夠自動進行數據分片和負載均衡，將數據分布在多個節點上， 緩解單一節點的磁盤壓力，避免了傳統 MySQL 中常見的存儲瓶頸問題，從而提高系統的可擴展性和靈活性。
• 數據傾斜場景：在電商業務場景上，每個電商平臺都會有一些銷量很好的頭部賣家，數據量會很大。即使采取了進行分庫分表的策略，仍難以避免大賣家的數據會存儲在同一實例中，這樣會導致熱點查詢和慢 SQL 問題，盡管可以通過添加索引或進一步分庫分表來優化，但效果有限。采用分布式數據庫能夠有效解決這一問題。可以將數據均勻地分散存儲在多個節點上，在查詢時則能夠并發執行，從而將流量分散，避免熱點現象的出現。隨著業務的快速發展和數據量的不斷增長，借助簡單地增加節點，即可實現水平擴展，滿足海量數據及高并發的需求。

八、總結

綜上所述，在本次 TiDB 集群版本升級到 v7.5.x 版本過程中，實現了性能和穩定性提升。通過優化的查詢計劃和更高效的執行引擎，數據讀取和寫入速度顯著提升，大幅度降低了響應延遲，提升了在高并發操作下的可靠性。通過直觀的監控界面和更全面的性能分析工具，能夠更快速地識別和解決潛在問題，降低 DBA 的工作負擔。也為未來的業務擴展和系統穩定性提供了強有力的支持。

后續依然會持續關注 TiDB 在 v8.5.x 版本穩定性、性能以及新產品特性帶來應用開發以及運維人效收益進展。目前 TiDB 內核版本 v8.5.x 已經具備多模數據庫 Data + AI 能力，在JSON函數、ARRAY 索引以及 Vector Index 實現特性。同時已經具備 Resource Control 資源管理能力，適合進行多業務系統數據歸集方案，實現數據庫資源池化多種自定義方案。技術研究方面我們數據庫團隊會持續投入，將產品最好的解決方案引入現網環境。