“當用戶使用軟件時，會需要面對的兩個鴻溝：一個是執行的鴻溝，在這里，用戶要弄清楚如何操作，與軟件「對話」；另一個是評估的鴻溝，用戶要弄清楚操作的結果。” PingCAP 聯合創始人兼 CTO 黃東旭在《做出讓人愛不釋手的基礎軟件》中提到，“ 我們作為設計師的使命就是幫助用戶消除可觀測性和可交互性這兩個鴻溝。”

2021 年 11 月 30 日，TiDB 5.3.0 版本正式上線，該版本推出持續性能分析 （Continuous Profiling) 功能（目前為實驗特性），跨越可觀測性的鴻溝，為用戶帶來數據庫源碼水平的性能洞察，徹底解答每一個數據庫問題。

在提升數據可觀測性的同時，TiDB 5.3.0 實現了 HTAP 性能和穩定性的大幅提升，數據遷移效率、高可用性和易用性也實現了大幅提升，為所有用戶帶來重磅福利。

5.3.0 功能亮點與用戶價值

• 支持持續性能分析 (Continuous Profiling) ，引領數據庫的可觀測性潮流
• 深度優化分布式時間戳獲取技術，提升系統的整體性能
• 持續優化存儲和計算引擎，提供更敏捷更可靠的 HTAP 服務
• 進一步降低上游系統同步數據至 TiDB 的延遲，助力高峰期業務增長
• 新增并行導入功能，提升全量數據遷移效率
• 引入臨時表，一條 SQL 語句簡化業務邏輯并提升性能

支持持續性能分析，引領數據庫的可觀測性潮流

在企業遭遇的 IT 故障中，約有 30% 與數據庫相關。當這些故障涉及到應用系統、網絡環境、硬件設備時，恢復時間可能達到數小時，對業務連續性造成破壞，影響用戶體驗甚至營收。在復雜分布式系統場景下，如何提高數據庫的可觀測性，幫助運維人員快速診斷問題，優化故障處理流程一直是困擾著企業的一大難題。在 TiDB 5.3.0 版本中，PingCAP 率先在數據庫領域推出了持續性能分析 (Continuous Profiling) 特性（目前為實驗特性），為企業提供了數據庫源碼水平的性能洞察。

持續性能分析以低于 0.5% 的性能損耗實現了對數據庫內部運行狀態持續打快照（類似 CT 掃描），以火焰圖的形式從系統調用層面解讀資源開銷。讓原本黑盒的數據庫變成白盒。在 TiDB Dashboard 上一鍵開啟持續性能分析后，運維人員可以方便快速定位性能問題的根因，無論過去現在皆可回溯。

• 當數據庫意外宕機時，可降低至少 50% 診斷時間

在互聯網行業的一個案例中，當客戶集群出現報警業務受影響時，因缺少數據庫連續性能分析結果，運維人員難以發現故障根因，耗費 3 小時才定位問題恢復集群。如果使用 TiDB 的持續性能分析功能，運維人員可比對日常和故障的分析結果，僅需 20 分鐘就可恢復業務，極大減少損失。

• 在日常運行中，可提供集群巡檢和性能分析服務，保障集群持續穩定運行
• 持續性能分析是 TiDB 集群巡檢服務的關鍵，為商業客戶提供了集群巡檢和巡檢結果數據上報。客戶可以自行發現和定位潛在風險，執行優化建議，保證每個集群持續穩定運行。
• 在數據庫選型時，提供更高效的業務匹配
• 在進行數據庫選型時，企業往往需要在短時間內完成功能驗證、性能驗證的流程。持續性能分析功能能夠協助企業更直觀地發現性能瓶頸，快速進行多輪優化，確保數據庫與企業的業務特征適配，提高數據庫的選型效率。

注：性能分析結果存儲在監控節點上，不會對處理業務流量的節點產生影響。

深度優化分布式時間戳獲取技術，為海量業務數據處理提供堅強后盾

當互聯網行業的核心業務系統具有龐大的用戶數量和業務數據時，在高并發訪問的場景下，可能會出現數據庫時間戳獲取延遲增大而導致業務響應變慢、超時頻發、用戶體驗急劇下降的情況。海量的業務數據要求數據庫擁有良好的擴展性。TiDB 本身擁有能夠水平擴展的優勢，但是不斷增長的業務數據量使時間戳獲取能力逐漸成為阻礙集群擴展的瓶頸，最終限制集群整體的擴展。

為進一步提升時間戳獲取能力，在 TiDB 5.3.0 版本中，TiDB 在保持原有的全局時間戳管理方式的基礎上，新增兩個時間戳處理調優參數，在 PD 負載達到瓶頸的情況下，可以有效減輕負載，降低了時間戳獲取延遲，大大提升了系統的整體性能：

