作为开源云原生方案, Zabbix 一直使用 MySQL 作为 后端存储, 在面对更大规模监控需求的时候, 单机 MySQL 数据库面临性能和容量瓶颈, 无法支持几T量级 的数据, 使得监控对象的数量和数据存储时间不能莱得。 TiDB 是兼容 MySQL 协议的分布式数据库, 在易用性与平滑升级方面比其他监控后台数据库方案更有优 势,中国银行决定采用 TiDB 痊换 Zabbix 后端的 MySQL,构建新一代运维监控平台。 o 。 第五章 - 场入案例 ET 一， 33 实际迁移中, PayPay 使用增量的方法逐步增加流量, 实际迁移耗时小于 2 小时, 未出现任何问题,将服务停 机时间降至最低。迁移后经过 3 个多月实际业务的运行考验, TiDB 各项指标均达到预期的目标。 PayPay 新的交易数据库由 TiDB 集群组成, 每个集群包括 PDTiDB 和TiKV 组件, 每个组件都有多个实 栈，大幅降低了电力企业数据中台的建设与维护成本。TiDB 实现了处理与存储能力的弹性扩容，整体 性能表现很好地满足了业务要求，2019 年 10 月至今系统运行平稳，数据量为9 TB，月增长 15TB左 右，时间索引查询 50 毫秒内返回，主键点查小于 ] 毫秒返回。 PingCAP.COM 一 第五章 - 场景案例

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 3520 21 16.2 TiDB 版本发布时间线 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 可以将系统变量tidb_enable_metadata_lock 设置为 OFF。 更多信息，请参考用户文档。 • 支持通过 FLASHBACK CLUSTER TO TIMESTAMP 命令将集群快速回退到特定的时间点 (GA) #37197 #13303 @Defined2014 @bb7133 @JmPotato @Connor1996 @HuSharp @CalvinNeo 32 TiDB v6.4 Garbage Collection (GC) life time 内快速回退整个集群到指定的时间点。该功能在 v6.5.0 新增对 TiCDC 和 PITR 的兼容性支持并正式 GA， 适用于快速撤消 DML 误操作、支持集群分钟级别的快速回退、支持在时间线上多次回退以确定特定数 据更改发生的时间。 更多信息，请参考用户文档。 • 完整支持包含 INSERT、REPLACE、UPDATE 和

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 3721 16.2 TiDB 版本发布时间线 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 间数据操作的物理隔离，并支持平稳管理更多的数据。与原 TiKV 存储引擎相比，使用 Partitioned Raft KV 引擎在相同硬件条件和读写混合场景下，可以实现大约两倍 的写入吞吐并缩短大约 4/5 的弹性扩展时间。 在 TiDB v7.1.0 中，Partitioned Raft KV 引擎支持 TiDB Lightning、BR 和 TiCDC 等工具。 该功能目前是实验特性，不推荐在生产环境中使用。 读取副本，而无需在热点 TiKV 节点排队等待。你可以通过tidb_load_based_replica_read_threshold 系 统变量控制读请求的排队长度。当 leader 节点的预估排队时间超过该阈值时，TiDB 会优先从 follower 节 点读取数据。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70% ～ 200%。 更多信息，请参考用户文档。 • 增强缓存非

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 4018 16.2 TiDB 版本发布时间线 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · （实验特性，从 v7.6.0 开始引入） 在 v7.6.0 中引入了新的 DDL 架构，批量建表的性能提高了 10 倍。 �→ 这一重大改进极大地缩短了创建大量表所需的时间。特别是在 SaaS 场景中，快速创建大量表（ �→ 从数万到数十万不等）是一个常见的挑战，使用该特性能显著提升 SaaS 场景的建表速度。 0 码力 | 4807 页 | 101.31 MB | 1 年前

