--- title: 'TiDB 7.2 – 更平滑的操作体验' date: '2023-07-19T00:00:00+08:00' status: publish permalink: /blog/tidb-7-2-release author: - PingCAP - PingCAP - PingCAP excerpt: 'TiDB 7.2 致力于简化数据管理，引入了暂停和恢复 DDL 操作、资源组控制查询影响以及将 TiDB Lightning 导入服务整合到 TiDB 中的功能。' type: post id: 3233 category: - 产品技术解读 tag: - Release - TiDB post_format: [] profile: - PingCAP algolia_posts_post_records_count: - '2' --- 关系型数据库管理系统（RDBMS）的世界正在发生变化，分布式架构和大数据规模下的一致性比以往任何时候都更加必要。分布式SQL引擎的创造者和维护者面临着提供易用性的新范式。虽然 PingCAP 一直将此作为首要任务，但 TiDB 7.2 则直接致力于使 TiDB 数据的管理更加容易。 *版本 7.2 是一个开发里程碑版本（DMR），旨在引入实验性功能，因此不适用于生产环境。对于生产部署，请参考我们最新的稳定版本（LTS）7.1，以及[相应的博客](/blog/tidb-7.1-release)。* 与所有 TiDB 发布博客一样，本文专注于版本发布的主要功能亮点。有关版本的更全面信息，请参阅文档中的官方[发布说明](https://docs.pingcap.com/zh/tidb/v7.2/release-7.2.0)。 暂停和恢复 DDL 以优先处理关键流量 ------------------- 在前序版本中，TiDB 极大提高了 DDL 尤其是添加索引的速度。即便如此，构建索引仍然是数据库相对最为昂贵的操作之一。在线 Schema 变更使得 TiDB 的用户可以不用因此暂停业务，但数据重组的在线性质可能会对前台工作负载产生影响，尤其是对延迟和抖动敏感度高的在线业务：数据规模越大，耗时越长，您的在线流量暴露的风险就越高。虽然用户可以通过限制并发度来减少对前台流量的干扰。然而，即使如此，仍然可能会出现资源干扰的情况。 为了解决这类问题，TiDB 7.2 引入了在 DDL 操作暂停能力：用户可以暂停正在进行的 DDL 操作，并在合适的时机恢复操作。 总体而言，这使 DDL 操作能够在大规模数据重组对性能的影响提供了手动干预的手段，并且无需重新启动操作而因此丢失 DDL 操作进度。 通过资源组控制不良查询的影响 -------------- 在最新的[稳定版本 7.1 ](/blog/tidb-7.1-release)中，通过资源组实现资源控制的功能正式 GA。该功能的目的是在同一集群上保持多个独立工作负载的性能稳定。该功能的底层机制也正好适用于一些可操作性的增强。 TiDB 7.2 基于执行时间引入了基于[资源组](https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control)的全局查询超时概念，并将该控制功能提升到资源组的层面，使其更加细粒度。现在，归类为业务逻辑组的查询可以拥有自己的超时设置，避免了在集群中为所有工作负载和查询组确定“一刀切”的超时时间的需求。 从远程对象存储中导入到 TiDB ---------------- 如果您是当前的 TiDB 用户，您可能已经熟悉导入服务 [TiDB Lightning](https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview)。它是一个独立的服务，具备完整的导入功能，可以通过事务层逻辑方式和通过文件系统直接进行物理导入数据。 为了使从其他来源加载数据更简单，并且避免用户需要部署这个独立的服务，TiDB 7.2 将 Lightning 的物理导入服务整合到 TiDB 本身中。通过直接整合到 TiDB 中，不仅部署变得更简单，而且还为管理数据加载提供了一个 SQL 接口。在这里包含 Lightning 的功能还意味着可以直接从 AWS S3 和 Google Cloud Storage (GCS) 加载数据。 有关更多信息，请[参考文档](https://docs.pingcap.com/zh/tidb/v7.2/release-7.2.0)。