• 支持參數設置 PD follower proxy 開關，開啟后允許 follower 批量轉發時間戳處理請求。
• 支持設置 PD client 批量處理時間戳的最大等待時間參數，提高時間戳請求的處理帶寬。

通過本次優化，TiDB 能夠更好地支撐百 TB 或百萬 QPS 大規模集群的擴展。經過 Sysbench 512 線程的測試驗證，時間戳處理流程優化后，TiDB 集群整體 QPS 吞吐提升了 100% 以上。

具體測試環境如下：

本次優化適用于以下場景：

• 擁有百 TB 或 百萬 QPS 以上超大規模集群，需要實現大規模集群的擴展。
• 擁有中等規模集群，但隨著業務的急速增長，數據的成倍增加，需要實現集群的無限擴展。

持續優化存儲和計算引擎，提供更敏捷更可靠的 HTAP 服務

在大型物流和金融服務類企業中，在線交易和實時業務監控等應用場景對數據有較高的一致性和時效性要求，尤其是當讀寫混合負載大時，會對數據庫管理系統的性能和穩定性形成較大挑戰。在年度流量峰值時段，數據平臺的寫入/更新和分析任務往往會激增數倍。例如，某合作伙伴（物流龍頭）在雙十一期間，每天處理超 2500 億條更新和插入記錄，同時還要兼顧海量歷史數據（50 億～100 億）的分析任務。

TiDB HTAP 致力于為企業的規模化在線交易和實時分析應用提供一棧式數據服務平臺，提升關鍵業務的時效性，降低數據技術棧的復雜性。在已有產品基礎上，TiDB 5.3.0 進一步優化了 HTAP 的性能和穩定性，大幅改善了高混合負載場景下并發查詢能力和查詢任務的執行速度。主要的改進包括：

• 性能大幅提升（50%～100%），CPU /內存資源使用率進一步優化，查詢失敗減少：TiDB 5.3.0 優化了列式存儲引擎，調整了存儲引擎底層文件結構和 IO 模型，優化了訪問節點副本和文件區塊的計劃，緩和了寫放大問題以及改進了普遍的代碼效率。總體上高負載時因資源不足造成的失敗狀況大大緩解。
• 遠程數據讀取提速，任務成功率提高，告警可讀性增強：優化了 MPP 計算引擎，支持更多的字符串/時間和其他函數/算子下推至 MPP 引擎，并改善了存儲層寫入/更新事務量較大時數據等待造成內部進程超時的問題，同時還優化了查詢請求的告警信息，便于追蹤和定位問題。
• 輕松擴展節點：在 TiDB 5.3.0 中，TiDB HTAP 架構可隨業務增長輕松擴展到 200 節點甚至更大的集群規模，并且確保 OLTP 與 OLAP 之間原則上不產生資源沖突和相互性能影響。
• 增強運維能力：完善了數據校驗，解決了節點重啟時內部處理可能出現的問題；同時進一步提升了 SQL 告警信息和增強了日志收集、檢索功能。

低延遲同步至 TiDB，助力企業業務持續增長

伴隨著業務持續增長，企業訂單系統的數據庫壓力也不斷增加。核心交易庫寫流量巨大，造成訂單提交時間變長，影響網站用戶體驗。面對這一典型的業務場景，為了幫助提升企業縮短訂單提交時間，TiDB 支持作為下游只讀從庫提供業務查詢服務，為核心交易系統減壓。

TiDB Data Migration (DM) 作為一款實時的數據同步工具，支持將數據從與 MySQL 協議兼容的數據庫同步到 TiDB，實現業務分流，減輕高峰期前端訂單寫入時的壓力。而交易場景高度的即時性，要求業務查詢延遲極低、數據實時性極高，這給 DM 的同步性能帶來了極大挑戰。

為了保證低延遲，數據遷移工具 DM 在 v5.3.0 實現了兩項優化：

• 合并單行數據的多次變更，減少同步到下游的 SQL 數量，提高遷移效率，降低數據延遲，為網站用戶更快地提供業務查詢服務；
• 批量的點查更新合并為單一的語句操作，減少遠程過程調用請求的數量，同樣數量的 binlog 可以更快地同步完成，進而降低延遲，為網站用戶更準確地提供業務查詢服務。

極低的同步延遲保障了下游 TiDB 數據查詢實時性，企業在保持現有架構的情況下，無需進行大規模改造，就能快速引入 TiDB 以增強實時查詢分析能力，更好更快萃取數據價值。

經場景實測，在 300K QPS 數據同步流量下，99.9% 時間內 DM 同步延遲降低至 1 秒以內，尤其適用于高負載業務壓力下 TiDB 作為只讀從庫的場景。

新增并行導入功能，提升全量數據遷移效率