3

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 4029 16.2 TiDB 版本发布时间线 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 支持微服务模式（实验特性）#5766 @binshi-bing 从 v8.0.0 开始，PD 支持微服务模式。该模式可将 PD 的时间戳分配和集群调度功能拆分为以下微服务单 独部署，从而实现 PD 的性能扩展，解决大规模集群下 PD 的性能瓶颈问题。 – tso 微服务：为整个集群提供单调递增的时间戳分配。 – scheduling 微服务：为整个集群提供调度功能，包括但不限于负载均衡、热点处理、副本修复、副 100 TiB 数据的恢复。 这意味着即使在高负载环境下，BR 工具也能够充分利用每个 TiKV 节点的资源，显著减少数据库恢复时 间，增强数据库的可用性和可靠性，减少因数据丢失或系统故障引起的停机时间和业务损失。需要注 意的是，恢复速度的提升是因为使用了大量的 goroutine 来并行工作，会有比较大的内存消耗，特别是 在表或者 Region 数很多的时候，推荐使用内存规格较高的机器来运行 BR

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 3920 16.2 TiDB 版本发布时间线 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 6/ddl-v2">建表性能提升 10 倍（实验特性） 在 v7.6.0 中引入了新的 DDL 架构，批量建表的性能提高了 10 倍。 �→ 这一重大改进极大地缩短了创建大量表所需的时间。特别是在 SaaS 场景中，快速创建大量表（ �→ 从数万到数十万不等）是一个常见的挑战，使用该特性能显著提升 SaaS 场景的建表速度。 0 码力 | 4666 页 | 101.24 MB | 1 年前

3

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 3865 16.2 TiDB 版本发布时间线 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ADD INDEX 语句 通过该功能，为同一个表添加多个索引的任务可以变为并发运行。以前同时运行 2 个添加索引语句 X 和 �→ Y 需要花费 X 的时间 + Y 的时间，现在在一个 SQL 语句中同时添加索引 X 和 Y，并发运行后， �→ 添加索引总耗时显著减少了。尤其是在宽表的场景， �→ 内部测试数据显示同时添加多个索引的性能最高可提升 94%。 但它并不对每个资源组内的查询产生影响。TiDB v7.2.0 引入了运行超出预期的查询 (Runaway �→ Queries) 时的资源控制功能，你可以控制 TiDB 如何识别和处理每个资源组的查询。根据需要， �→ 长时间运行的查询可能会被终止或节流，你可以通过准确的 SQL 文本、SQL Digest 或 Plan Digest �→ 来识别查询。在 TiDB v7.3.0，你可以主动监视已知的不良查询，类似于数据库级别的

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 945 7.7.4 TiCDC 启动任务的 start-ts 时间戳与当前时间差距较大，任务执行过程中同步中断，出现错误 [CDC:ErrBufferReachLimit]，怎么办？ · · · · · · · · · · · · · · · · · · · · · · 输出变更数据中的时间戳、表名和 库名？· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 954 7.8.16 TiCDC 把数据同步到 Kafka 时，如何确定一条消息中包含的数据变更发生在哪个时间点？ · · 产生的数据变更同步到下游？ · · · · · · · · · · · · · · · · · · · · · · · · · · · · 955 7.8.22 同步 DDL 到下游 MySQL 5.7 时为什么时间类型字段默认值不一致？ · · · · · · · · · · · · · · · · · · · · 956 7.8.23 使用 TiCDC 创建同步任务时将 safe-mode 设置为 true

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 4193 16.2 TiDB 版本发布时间线 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 实例级执行计划缓存允许同一个 TiDB 实例的所有会话共享执行计划缓存。 �→ 与现有的会话级执行计划缓存相比，实例级执行计划缓存能够在内存中缓存更多执行计划，减少 SQL �→ 编译时间，从而降低 SQL 整体运行时间，提升 OLTP 的性能和吞吐，同时更好地控制内存使用， �→ 提升数据库稳定性。 34 TiDB 并行获取 TSO 在高并发场景下，并行获取 TSO 能够有效降低等待获取 TSO 的时间，提升集群的吞吐。 提升缓存表的查询性能

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 4150 24 16.2 TiDB 版本发布时间线 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 倍 #52831 @hawkingrei SaaS 或 PaaS 类业务应用中可能存在大量的数据表，这些表不但会拖慢初始统计信息的加载速度，也会 增加高负载情况下同步负载的失败率。TiDB 的启动时间以及执行计划的准确性都会受到影响。在 v8.2.0 中，TiDB 从并发模型、内存分配方式等多个角度优化了统计信息的加载过程，降低延迟，提升吞吐，避 免由于统计信息加载速度过慢，影响业务扩容。 新 更多信息，请参考用户文档。 2.2.1.5 数据库管理 • TiUP 支持部署 PD 微服务 #5766 @rleungx 37 PD 从 v8.0.0 开始支持微服务模式。该模式通过将 PD 的时间戳分配和集群调度功能拆分为独立的服务进 行部署和管理，可以更好地控制资源的使用和隔离，减少不同服务之间的相互影响。但是，在 v8.2.0 之 前的版本中，PD 微服务仅支持通过 TiDB Operator