我們很高興向大家宣佈，TiDB 6.1 於 6 月 xx 日釋出了，這是 TiDB 6 系版本的第一個 長期支援版（Long Term Support）。

長期支援版

在兩個月前釋出 TiDB 6.0 版本時，我們提過在新發版流程中，我們引入了 LTS 版本的概念，與之相對的是 開發里程碑版本（Development Milestone Release）。引入這兩種概念是為了讓 TiDB 的發版節奏能兼顧快速變化的市場需求以及企業版對穩定性的要求。

我們重新思考了發版模型， 最後選擇了長期支援版結合開發里程碑版的方式：我們保持 2 個月左右一次發版的節奏，以期快速應對市場節奏，但不再對所有釋出進行長期維護，而是 以半年左右為節奏揀選其中一個版本作為 LTS 長期支援版本。針對 LTS 版本我們提供針對問題的修復補丁而不再合併新功能。與此相對的， DMR 版本則保持快速發版的節奏，不斷髮布新特性，讓使用者所需的新需求不必等待很久（但並不提供基於 DMR 的問題修復）。對於使用者而言，在沒有特定需求開發的情況下，可以選擇最新的 LTS 版本投產；如果需求某個 DMR 釋出的新功能，則可以選擇該版本進行 PoC 以及試執行，待到對應的 LTS 版本釋出後升級 TiDB 到穩定生產狀態。這樣快慢結合的方式，可以最大限度兼顧快速迭代和穩定投產兩方面的需求。

對應 LTS 穩定版的主旨，6.1 版本中攜帶了重要的穩定性更新：

1. 提升 TiKV 高壓場景下的記憶體穩定性。
2. 解決了由於 Raft Log 複製流量過大導致的 OOM 問題。
3. 解決了在高壓場景下當機後重啟過程中長時間持續反覆 OOM 的問題。
4. 完善了 TiDB Server 記憶體使用跟蹤統計，加強查詢記憶體使用配額限制。
5. 優化了部分統計資訊記憶體使用。

另外，新版本也包含了 42 個問題修復和 20 個改進提升。

雖是 LTS，仍有新驚喜

TiDB 6.1 除了作為第一個推薦投產的 6 系版本，本身也攜帶了諸多強大的特性。

HTAP 基礎能力提升

在新版本中，部分分割槽表的實驗特性 GA，且分析引擎加入了分割槽表和視窗函式支援。

讓我們先來看看分割槽表：我們在版本 5 中引入了 List 分割槽和動態裁剪特性，但一直保持實驗特性狀態。更重要的是，由於舊有的分割槽靜態裁剪在 MPP 下表現欠佳，因此 TiFlash 引擎一直以來並未完整支援分割槽表特性。這次新發布中，我們宣佈  List 分割槽 / 分割槽動態裁剪以及 MPP 模式下的分割槽表支援 GA。對於分割槽表本身在此無需過多贅述，各位可以參考官方文件，我們單獨說下分析引擎下的分割槽表支援。

對於列存引擎而言，由於並不支援類似行存的細粒度索引，僅僅依靠粗糙索引並不能滿足資料過濾需求。而分割槽表作為列存下最高效的資料過濾手段，是分析場景下需求優先順序非常高的特性。例如在訂單 管理場景下，使用者的資料天然可以將訂單建立日期作為分割槽依據按天將一個月的資料分成 30 個分割槽，而使用者的分析查詢往往更高頻查詢最近一週甚至三五天的訂單資料。在以往分析引擎不支援分割槽的情況下，TiDB MPP 只能進行全表掃描，這不但浪費了無謂的儲存頻寬，也會消耗 CPU 針對日期欄位進行過濾。而在 6.1 版本中，對於上述例子， 只要查詢條件帶有訂單建立日，則可以數倍甚至數十倍提高查詢效率。