目前 MySQL 分庫分表架構日益普遍，很多企業的數據量已經達到百 TB 級別。隨著企業數據量的增長，從集中式數據庫遷移到以 TiDB 為代表的分布式數據庫已經成為必然，然而存量系統里面的 100 TB 數據沒有方便高效的工具進行遷移。

為解決此問題，TiDB 5.3.0 發布了 TiDB Lightning 并行導入功能，提供了高效的 TiDB 集群初始化能力。用戶可以同時啟動多個 TiDB Lightning 實例，并行地將單表或者多表數據遷移到 TiDB，速度可以橫向擴展，極大地提高了數據遷移效率。

并行導入示意圖如下。用戶可以使用多個 TiDB Lightning 實例導入 MySQL 的分表到下游的 TiDB 集群。

并行導入功能支持多種數據源，包括：CSV/SQL 格式的文本數據、MySQL 分表導出數據 。支持的最大單表規模在 20 TB ～ 30 TB 之間，導入單表數據建議使用 1 個 ～ 8 個 TiDB Lightning 實例，每個實例最佳規模保持在 2 TB～ 5 TB 。對于多表總規模和使用 Lightning 的個數沒有上限要求。

經測試，使用 10 臺 TiDB Lightning，20 TB 規模的 MySQL 數據可以在 8 小時內導入到 TiDB，單臺 TiDB Lightning 可以支持 250 GB/h 的導入速度，整體效率提升了 8 倍。

引入臨時表，一條 SQL 語句簡化業務邏輯并提升性能

業務臨時中間數據存儲不易

在數據量大的場景下，用戶業務常常需要處理龐大的中間數據。如果業務需要反復使用數據中的一部分子集，用戶通常會臨時保存這部分數據，用完后釋放。因此，DBA 不得不頻繁地建表和刪表，可能還需要自行設計數據存儲結構，把中間數據存儲至業務模塊中。這不僅增加了業務復雜度，也造成了龐大的內存開銷，而且如果管理不善，還存在內存泄漏導致系統崩潰的風險。

TiDB 臨時表幫助用戶簡化業務邏輯并提升性能

為幫助用戶解決以上痛點，TiDB 在 5.3.0 版本中引入了臨時表功能。該功能針對業務中間計算結果的臨時存儲問題，讓用戶免于頻繁地建表和刪表等操作。用戶可將業務上的中間計算數據存入臨時表，用完后自動清理回收，避免業務過于復雜，減少表管理開銷，并提升性能。

TiDB 臨時表主要應用于以下業務場景：

• 緩存業務的中間臨時數據，計算完成后將數據轉儲至常規表，臨時表會自動釋放。
• 短期內對同一數據進行多次 DML 操作。例如在電商購物車應用中，添加、修改、刪除商品及完成結算，并移除購物車信息。
• 快速批量導入中間臨時數據，提升導入臨時數據的性能。
• 批量更新數據。將數據批量導入到數據庫的臨時表，修改完成后再導出到文件。

一條 SQL 語句輕松創建臨時表

可通過 CREATE [GLOBAL] TEMPORARY TABLE 語句創建臨時表。臨時表中的數據均保存在內存中，用戶可通過 tidb_tmp_table_max_size 變量限制臨時表的內存大小。

TiDB 提供的臨時表分為 Global 和 Local 兩類，無論使用哪種臨時表，都能有效幫助用戶簡化業務邏輯并提升性能：

• Global 臨時表：
• 對集群內所有 Session 可見，表結構持久化。
• 提供事務級別的數據隔離，數據只在事務內有效，事務結束后自動刪除數據。
• Local 臨時表：
• 只對當前 Session 可見，表結構不持久化。
• 支持重名，用戶無需為業務設計復雜的表命名規則。

提供會話級別的數據隔離，降低業務設計復雜度，會話結束后刪除臨時表。

結語

本次發布的 5.3.0 版本進一步完善了系統的可觀測性、提升了分布式數據庫可擴展性、保證了數據的低延遲同步、大幅提升了全量數據遷移效率、提升了實時分析的穩定性，是 TiDB 邁向成熟企業級 HTAP 平臺的一個重要里程碑。

PingCAP 首席架構師唐劉表示：TiDB HTAP 的使命不僅僅局限于對傳統數據庫的升級或者是交易和分析處理性能的提升，本質上 TiDB HTAP 是一個開放的生態體系，在企業中承擔著支持數據服務消費化和構建統一實時數據服務平臺的角色，為用戶帶來業務與架構的創新與提升。

TiDB 的每一次發版和進步都離不開每一位用戶的反饋、每一位開發者的 PR 合并、每一位質量保證人員的測試。感謝所有人的貢獻，TiDB 在后續版本中會不斷加強大規模場景下的穩定性和易用性，不忘初心，砥礪前行，成為一款讓人愛不釋手的基礎軟件，給用戶帶來更好的使用體驗。