在2023 伊始，我們很高興向大家宣佈，TiDB 6.5 LTS 版本已經發布了。這是 TiDB V6 的第二個長期支援版（上一個是 TiDB 6.1），除了攜帶了諸多備受期待的新特性，同時也將得到 TiDB 開發社群的長期維護，是推薦企業級使用者採用的最新版本。

在這個版本中，TiDB 專注於如下幾個主題：

- **產品易用性進一步提升**
- **核心不斷打磨，更加成熟**
- **多樣化的災備能力**
- 應用開發者生態構建

相信長期關注我們的朋友已經發現，這些主題似曾相識。的確如此，TiDB 近年的發展幾乎都圍繞著它們開展。我們期望 TiDB 成為**更易用，對開發者更友好，且更成熟的企業級資料庫**，而這個追求也並沒有盡頭。

## 產品易用性進一步提升

大家也許不止一次聽說過，易用性之於 TiDB 是非常關鍵的理念。畢竟，TiDB 伊始是為了解決分庫分錶帶來的麻煩，這也使得易用性在 TiDB 研發過程中貫穿始終。在新版本中，我們提供了更多的讓使用者解放心智的能力。

### AND 運算下的索引歸併讀取

對於資料服務和洞察場景，使用者往往會基於諸多查詢條件的組合進行資料篩選。例如在物流場景中，使用者可能會根據下單日，倉庫 ID，轉運人，送達日，目標地址等等不同維度進行篩選再分析。而這些條件單獨來看，並不一定具備很好的選擇性，只有組合起來才能將資料限定在一個小範圍。如果條件的組合不多，我們尚可使用特定的組合索引覆蓋，但很可能在這類場景中，組合以數十記，完全無法為每個組合都建立特定索引。在新版本中，TiDB 支援根據 AND 條件組合同時選中多組索引，並計算它們的交集再讀取實際表資料。這種能力，使得使用者可以僅僅為單列建立少量索引，以達到更好的選擇性以及更優的效能。

### 叢集閃回

有時候，使用者會希望整個叢集快速恢復到之前的某個時間點。例如，由於遊戲伺服器新版本資料設定問題，將一把絕世好劍設定為 1 元，造成新版釋出後一小時內人手一把。若僅僅如此也就算了，開發者可以很容易回收或這個道具，但這種事故還有次生災害，例如稀有 Boss 被濫殺，稀有掉落隨之氾濫，整個遊戲內容崩壞。這時候作為遊戲設計師，你可能會希望時間能回到犯錯之前的那一刻，讓你修正那個令人追悔莫及的錯誤。在新版本中，TiDB 就提供了這個能力，它支援用簡單一條命令向 GC 時間內的任意時間點進行全叢集閃回，就像下面這樣。

```sql
FLASHBACK CLUSTER TO TIMESTAMP '2022-09-28 17:24:16'; 
```

我們當然希望這不會是一個常見的狀況，但這並不表示需要閃回的時機千年難遇：閃回能力也可用於日常操作，例如將測試環境恢復到測試開始前的狀態，以供反覆使用。

### 完整的大事務自動拆分支援

在前序版本中，我們支援了針對刪除的大事務自動拆分支援。而在新版本中，TiDB 完整支援了針對插入和修改的大事務拆分。在以往版本中，TiDB 使用者經常要面對的一個問題就是，一些大規模的資料變更維護操作，例如過期資料刪除，大範圍資料修訂，或者根據查詢結果回寫資料等操作，會遇到超過 TiDB 單條事務上限的問題，這是由於 TiDB 單一事務需要由單一 TiDB Server 作為提交方而帶來的限制，這時候使用者往往不得不手動想辦法拆小事務以繞過該限制。但在實際使用中，上述型別的資料變更未必真的需要作為單一事務確保原子性，例如資料淘汰和資料修訂，只要最終執行完成，哪怕事務被拆開多次執行也並不會影響使用。在 TiDB 6.5 中，我們提供了將大事務自動拆分的能力，例如按照 t1.id 以 10000 條為大小分批資料更新，可以簡單使用如下語句完成：

```sql
BATCH ON t1.id LIMIT 10000 update t1 join t2 on t1.a=t2.a set t1.a=t1.a*1000;
```