在 6.1 中另一個分析場景下常用的新功能是  MPP 下的視窗函式支援。在新版本中，MPP 執行器加入了對視窗函式的框架性支援，並隨之推出了三個最常用視窗函式 rank，dense_rank 以及 row_number。這使得在 MPP 執行模式下，視窗函式除了記憶體消耗可以被分散式分擔，效能也得到大幅提升。以 100G 規模資料集測試為例 ，新版本中查詢使用單節點 MPP 模式進行視窗函式計算將提速 282%，使用更多節點將有更大幅度提速。與以往 MPP 模式下對內建函式的支援一樣，我們將逐步增加對各類視窗函式的支援。

新版本中， TiDB 引入了非事務性 DML 語句以應對大批量資料變更。新加入的非事務性 DML 是將一個普通 DML 拆成多個 SQL 執行，以犧牲事務的原子性和隔離性為代價，增強批量資料處理場景下的效能和易用性。典型的，在新版本中可以使用如下語句淘汰過期資料，而無需擔心事務大小限制問題：

BATCH ON id LIMIT 2 
DELETE 
FROM orders 
where create_date < 
'2022-05-01';

上述 SQL 將會以 2 批次的方式執行 DELETE 操作，以控制單次操作的記憶體佔用。當前版本中，TiDB 僅支援非事務性刪除。

除了上述三個功能外， TiFlash 列式儲存引擎進行了效能優化，使得在寫入場景下大幅度節省了硬體資源。實際混合負載業務測試顯示，寫流量從峰值 140MB/s 下降為 50MB/s，峰值 CPU 從 3000% 下降到 2500%，記憶體峰值從 28GB 降為 18GB，且大幅減少 IO 抖動。

更完善的生態對接

資料庫從來都不是單獨被使用的，而 TiDB 也在持續改進和生態環境的對接。 在新版本中，TiDB 引入了使用者級別鎖和 TiCDC 下的 Avro 格式向 Kafka 同步資料的支援。

先說 使用者級別鎖。使用者級別鎖是 MySQL 通過內建函式提供的使用者命名鎖管理系統。它們可以用在 SQL 語句的 SQL 函式中，比如 select，where 子句，group by 子句等位置使用。這些語句可以在不同的程式碼處阻塞，等待，實現使用者級別鎖管理。使用者級別鎖在 ORM 框架中也有較為廣泛的應用，例如 RoR, Elixir 和 Ecto 等。TiDB 從 6.1 版本開始支援相容 MySQL 的使用者級別鎖管理，支援 GET_LOCK，RELEASE_LOCK, RELEASE_ALL_LOCKS 等鎖管理函式，這使得 TiDB 得以更好支援現有 ORM 框架的生態。

對 TiDB 而言，TiCDC 是叢集資料實時變更資訊的出口，而 支援常用的資料格式以方便消費者解析則是降低開發複雜度的必修課。Avro 作為一種資料序列化系統，採用了壓縮二進位制格式，傳輸效率高，資料格式豐富，已經被大量的資料分析、資料整合產品所支援。TiCDC 支援將 TiDB 資料庫的增量資料轉換為 Avro 格式，併傳送到 Kafka 的方式，這將使得 TiDB 資料庫和眾多的生態系統，例如：Kafka、Snowflake、SQL Server 連結起來。在新版本中，向其他系統實時同步 TiDB 的資料改變，無論是用於實時資料整合還是變更訂閱觸發操作，都可以藉助 Avro 格式變得更簡單。更進一步，一些仰賴 Avro 格式的其他生態功能，現在也得以發揮熱量，例如使用者可以藉助 Avro 格式通過 Kafka kSQL 對變更日誌進行實時計算。

行動起來

除了上述所有新功能外，其實  TiDB 6.1 作為 6 系版本的第一個推薦生產的 LTS 版本，是所有需求 6.0 版本特性的使用者的理想選擇。無論你已經在使用 6.0 版本，還是正在調研中，都推薦大家部署 6.1 版本或升級。相信新版本將為廣大使用者提供強大的功能和穩定的體驗。