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