TiDB 7.2 版本发布：更加流畅的操作体验

关系型数据库管理系统（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) 加载数据。

有关更多信息，请参考文档。ReleaseTiDB

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。