TiDB Cloud v8.5.0 性能亮点

TiDB v8.5.0 是一个重要的长期支持（LTS）版本，在性能、扩展性和运维效率方面带来了显著提升。

本文档将从以下几个方面介绍 v8.5.0 的性能提升：

• 通用性能
• 多版本并发控制（MVCC）版本过多导致的热点读
• IO 延时抖动
• 批量处理
• TiKV 扩展性能

通用性能

在 v8.5.0 版本中，默认 Region 大小从 96 MiB 增加到 256 MiB，并结合其他多项优化，带来了显著的性能提升：

• oltp_insert 性能提升 27%。
• Analyze 性能大幅提升，约为 45%。

多版本并发控制（MVCC）版本过多导致的热点读

挑战

在部分用户场景下，可能会遇到如下挑战：

• 版本频繁更新：在某些负载下，数据被频繁地修改和读取。
• 历史版本保留时间过长：为满足业务需求（如支持回溯到指定时间点），用户可能会配置过长的 GC（垃圾回收）时间（如 24 小时），导致多版本并发控制（MVCC）版本大量堆积，极大降低查询效率。

MVCC 版本的堆积会导致请求数据与实际处理数据之间的差距变大，从而导致读性能下降。

解决方案

为解决该问题，TiKV 引入了 In-Memory Engine (IME)。通过将最新版本缓存到内存中，TiKV 降低了历史版本对读性能的影响，显著提升查询效率。

测试环境

• 集群拓扑结构：TiDB（16 vCPU，32 GiB）* 1 + TiKV（16 vCPU，32 GiB）* 6

• 集群配置：

  tikv_configs:
  [in-memory-engine]
  enable = true
  

• 数据集：24 GiB 存储空间，约 340 个 Region，包含频繁更新的数据

• 负载：需要扫描的行包含大量由频繁更新引入的 MVCC 版本

测试结果

查询延时降低 50%，吞吐提升 100%。

IO 延时抖动

挑战

在云环境中，云盘的瞬时或持续 IO 延时波动是常见挑战。这些波动会增加请求延时，导致超时、报错，影响正常业务，最终降低服务质量。

解决方案

TiDB v8.5.0 引入了多项增强，缓解云盘 IO 抖动对性能的影响：

• Leader 写入优化：允许 Leader 提前应用已提交但尚未持久化的 Raft 日志，降低 IO 抖动对 Leader 副本写入延时的影响。

• 慢节点检测增强：优化慢节点检测算法，默认开启慢分数检测。当检测到慢节点时，触发 evict-leader 调度器以恢复性能。慢节点检测机制 使用 evict-slow-store-scheduler 检测和管理慢节点，降低云盘抖动影响。

• 统一健康控制器：在 TiKV 中新增统一健康控制器，并在 KV 客户端增加反馈机制。KV 客户端可根据 TiKV 节点健康和性能优化错误处理和副本选择。

• 改进副本选择器：KV 客户端引入 Replica Selector V2，优化状态切换，消除不必要的重试和退避操作。

• 其他修复与改进：包括 region cache、KV 客户端健康检查器等关键组件的优化，同时避免 TiKV store loop 中不必要的 IO 操作。

测试环境

• 集群拓扑结构：TiDB（32 vCPU，64 GiB）* 3 + TiKV（32 vCPU，64 GiB）* 6
• 负载：读写比为 2:1，在一个 TiKV 节点上模拟云盘 IO 延迟或假死

测试结果

基于上述测试设置，在多种 IO 延迟场景下，故障切换能力得到提升，受影响期间的 P99/P999 延时最高降低 98%。

下表中，Current 列为引入 IO 延时抖动优化后的结果，Original 列为未优化前的结果：

进一步优化建议

磁盘抖动的严重程度也与用户的负载特征密切相关。在对延时敏感的场景下，结合 TiDB 特性进行应用设计，可进一步降低 IO 抖动对应用的影响。例如，在读多且对延时敏感的环境下，可以根据延时需求调整 tikv_client_read_timeout 系统变量，并结合使用 Stale Read 或 Follower Read，使 TiDB 发起的 KV 请求能更快地切换到其他副本重试，从而降低单个 TiKV 节点 IO 抖动对查询延时的影响。需要注意的是，该特性的效果依赖于具体负载特征，建议在实施前进行评估。

