TiDB v6.2 发版

TiDB v6.2 于 8 月 23 日发布了。在全新的版本中，TiDB 提供了诸多方面的提升，它们主要集中于：可观测性、性能、稳定性、数据生态加强以及 MySQL 兼容几个领域。

可观测性

在新版本中，TiDB Dashboard 支持了可视化执行计划。以往 TiDB 用只能借助观察文字输出的执行计划排查问题，这对于简单的交易类 SQL 而言问题并不大，但分析型 SQL 很可能会产生庞大的执行计划信息，造成用户难以观察分析。在新版本中，TiDB Dashboard 在 Statements 和 Slow Query 中提供可视化执行计划和基础问题诊断的能力。这是一种全新的查询计划的展示方式，目标是通过图形化的手段展示 Query 查询计划的每个步骤，从而使得用户能够更加直观方便地了解查询执行计划的细节。对于复杂的大型查询语句，可视化的展示方式对于深入理解其执行过程大有裨益。

在这个版本中，TiDB Dashboard 也新增的 Monitoring 页面，展示了在业务性能调优中所需的核心指标，使得用户大部分的日常运维监控需求可以在这里完成，无需在 Grafana 和 Dashboard 间跳转。

除此之外，新版本中 TiDB 锁视图支持乐观事务被阻塞的信息。大量锁冲突往往会造成严重的性能问题，而锁冲突定位是这类性能问题排查的必要手段之一。TiDB v6.2.0 之前版本支持通过系统视图 INFORMATION_SCHEMA.DATA_LOCK_WAITS 查看锁冲突关系，但是不支持乐观事务被悲观锁阻塞的情况。TiDB v6.2.0 扩展了 DATA_LOCK_WAITS 视图，提供乐观事务被悲观锁阻塞情况下的冲突关系，可以帮助用户快速定位锁冲突，同时为业务改进提供依据，从而减少这类锁冲突的发生频率，提升系统整体性能。

性能

在新版本中 TiDB HTAP 性能有进一步提升。

首先，TiFlash 在 6.2.0 中引入了新的存储格式 PageStore V3。该格式大幅减轻了在高并发、高负载场景下 GC 造成 CPU 占用高的问题，可以有效减少后台任务 IO 流量，提升高并发、高负载下的稳定性。6.2.0 版本默认以新版本存储格式保存数据。

在计算引擎方面，TiFlash 通过实现细粒度数据交换（shuffle）使窗口函数 （Window function） 可以利用多线程并行计算，成倍降低查询响应时间，使其在典型场景下可提速 4～5 倍。而在去重计算 COUNT(DISCINT) 中，分析引擎通过降低数据倾斜优化了计算效率。

除了分析场景，新版本中引入新的 DDL 并行执行框架，在不同表对象上的 DDL 可以并发执行，解决了之前不同表之间 DDL 相互阻塞的问题。同时在不同表对象的追加索引、列类型变更等场景下支持并行执行，大幅提升执行效率。

除了分析场景，新版本中引入新的 DDL 并行执行框架，在不同表对象上的 DDL 可以并发执行，解决了之前不同表之间 DDL 相互阻塞的问题。同时在不同表对象的追加索引、列类型变更等场景下支持并行执行，大幅提升执行效率。

稳定性

除了性能加强，V6.2 也包含了重要的稳定性加固。

TiKV 在新版本中支持自适应调整 CPU 使用率。数据库通常会使用后台进程来执行一些内部操作，通过采集各种统计信息，帮助用户定位性能问题，生成更优的执行计划，从而提升数据库的稳定性和性能。然而如何平衡后台操作和前台操作的资源开销，在不影响用户日常数据库使用的基础上如何更高效地采集信息，一直是数据库领域最为头疼的问题之一。从 v6.2.0 开始，TiDB 支持通过 TiKV 配置文件设置后台请求的 CPU 使用率, 进而限制自动统计信息收集等后台操作在 TiKV 的 CPU 使用比例，避免极端情况下后台操作抢占对用户操作的资源，确保数据库稳定高效运行。同时 TiDB 还支持 CPU 使用率自动调节的功能, 这时 TiKV 会根据实例的 CPU 占用情况, 自适应地对后台请求占用的 CPU 资源进行动态调整。该功能默认关闭。

而 TiFlash 则加固了在处理大量数据的场景。在新版本中，通过减少分布式事务处理的内存放大（memory amplification），TiFlash 大幅降低了内存消耗，相较于 v6.1 之前版本最好的情况下内存使用峰值可降低 50% 以上，从而减少了大规模分析场景下不同任务内存资源冲突问题出现的可能性。

数据生态加强

在新版本中，最重要的数据生态功能是支持 Point-in-Time Recovery (PiTR)。PiTR 指的是允许用户在新集群上恢复备份集群的历史任意时刻点的快照。从技术而言，PiTR 是基于变更日志和快照数据共同进行的数据备份和恢复。该功能可以满足以下的用户需求：

降低备份恢复在灾备场景下的 RPO，如实现十几分钟的 RPO； 用于处理业务数据写错的案例，如回滚业务数据到出错事件前； 业务历史数据审计，满足行业合规的需求。

针对数据导入场景，TiDB Lightning 优化并减小了导入对集群带来的性能影响。TiDB Lightning 原有的物理导入模式 (backend=local) 对目标集群影响较大，例如导入过程将停止 PD 调度等，因此仅适用于目标集群初次导入数据。新版本中，TiDB Lightning 在现有基础上做了改进，导入时影响范围由集群级别降低到表级别，即非导入的表仍可进行读写操作。

除此之外，BR 现在已支持恢复用户和权限数据，这使得备份恢复体验变得更平滑，用户不再需要在集群恢复之后单独处理用户和权限信息。

最后，TiCDC 加入了 DDL 过滤机制。自 v6.2 起，TiCDC 支持过滤指定类型的 DDL 事件，支持基于 SQL 表达式过滤 DML 事件，从而适应更多的数据同步场景。例如在一些特殊的场景下，用户可能希望对 TiDB 增量数据变更日志进行一定规则的过滤，例如过滤 Drop Table 等高风险 DDL。

MySQL 兼容

在 MySQL 兼容的道路上，TiDB 在 v6.2 加入了 SAVEPOINT 机制以及单 ALTER TABLE 语句增删改多个列或索引。

先说说 SAVEPOINT。事务是数据库保证 ACID 特性的一系列连续操作的逻辑集合。在一些复杂业务场景下，你可能需要管理一个事务的大量操作，有时候需要在事务内实现部分操作的回退能力。SAVEPOINT 就是针对事务内部实现的可命名保存点机制，通过这个机制，你可以灵活地控制事务内的回退节点，从而实现更复杂的事务管理能力，实现更为多样的业务设计。

然后是 ALTER TABLE 操作多列和多索引。之前版本中，TiDB 仅支持单一 DDL 变更，导致用户在迁移异构数据库时经常会遇见 DDL 操作不兼容的情况，需要耗费额外的精力将复杂的 DDL 修改成 TiDB 支持的多个简单 DDL。同时还有一些用户依赖 ORM 框架，实现 SQL 组装，最终出现了 SQL 不兼容等问题。TiDB 从 v6.2.0 开始，支持使用 ALTER TABLE 语句修改一个表的多个模式对象，方便了用户 SQL 实现，也提升了产品易用性。

查看 TiDB 6.2.0 Release Notes ，立即 下载试用 ，开启 TiDB 6.2.0 企业级数据库之旅。