TiDB 5.0.0-rc 版本是 5.0 版本的前序版本。在 5.0 版本中，我們專注於幫助企業基於 TiDB 數據庫快速構建應用程序，使企業在構建過程中無需擔心數據庫的性能、性能抖動、安全、高可用、容災、SQL 語句的性能問題排查等問題。
在 TiDB 5.0 版本中，你可以獲得以下關鍵特性：
開啓聚簇索引功能，提升數據庫的性能。例如：TPC-C tpmC 測試下的性能提升了 39%。
開啓異步提交事務功能，降低寫入數據的延遲。例如：Sysbench oltp-insert 測試中延遲降低了 37.3%。
通過提升優化器的穩定性及限制系統任務對 I/O、網絡、CPU、內存等資源的佔用，降低系統的抖動。例如：長期測試 72 小時，衡量 Sysbench TPS 抖動標準差的值從 11.09% 降低到 3.36%。
引入 Raft Joint Consensus 算法，確保 Region 成員變更時系統的可用性。
優化
EXPLAIN功能、引入不可見索引等功能幫助提升 DBA 調試及 SQL 語句的效率。通過備份文件到 AWS S3、Google Cloud GCS 或者從 AWS S3、Google Cloud GCS 恢復到 TiDB，確保企業數據的可靠性。
提升從 AWS S3 或者 TiDB/MySQL導入導出數據的性能，幫忙企業在雲上快速構建應用。例如：導入 1TiB TPC-C 數據性能提升了 40%，由 254 GiB/h 提升到 366 GiB/h。
SQL
支持聚簇索引（實驗特性）
開啓聚簇索引功能後，TiDB 性能在以下條件下會有較大幅度的提升, 例如： TPC-C tpmC 的性能提升了 39%。聚簇索引主要在以下條件時會有性能提升：
插入數據時會減少一次從網絡寫入索引數據。
等值條件查詢僅涉及主鍵時會減少一次從網絡讀取數據。
範圍條件查詢僅涉及主鍵時會減少多次從網絡讀取數據。
-等值或範圍條件查詢涉及主鍵的前綴時會減少多次從網絡讀取數據。
聚簇索引定義了數據在表中的物理存儲順序，表的數據只能按照聚簇索引的定義進行排序，每個表只能有一個聚簇索引。
用戶可通過修改 tidb_enable_clustered_index 變量的方式開啓聚簇索引功能。開啓後僅在創建新表時生效，適用於主鍵是多個列或者單個列的非整數類型。如果主鍵是單列整數類型或者表沒有主鍵，系統會按照原有的方式進行數據排序，不受聚簇索引的影響。
例如，可通過 select tidb_pk_type from information_schema.tables where table_name = '{tbl_name}' 語名可查詢 tbl_name 是否有聚簇索引。
支持不可見索引
DBA 調試和選擇相對最優的索引時，可以通過 SQL 語句將某個索引設置成 Visible 或者 Invisible，避免執行消耗資源較多的操作，例如：DROP INDEX 或 ADD INDEX。
DBA 通過 ALTER INDEX 語句來修改某個索引的可見性。修改後優化器會根據索引的可見性決定是否將此索引加入到索引列表中。
支持 EXCEPT/INTERSECT 操作符
INTERSECT 操作符是一個集合操作符，返回兩個或者多個查詢結果集的交集。一定程度上可以替代 Inner Join 操作符。
EXCEPT 操作符是一個集合操作符，將兩個查詢語句的結果合併在一起，並返回在第一個查詢語句中有但在第二個查詢句中不存在的結果集。
事務
提升悲觀事務執行成功的概率
悲觀事務模式下，如果事務所涉及到的表存在併發 DDL 操作和 SCHEMA VERSION 變更，系統會自動將該事務的 SCHEMA VERSION 更新到最新版本，確保事務會提交成功，避免事務因 DDL 操作而中斷。事務中斷時客戶端會收到 Information schema is changed 的錯誤信息。
字符集和排序規則
使用 utf8mb4_unicode_ci 和 utf8_unicode_ci 排序規則和字符集比較排序時不區分大小寫。
安全
錯誤信息和日誌信息的脫敏
系統在輸出錯誤信息和日誌信息時，支持對敏感信息進行脫敏處理，避免敏感信息泄露。敏感信息可能是身份證信息、信用卡號等。
通過 SQL 語句修改
tidb_redact_log=1開啓 tidb-server 的錯誤信息和日誌信息脫敏功能通過修改 tikv-server 的
security.redact-info-log = true配置項開啓錯誤信息和日誌信息脫敏功能通過修改 pd-server 的
security.redact-info-log = true配置項開啓錯誤信息和日誌信息脫敏功能 #2852 #3011通過修改 tiflash-server 的
security.redact_info_log = true以及 tiflash-learner 的security.redact-info-log = true配置項開啓錯誤信息和日誌信息脫敏功能
相關 issue：#18566
性能提升
支持異步提交事務（實驗特性）
開啓異步提交事務可使延遲有較大幅度的降低，例如：Sysbench oltp-insert 測試中開啓異步提交事務的延遲與不開啓時相比降低了 37.3%。
數據庫的客戶端會同步等待數據庫通過兩階段 (2PC) 完成事務的提交。開啓 Async Commit 特性後事務兩階段提交在第一階段提交成功後就會返回結果給客戶端，第二階段會在後臺異步執行。通過事務兩階段異步提交的方式降低事務提交的延遲。
此特性只能顯式地修改 tidb_guarantee_external_consistency = ON 變量後才能保證事務的外部一致性。開啓後性能有較大幅度的下降。
用戶可通過修改 tidb_enable_async_commit = ON 全局變量開啓此功能。
提升優化器選擇索引的穩定性（實驗特性）
優化器若無法長期穩定地選擇相對合適的索引，會在很大程度上決定着查詢語句的延遲是否有抖動。爲確保相同的 SQL 語句不會因爲統計信息缺失、不準確等因素導致優化器每次都從多個候選索引選持不同的索引，我們對統計信息模塊進行了完善和重構。主要完善如下：
擴展統計信息功能，收集多列 NDV、多列順序依賴性、多列函數依賴性等信息，幫助優化器選擇相對較優的索引。
-
重構統計信息模塊，幫助優化器選擇相對較優的索引。
從
SKetch中刪除TopN值。重構
TopN搜索邏輯。從直方圖中刪除
TopN信息，建立直方圖的索引，方便維護 Bucket NDV。
相關 issue：#18065
優化因調度功能不完善或者 I/O 限流不完善引起的性能抖動問題
TiDB 調度過程中會佔用 I/O、Network、CPU、Memory 等資源，若不對調度的任務進行控制，QPS 和延時會因爲資源被搶佔而出現性能抖動問題。通過以下幾項的優化，長期測試 72 小時，衡量 Sysbench TPS 抖動標準差的值從 11.09% 降低到 3.36%。
減少節點的容量總是在水位線附近波動引起的調度及 PD 的
store-limit配置項設置過大引起的調度，引入一套新的調度算分公式並通過region-score-formula-version = v2配置項啓用新的調度算分公式 #3269通過修改
enable-cross-table-merge = true開啓跨 Region 合併功能，減少空 Region 的數量 #3129TiKV 後臺壓縮數據會佔用大量 I/O 資源，系統通過自動調整壓縮的速度來平衡後臺任務與前端的數據讀寫對 I/O 資源的爭搶，通過
rate-limiter-auto-tuned配置項開啓此功能後，延遲抖動比未開啓此功能時的抖動大幅減少 #18011TiKV 在進行垃圾數據回收和數據壓縮時，分區會佔用 CPU、I/O 資源，系統執行這兩個任務過程中存在數據重疊。GC Compaction Filter 特性將這兩個任務合二爲一在同一個任務中完成，減 I/O 的佔用。此特性爲實驗性特性，通過
gc.enable-compaction-filter = ture開啓 #18009TiFlash 壓縮或者整理數據會佔用大量 I/O 資源，系統通過限制壓縮或整理數據佔用的 I/O 量緩解資源爭搶。此特性爲實驗性特性，通過
bg_task_io_rate_limit配置項開啓限制壓縮或整理數據 I/O 資源。
相關 issue：#18005
提升 Real-time BI / Data Warehousing 場景下 TiFlash 的穩定性
限制 DeltaIndex 的內存使用量，避免大數據量下內存使用過多導致系統 OOM。
限制後臺數據整理任務使用的 I/O 寫流量，降低對前臺任務的影響。
新增加線程池，排隊處理 coprocessor 任務，避免高併發處理 coprocessor 時內存佔用過多導致系統 OOM。
其他性能優化
提升
delete * from table where id < ?語句執行的性能，p99 性能提升了 4 倍 #18028TiFlash 支持同時向本地多塊磁盤併發讀、寫數據，充分利用本地多塊磁盤併發的讀、寫數據的能力，提升性能
高可用和容災
提升 Region 成員變更時的可用性（實驗特性）
Region 在完成成員變更時，由於“添加”和“刪除”成員操作分成兩步，如果此時有故障發生會引起 Region 不可用並且會返回前端業務的錯誤信息。引入的 Raft Joint Consensus 算法，可提升 Region 成員變更時的可用性，將成員變更操作中的“添加”和“刪除”合併爲一個操作，併發送給所有成員。在變更過程中，Region 處於中間的狀態，如果任何被修改的成員失敗，系統仍然可以使用。用戶可通過 pd-ctl config set enable-joint-consensus true 修改成員變量的方式開啓此功能。
優化內存管理模塊，降低系統內存溢出的風險
減少緩存統計信息的內存消耗。
減少使用 Dumpling 工具導出數據時的內存消耗。
通過將數據加密碼的中間結果存儲到磁盤，減少內存消耗。
備份與恢復
BR 支持將數據備份到 AWS S3、Google Cloud GCS（用戶文檔）
BR 支持從 AWS S3、Google Cloud GCS 恢復數據到 TiDB（用戶文檔）
相關 issue：#89
數據的導入和導出
TiDB Lightning 支持從 AWS S3 將 Aurora Snapshot 數據導入 TiDB（相關 issue：#266）
使用 TiDB Lightning 在 DBaaS T1.standard 中導入 1TiB TPCC 數據，性能提升了 40%，由 254 GiB/h 提升到 366 GiB/h
Dumpling 支持將 TiDB/MySQL 數據導出到 AWS S3（實驗特性）（相關 issue：#8，用戶文檔）
問題診斷
優化 EXPLAIN 功能，收集更多的信息，方便 DBA 排查性能問題
DBA 在排查 SQL 語句性能問題時，需要比較詳細的信息來判斷引起性能問題的原因。之前版本中 EXPLAIN 收集的信息不夠完善， DBA 只能通過日誌信息、監控信息或者盲猜的方式來判斷問題的原因，效率比較低。此版本通過以下幾項優化事項提升排查問題效率：
支持對所有 DML 語句使用
EXPLAIN ANALYZE語句以查看實際的執行計劃及各個算子的執行詳情 #18056支持對正在執行的 SQL 語句使用
EXPLAIN FOR CONNECTION語句以查看實時執行狀態，如各個算子的執行時間、已處理的數據行數等 #18233EXPLAIN ANALYZE語句顯示的算子執行詳情中新增算子發送的 RPC 請求數、處理鎖衝突耗時、網絡延遲、RocksDB 已刪除數據的掃描量、RocksDB 緩存命中情況等 #18663慢查詢日誌中自動記錄 SQL 語句執行時的詳細執行狀態，輸出的信息與
EXPLAIN ANALYZE語句輸出信息保持一致，例如各個算子消耗的時間、處理數據行數、發送的 RPC 請求數等 #15009
部署及運維
TiUP 支持將 TiDB Ansible 的配置信息導入到 TiUP。以前導入 Ansible 集羣的時候 TiUP 會將用戶的配置放在
ansible-imported-configs目錄下面。用戶後續修改配置執行tiup cluster edit時，配置編輯界面中不顯示導入的配置，會給用戶造成困擾。現在導入 TiDB Ansible 配置信息的時候 TiUP 不僅會放一份到 ansible-imported-configs 目錄下面，還會導入到tiup cluster edit的配置編輯界面，這樣用戶以後編輯集羣配置時就能夠看到導入的配置了。-
增強
TiUP mirror命令的功能，支持將多個鏡像合併成一個，支持在本地鏡像發佈組件，支持添加組件所有者到本地鏡像 #814金融行業或者大型企業生產環境的變更是一項非常嚴肅的事情，若每個版本都採用光盤安裝一次，用戶使用起來不是很方便。TiUP 提升
merge命令將多個安裝包合併成一個，方便 DBA 安裝部署。在 v4.0 中，用戶發佈自建的鏡像時需要啓動 tiup-server，使用起來不是很方便。在 v5.0 中，執行
tiup mirror set將當前鏡像設置成本地的鏡像就可以方便發佈自建鏡像。