TiDB v6.2 于 8 月 23 日發布。在全新的版本中，TiDB 提供了諸多方面的提升，它們主要集中于：可觀測性，性能，穩定性，數據生態加強以及 MySQL 兼容幾個領域。
可觀測性
在新版本中，TiDB Dashboard 支持了可視化執行計劃。以往 TiDB 用只能借助觀察文字輸出的執行計劃排查問題，這對于簡單的交易類 SQL 而言問題并不大，但分析型 SQL 很可能會產生龐大的執行計劃信息，造成用戶難以觀察分析。在新版本中，TiDB Dashboard 在 Statements 和 Slow Query 中提供可視化執行計劃和基礎問題診斷的能力。這是一種全新的查詢計劃的展示方式，目標是通過圖形化的手段展示 Query 查詢計劃的每個步驟，從而使得用戶能夠更加直觀方便地了解查詢執行計劃的細節。對于復雜的大型查詢語句，可視化的展示方式對于深入理解其執行過程大有裨益。
在這個版本中，TiDB Dashboard 也新增的 Monitoring 頁面，展示了在業務性能調優中所需的核心指標，使得用戶大部分的日常運維監控需求可以在這里完成，無需在 Grafana 和 Dashboard 間跳轉。
除此之外，新版本中 TiDB 鎖視圖支持樂觀事務被阻塞的信息。大量鎖沖突往往會造成嚴重的性能問題，而鎖沖突定位是這類性能問題排查的必要手段之一。TiDB v6.2.0 之前版本支持通過系統視圖 INFORMATION_SCHEMA.DATA_LOCK_WAITS 查看鎖沖突關系，但是不支持樂觀事務被悲觀鎖阻塞的情況。TiDB v6.2.0 擴展了 DATA_LOCK_WAITS 視圖，提供樂觀事務被悲觀鎖阻塞情況下的沖突關系，可以幫助用戶快速定位鎖沖突，同時為業務改進提供依據，從而減少這類鎖沖突的發生頻率，提升系統整體性能。
性能
在新版本中 TiDB HTAP 性能有進一步提升。
首先，TiFlash 在 6.2.0 中引入了新的存儲格式 PageStore V3。該格式大幅減輕了在高并發、高負載場景下 GC 造成 CPU 占用高的問題，可以有效減少后臺任務 IO 流量，提升高并發、高負載下的穩定性。6.2.0 版本默認以新版本存儲格式保存數據。
在計算引擎方面，TiFlash 通過實現細粒度數據交換（shuffle）使窗口函數 （Window function） 可以利用多線程并行計算，成倍降低查詢響應時間，使其在典型場景下可提速 4～5 倍。而在去重計算 COUNT(DISCINT) 中，分析引擎通過降低數據傾斜優化了計算效率。
除了分析場景，新版本中引入新的 DDL 并行執行框架，在不同表對象上的 DDL 可以并發執行，解決了之前不同表之間 DDL 相互阻塞的問題。同時在不同表對象的追加索引、列類型變更等場景下支持并行執行，大幅提升執行效率。
穩定性
除了性能加強，V6.2 也包含了重要的穩定性加固。
TiKV 在新版本中支持自適應調整 CPU 使用率。數據庫通常會使用后臺進程來執行一些內部操作，通過采集各種統計信息，幫助用戶定位性能問題，生成更優的執行計劃，從而提升數據庫的穩定性和性能。然而如何平衡后臺操作和前臺操作的資源開銷，在不影響用戶日常數據庫使用的基礎上如何更高效地采集信息，一直是數據庫領域最為頭疼的問題之一。從 v6.2.0 開始，TiDB 支持通過 TiKV 配置文件設置后臺請求的 CPU 使用率, 進而限制自動統計信息收集等后臺操作在 TiKV 的 CPU 使用比例，避免極端情況下后臺操作搶占對用戶操作的資源，確保數據庫穩定高效運行。同時 TiDB 還支持 CPU 使用率自動調節的功能, 這時 TiKV 會根據實例的 CPU 占用情況, 自適應地對后臺請求占用的 CPU 資源進行動態調整。該功能默認關閉。
而 TiFlash 則加固了在處理大量數據的場景。在新版本中，通過減少分布式事務處理的內存放大（memory amplification），TiFlash 大幅降低了內存消耗，相較于 v6.1 之前版本最好的情況下內存使用峰值可降低 50% 以上，從而減少了大規模分析場景下不同任務內存資源沖突問題出現的可能性。
數據生態培育
在新版本中，最重要的數據生態功能是支持 Point-in-Time Recovery (PiTR)。PiTR 指的是允許用戶在新集群上恢復備份集群的歷史任意時刻點的快照。從技術而言，PiTR 是基于變更日志和快照數據共同進行的數據備份和恢復。該功能可以滿足以下的用戶需求：
· 降低備份恢復在災備場景下的 RPO，如實現十幾分鐘的 RPO；
· 用于處理業務數據寫錯的案例，如回滾業務數據到出錯事件前；
· 業務歷史數據審計，滿足行業合規的需求。
針對數據導入場景，TiDB Lightning 優化并減小了導入對集群帶來的性能影響。TiDB Lightning 原有的物理導入模式 (backend='local') 對目標集群影響較大，例如導入過程將停止 PD 調度等，因此僅適用于目標集群初次導入數據。新版本中，TiDB Lightning 在現有基礎上做了改進，導入時影響范圍由集群級別降低到表級別，即非導入的表仍可進行讀寫操作。
除此之外，BR 現在已支持恢復用戶和權限數據，這使得備份恢復體驗變得更平滑，用戶不再需要在集群恢復之后單獨處理用戶和權限信息。
最后，TiCDC 加入了 DDL 過濾機制。自 v6.2 起，TiCDC 支持過濾指定類型的 DDL 事件，支持基于 SQL 表達式過濾 DML 事件，從而適應更多的數據同步場景。例如在一些特殊的場景下，用戶可能希望對 TiDB 增量數據變更日志進行一定規則的過濾，例如過濾 Drop Table 等高風險 DDL。
MySQL 兼容
在 MySQL 兼容的道路上，TiDB 在 v6.2 加入了 SAVEPOINT 機制以及單 ALTER TABLE 語句增刪改多個列或索引。
先說說 SAVEPOINT。事務是數據庫保證 ACID 特性的一系列連續操作的邏輯集合。在一些復雜業務場景下，你可能需要管理一個事務的大量操作，有時候需要在事務內實現部分操作的回退能力。SAVEPOINT 就是針對事務內部實現的可命名保存點機制，通過這個機制，你可以靈活地控制事務內的回退節點，從而實現更復雜的事務管理能力，實現更為多樣的業務設計。
然后是 ALTER TABLE 操作多列和多索引。之前版本中，TiDB 僅支持單一 DDL 變更，導致用戶在遷移異構數據庫時經常會遇見 DDL 操作不兼容的情況，需要耗費額外的精力將復雜的 DDL 修改成 TiDB 支持的多個簡單 DDL。同時還有一些用戶依賴 ORM 框架，實現 SQL 組裝，最終出現了 SQL 不兼容等問題。TiDB 從 v6.2.0 開始，支持使用 ALTER TABLE 語句修改一個表的多個模式對象，方便了用戶 SQL 實現，也提升了產品易用性。