更詳細的說明請[參考文件](https://docs.pingcap.com/tidb/stable/non-transactional-dml)。

### TiFlash 結果物化（實驗特性）

TiFlash 在過往版本中有一個很大的缺憾是無法在讀寫事務中使用：經常使用者希望將 TiFlash 的計算結果進行回寫以供高併發讀取（類似物化效果）。從 v6.5.0 起，TiFlash 支援透過 INSERT SELECT 語句回寫結果進行物化，節省系統資源並提高響應速度。

```sql
INSERT INTO top_payments SELECT MAX(amount) FROM payments;
```

在執行上述 INSERT INTO SELECT 語句時，TiDB 可以將 SELECT 子查詢下推到 TiFlash 以提供高速分析計算，並將返回結果透過 INSERT INTO 可以儲存到指定的 TiDB 表中。值得一提的是，該功能結合前述大事務拆分可以實現大量結果集物化。

### 高效能全域性單調遞增 AUTO_INCREMENT 列

TiDB 作為一款分散式資料庫，以往在使用 AUTO INCREMENT 列建立主鍵時，僅保證在每個 TiDB 例項中序列遞增，而跨 TiDB 例項則無法保證。但實際使用中，使用者仍然經常會遇到需要嚴格單調遞增主鍵的時候，例如以主鍵隱式代表時間維度，確定事件發生順序。在 6.4 版本中，我們加入了高效能的全域性單調遞增主鍵的支援，以相容 MySQL 的行為。該模式下，TiDB 將採取中心化的主鍵分配以確保單調遞增，即使跨 TiDB 例項訪問，ID 也不會出現回退，且針對其的寫入也可輕鬆達到數萬的 TPS。

### 使用 TTL (Time to Live) 來週期性地刪除過期資料（實驗特性）

維護資料的生命週期在 TB 以上規模下並不是很容易的事情：由於資料規模大，尋找並清理過期的資料往往需要消耗相當的算力，有時使用者為了更快清理資料甚至被迫使用分割槽表，以刪除分割槽的方式來進行快速清理。更麻煩的是，使用者需要維護特定的任務以不斷定期淘汰資料。在新版本中，TiDB 提供了 Time to Live (TTL) 能力，使得使用者可以設定行級別的生命週期控制策略。透過為表設定 TTL 屬性，TiDB 可以週期性地自動檢查並清理表中的過期資料。當開啟時，TTL 會以表為單位，併發地分發不同的任務到不同的 TiDB 例項節點上，進行並行刪除處理，且不影響叢集效能。更詳細的說明請[參考文件](https://docs.pingcap.com/tidb/stable/time-to-live)。

## 核心關鍵特性打磨和增強

TiDB 包含繁多的特性集合，但其中有些仍需不斷打磨，例如 JSON 雖然已獲支援許久，但實際能力卻尚需完善。在新版本中，我們針對重要特性集合用力打磨，以期提供給使用者更「絲滑」的體驗，讓 TiDB 的重大特性以更完善的方式呈現在使用者面前，也讓 TiDB 演進方式更穩重更有質量。

**首先是 DDL 加強**。支援線上 DDL 是 TiDB 的核心優勢之一，在過往一年中，我們加入了對並行 DDL 的支援，使得例如 SaaS 等多租戶場景下不會因為同時進行的 DDL 互相阻塞，而 DDL 干擾 DML 的情況也透過 Metadata Lock 得以解決。在新的 6.5 版本中，TiDB 支援了類似 Lightning 注入 SST 的設計，針對需要追溯的歷史資料直接使用 SST 構建的方式進行生成，大幅提高了 DDL 的構建速度，最快可達 **10 倍提升**。

如下圖所示，以 TiDB 6.1 版本為基準值，新版除了取得了數量級的提速，且對比 CockroachDB v22.2 和當前版的 AWS Aurora 也快 2-3 倍。

**其次是 JSON 的支援打磨**。JSON 對於需要靈活資料結構的場景非常重要，因此在移動端，遊戲開發等場景中廣泛使用。從 6.2 版本以來，在這半年中 TiDB 陸續引入了完整的 MySQL 5.7 相容函式，針對 JSON 的表示式索引支援，更多的生態工具相容以及更好的 TiFlash 引擎支援。

**再者是 TiDB 全域性記憶體控制**。自 v6.5.0 起，TiDB 全域性記憶體控制已能夠跟蹤到 TiDB 中主要的記憶體消耗。當單個會話的記憶體消耗達到系統變數 `tidb_mem_quota_query` 所定義的閾值時，將會觸發系統變數 `tidb_mem_oom_action` 所定義的行為 (預設為 `CANCEL`，即取消操作)。當全域性記憶體消耗達到 `tidb_server_memory_limit` 所定義的預設值時，TiDB 會嘗試 GC 或取消 SQL 操作等方法限制記憶體使用，保證 TiDB 的穩定性，對記憶體的使用效率也更加高效。

**最後是降低累積的悲觀鎖對效能的影響**。 在一部分交易系統，尤其是銀行業務中，客戶應用會在悲觀事務中利用 select for update 先鎖定一條記錄，從而達到對資料一致性的保護，減少事務中後續操作失敗的可能，比如

```sql
BEGIN;
SELECT c FROM sbtest1 WHERE id = 100 FOR UPDATE; 
UPDATE sbtest1 SET k = k + 1 WHERE k = ?; 
COMMIT;
```

而在 TiDB 中，對一行記錄反覆的 select for update，會造成這條記錄的查詢效能下降。 在 v6.5.0 中，我們對這部分機制進行了最佳化， 透過記錄連續的鎖標記，降低了累積的悲觀鎖對查詢效能的影響，QPS 可大幅提升 10 倍以上。

## 多樣化的災備能力

在過往版本中，TiDB 主要依賴 BR 進行靜態的備份恢復，而在 6.2 之後的新版中，TiDB 提供了 PITR 能力，使得資料庫可以更靈活地恢復到任意時間點。

TiDB PITR（Point-in-Time Recovery）是結合了 BR 和變更捕獲（Change Data Capture）兩種能力的災備特性。以往 BR 的靜態災備只能將資料恢復到備份的時間點，如果要更提供針對更新和更多時間點的恢復，則相應需要提高備份頻率。這不但會加重備份對線上業務的負擔，也需要更多儲存成本。使用 PITR 則可以擺脫這個煩惱，使用者無需不斷進行全量備份，而是可經由一個全量備份結合增量共同完成針對任意時間點的資料恢復。

經過半年左右的持續改進，在新版本中，我們減少了 PITR 備份檔案大小和數量，加強了穩定性，提升了效能。 例如：確保在絕大多數異常場景下 RPO < 5mins, 單個 TiKV 的備份速度達到100MB/s等，針對 PITR 更詳細的介紹，請參考[這篇部落格](https://docs.google.com/document/d/102x8nT6wW4he8GEt7_hxt8TnCgNjyVZHV0hdu2r6s00/edit#)。

與此同時，在 6.5 版本中，TiCDC 的吞吐獲得了得了至數倍的提升。透過對 TiCDC 內部的設計和實現的不斷最佳化，針對資料複製場景，當下遊為 Kafka 叢集時，針對大單表場景的吞吐量得到了極大的提升，單個 TiCDC 節點可以支援35k row/s QPS，吞吐量可以達到 50MB/s，並將延遲控制在 2 秒左右，而記憶體使用量只有之前版本的50%左右。 針對跨區域主備叢集容災場景，TiCDC 單個節點的吞吐量可以達到 30MB/s，並且其延遲也可以穩定在 2 秒左右，穩定性大幅度提高。

其次，在6.5 版本中，DM 正式釋出了在資料遷移過程中的增量資料持續校驗功能，該特性只對新增或變更的資料進行校驗，而不是對整個資料集進行校驗，在確保資料遷移過程的準確性和可靠性的同時，大大減少資料校驗的時間和資源消耗。尤其是在遷移一些重要系統時，該特性可以讓資料遷移過程更加安全。

除此以外，新版本支援了在下游叢集使用水位線進行一致性讀取的能力：在新版本中，TiCDC 可以在向下遊寫入時提供特殊的時間戳，而下游叢集則可以自動使用該時間戳進行一致性讀取而無需擔心讀到的事務不完整。這使得下游叢集在需要嚴苛事務保證的場景下，也可以良好承擔讀流量分流的職責。

## 應用開發者生態構建

在以往版本中，TiDB 更強調 DBA 的使用體驗。但在近期的更新中，你也許已經發現我們逐漸開始聚焦 DBA 以外的應用開發者體驗。在新版中，我們強化了應用開發所需的生態環境構建，例如這半年來 TiDB 透過增加對 Savepoint，User Level Lock，Multiple Schema Change 等功能的支援，完善了針對常見應用框架 django，prisma 等的支援。與此同時，我們也引入了更多上下游生態廠商的戰略合作：Vercel，Hashicorp，Retool 等。在 6.5 版本中，TiCDC 增加了針對向 Object Storage 寫入的支援。物件儲存是一種面向雲的儲存服務，具有高可擴充套件性、高可用性、低成本等優勢。使用 TiCDC 將資料同步到物件儲存，可以幫助使用者實現資料的長期儲存、資料的跨區域複製等目的。另外，這使得 TiDB 在雲環境下能直接打通向數倉和資料湖環境的通路。更好的生態支援，將使得開發者在使用 TiDB 構建應用時，擁有更多選擇，也更簡便。

## 總結

作為 TiDB 版本 6 的第二個長期支援版，TiDB 6.5 已經發布。我們希望藉助這個版本為更多使用者提供更易用且更成熟的企業級資料庫。更詳細的變更情況請參閱 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-6.5.0)。歡迎各位和我們一起開啟新的[奇妙旅程](https://docs.pingcap.com/zh/tidb/stable/quick-start-with-tidb)。

TiCDC 在大單表場景下的效能最佳化：我們如何將吞吐量提升 7 倍？

相關文章