自 TiDB 5.0 發布以來，陸續在金融、互聯網 & 新經濟、物流等行業用戶的生產環境得到應用，收獲不少用戶的積極評價：
TiDB 服務 58 金融、安居客等數倉報表的復雜讀取與關聯查詢，在多表關聯查詢中，相比 4.0 版本性能最高提升達 90%；經過網易互娛場景實測，與 4.0 相比 TiDB 5.0 整體性能表現更加穩定，沒有出現明顯的抖動；TiDB 5.0 在汽車之家大數據 join 與聚合場景的應用中，MPP 體現出明顯的優勢，與 MySQL 相比總體效能提升 20 - 50 倍。
“用戶的反饋激勵我們不斷前行，我們的使命是持續提升開發者和 DBA 的體驗，讓用戶用得省心，用得順手。” PingCAP 聯合創始人兼 CTO 黃東旭說，“ TiDB 每一個版本的發布都立足于解決 DBA 的痛點。真實場景就是最好的架構師，從 5.0 版本開始 TiDB 縮短了發版周期，采用了更靈活、更敏捷的火車發版模型，每一個用戶真實場景需求的輸入，在兩個月周期內就有可能成為下一個版本交付的功能。”
得益于大量用戶真實應用場景的快速反饋，TiDB 5.1 提速發版，進一步打造更流暢的企業級數據庫體驗。TiDB 5.1 擁有更加穩定的響應延遲表現，更優的 MPP 性能與穩定性，更便捷的可運維性，開發者和 DBA 可以輕松地基于 TiDB 5.1 構建任意規模的關鍵業務應用。
TiDB 5.1 功能亮點和用戶價值
支持 ANSI SQL 99 標準的 Common Table Expression，用戶可以寫出更加簡潔、更易維護的 SQL 代碼，輕松應對復雜的業務邏輯，提高開發效率。進一步提升 MPP 性能和穩定性，幫助用戶更快做出實時決策。5.1 通過支持 MPP 模式下的分區表以及新增的多個函數表達式和算子優化，實時分析性能提升一個數量級以上；通過增強的內存管理和負載平衡機制，讓分析查詢變得更快、更穩。在突發的大流量寫入、集群擴縮容以及在線數據導入和備份等場景下，5.1 版本優化了數據庫的長尾查詢延遲的穩定性，應對不同的工作負載，延遲能夠降低 20% - 70% 。尤其對于金融行業延遲敏感類型的關鍵業務應用，大幅提升了在高壓力負載下的查詢穩定性。支持列類型變更，與 MySQL 兼容度更高。5.1 新增 Stale Read 模式，在讀寫分離場景中通過打散讀熱點大幅提升讀吞吐能力；引入新的系統表，實現在高并發事務場景中快速定位鎖沖突；改進統計信息分析引擎，提升優化器選擇索引的精準度，保障業務查詢的效率和穩定性。面向大集群提供更加友好的運維體驗，進一步降低 DBA 工作負荷。5.1 版本集群擴縮容和數據遷移速度提升 40%，改善了大規模集群運維的可靠性，降低大規模集群整體備份和恢復的耗時，通過優化 CDC 數據鏈路臨時中斷后的自動恢復機制，進一步提升數據同步鏈路的可靠性。
Common Table Expression 讓 SQL 化繁為簡
在金融交易類場景，由于業務的客觀復雜性，有時候會寫出長達 2000 行的單條 SQL 語句，其中包含大量的聚合和多層子查詢嵌套，維護此類 SQL 堪稱開發人員的噩夢。5.1 版本支持 ANSI SQL 99 標準的 Common Table Expression（CTE）及遞歸的寫法，極大提升開發人員和 DBA 編寫復雜業務邏輯 SQL 的效率，增強代碼的可維護性。
HTAP 實時分析能力再升級
進一步提升 MPP 的性能和穩定性
5.1 版本進一步增強 TiFlash MPP 計算引擎的綜合能力，幫助用戶提升業務決策速度：
MPP 支持分區表，結合業務邏輯可優化海量數據分析查詢所消耗的資源，提升查詢速度；新增多個常用 SQL 函數支持，并優化算子使得查詢能夠更充分利用 MPP 來加速；提供便利的強制 MPP 模式開關，用戶可自主決定是否開啟 MPP 模式；通過優化集群負荷的分散與平衡機制，消除熱點，提升系統“綜合”承載能力；修復引擎內存使用問題，提供更加平穩流暢的使用體驗。
提升高壓力負載下查詢分析的穩定性
在金融類業務場景下，技術人員每天會對數據進行高壓力的跑批計算，生成最新的市場和營銷分析報告，以輔助商業決策。跑批流程對連續性要求極高，無法容忍中間過程出錯。針對該場景，5.1 版本優化了 TiDB 的請求重試機制和 TiKV 的請求處理機制，顯著降低了在高負載下由于 TiFlash 同步數據不及時導致的 Region Unavailable 出錯概率。
無縫集成 TiSpark
TiSpark 5.1 版本實現了對含有聚簇索引表的讀寫支持，不帶來任何額外的性能開銷，對用戶完全透明，用戶可以立刻遷移到新版 TiSpark 來體驗與 TiDB 5.1 的無縫集成。
降低讀寫延遲抖動
在延遲敏感的應用場景下，當線上產生突發寫流量、操作 TiDB 擴縮容、后臺執行統計任務，以及在線數據導入和備份時，可能造成數據庫的 P99 和 P999 百分位的延遲抖動，對長尾查詢產生一定影響
TiDB 5.1 加強了對磁盤讀寫鏈路的管理，限制后臺任務對磁盤資源的使用，大幅降低上述場景對線上業務的干擾，改善讀寫鏈路的效率和穩定性。在 AWS EC2 r5b.4xlarge 實例掛載 EBS gp3 盤的環境下，通過 TPC-C 基準測試（10k WH）的實測結果：
操作集群從 6 臺 TiKV 縮到 3 臺，P99 響應時間降低 20%，P999 響應時間降低 15%；執行在線導入 200GB 數據，P99 響應時間降低 71%，P999 響應時間降低 70%。
增強業務開發靈活性
支持列類型變更
在典型的 TiDB 應用場景中，經常借助 binlog 將多個 MySQL 上游數據匯聚到一個 TiDB 集群。原先 TiDB 不支持變更列類型的操作，如果上游 MySQL 修改表的字段類型會導致與 TiDB 數據同步的中斷。5.1 版本新增對修改列類型 DDL 語句的支持，解決上述問題并進一步提升MySQL 兼容性。
Stale Read（實驗特性）
Stale Read 適用于讀多寫少并且能夠容忍讀到舊數據的場景。例如 Twitter 用戶發出一條消息后，系統會產生成千上萬甚至上億次讀取，并且新發出的消息在一定時間后被讀到是可以容忍的。該場景給數據庫帶來相當大的讀并發壓力，可能會產生讀熱點，導致節點的負載分布不均，整體吞吐成為瓶頸。借助 Stale Read，用戶可以指定一個過去的時間點從任意一個數據副本讀取數據（不必從 leader 讀取），從而顯著分散節點的壓力負載，使得整體讀吞吐能力提升近一倍。
/* 例如：可以通過設置當前事務為查詢 5 秒之前的數據狀態來開啟 Stale Read */
> SET TRANSACTION READ ONLY AS OF TIMESTAMP NOW() - INTERVAL 5 SECOND;
> SELECT * FROM T;
快速定位鎖沖突 (實驗特性)
業務開發需要很謹慎地處理數據庫并發事務，一旦發生鎖表會給線上業務帶來巨大影響，而 DBA 需要快速定位鎖表原因以保證業務能夠恢復正常。TiDB 5.1 中新增 Lock View 系統表視圖，可以快速定位到引起鎖表的事務和相關 SQL 語句，從而提高鎖沖突問題的處理效率。下面一個小例子展示如何使用 Lock View 快速定位發生鎖表的事務和 SQL 語句。
更快更準的統計信息分析
隨著業務數據持續不斷的變更，表的統計信息也會變得陳舊，進而導致優化器執行計劃準確度降低，使得查詢變慢。DBA 通過執行 ANALYZE 操作，對表的統計信息進行重建。TiDB 5.1 對 ANALYZE 采樣算法的性能進行了優化，生成統計信息的平均時間縮減為二分之一，同時新增一項新的統計數據類型，讓優化器選擇索引更加準確。
提升大集群運維和數據傳輸的可靠性
超多數量表的備份優化
優化超多數量表的備份，在 50k 張表的量級下，TiDB 集群全量備份時間降低到之前的 30~40%。此外， 5.1 版本優化了備份模塊的元信息文件組織形式（簡稱v2），啟動 BR 時可以通過指定參數 “--backupmeta-version=2” 來啟用 v2，從而減少單次寫入量來降低內存消耗，有效避免低規格內存（≤8GB）環境下的異常退出。
提升大規模集群運維可靠性
TiDB 集群規模越大對生產集群擴縮容、硬件升級以及節點搬遷等日常運維操作的耗時就越久。TiDB 5.1 顯著提升了擴縮容時數據遷移的性能，以下是兩組測試結果：
100 個節點規模下，完成集群所有數據跨數據中心遷移的耗時降低 20%；下線節點或對某節點的數據進行遷移，耗時縮短約 40%。
優化內存使用
內存溢出（Out Of Memory）一直是困擾數據庫行業的典型問題，5.1 版本針對 TiDB 的內存使用進行了一系列優化，從而降低 OOM 風險：
無論數據量大小，窗口函數 row_number 將只占用固定大小內存；優化分區表的讀取，占用更少內存；為存儲層加入可配置的內存限制，當限制觸發時，系統將釋放部分緩存以降低內存占用；TiFlash 寫入的內存占用比上一版本降低 80%。
提升 CDC 同步鏈路可靠性
TiCDC 5.1 在無需人工干預的情況下提供同步鏈路的可靠性：當發生環境擾動或硬件故障時，TiCDC 可以保證同步持續進行；即使發生同步中斷，TiCDC 也會根據實際情況自動進行重試。
最后，特別感謝小米、奇虎 360、知乎、愛奇藝、理想汽車、新浪、虎牙、小電、跨越速運、億瑪科技等公司和社區開發者們在 TiDB 5.1 版本的設計、開發和測試過程中做出的貢獻，是你們一如既往的支持，幫助 TiDB 在實際場景中持續提升開發者和 DBA 的使用體驗，讓 TiDB 變得更加簡單易用。