此外，用户在公有云部署 TiDB时，可以选择更高性能的云盘，以降低抖动发生概率。

批量处理

挑战

大规模事务（如批量数据更新、系统迁移、ETL 工作流）通常涉及数百万行处理，是支撑关键业务的核心能力。虽然 TiDB 作为分布式 SQL 数据库具备良好扩展性，但在大规模事务处理时面临两大挑战：

• 内存限制：在 TiDB v8.1.0 之前，所有事务变异都需在整个事务生命周期内驻留于内存，资源压力大，性能下降。对于数百万行的操作，可能导致内存占用过高，甚至在资源不足时出现 OOM（内存溢出）错误。

• 性能下降：大内存缓冲区依赖红黑树实现，带来计算开销。随着缓冲区增大，操作速度因数据结构的 O(N log N) 复杂度而变慢。

解决方案

这些挑战为提升扩展性、降低复杂度、增强可靠性提供了明确的优化空间。随着现代数据负载的增长，TiDB 引入了 Pipelined DML 特性，专为优化大事务处理、提升资源利用率和整体性能而设计。

测试环境

• 集群拓扑结构：TiDB（16 vCPU，32 GiB）* 1 + TiKV（16 vCPU，32 GiB）* 3
• 数据集：YCSB 非聚簇表，1,000 万行（约 10 GiB 数据）。部分测试中有选择性地移除主键，以隔离并评估热点模式影响。
• 负载：DML 操作，包括 INSERT、UPDATE 和 DELETE。

测试结果

执行速度提升 2 倍，TiDB 最大内存占用降低 50%，TiKV 写入流量更加平滑。

• 延时（秒）

  负载（10 GiB）	标准 DML	Pipelined DML	提升幅度
  YCSB-insert-10M	368	159	131.45%
  YCSB-update-10M	255	131	94.66%
  YCSB-delete-10M	136	42	223.81%

• TiDB 内存使用峰值（GiB）

  负载（10 GiB）	标准 DML	Pipelined DML	降低幅度
  YCSB-insert-10M	25.8	12	53.49%
  YCSB-update-10M	23.1	12.9	44.16%
  YCSB-delete-10M	10.1	8.08	20.00%

TiKV 扩展性能

挑战

横向扩展是 TiKV 的核心能力，支持系统按需扩容或缩容。随着业务增长和租户数量增加，TiDB 集群中的数据库、表和数据量迅速增长，TiKV 节点扩容成为保障服务质量的关键。

在某些场景下，TiDB 承载大量数据库和表。当这些表较小或为空时，TiKV 会积累大量小 Region，尤其当表数量达到百万级及以上时。这些小 Region 带来较大维护负担，增加资源开销，降低效率。

解决方案

为解决上述问题，TiDB v8.5.0 优化了小 Region 合并性能，降低内部开销，提高资源利用率。此外，v8.5.0 还包含多项其他优化，进一步提升 TiKV 扩展性能。

测试环境

小 Region 合并

• 集群拓扑结构：TiDB（16 vCPU，32 GiB）* 1 + TiKV（16 vCPU，32 GiB）* 3
• 数据集：近 100 万张小表，每张表大小 < 2 MiB
• 负载：自动合并小 Region

TiKV 节点扩容

• 集群拓扑结构：TiDB（16 vCPU，32 GiB）* 1 + TiKV（16 vCPU，32 GiB）* 4
• 数据集：TPC-C 数据集，包含 20,000 个仓库
• 负载：TiKV 节点从 4 扩容到 7

测试结果

小 Region 合并速度提升约 10 倍。

TiKV 扩展性能提升超过 40%，节点扩容耗时降低 30%。

基准测试

除上述测试数据外，你还可以参考以下 v8.5.0 性能基准测试结果：

• TPC-C 性能测试报告
• Sysbench 性能测试报告