TiDB 7.1.0发布

TiDB 版本：7.1.0

试用链接：快速体验 | 生产部署 | 下载离线包

TiDB 7.1.0 为长期支持版本 (Long-Term Support Release, LTS)。

相比于前一个 LTS（即 6.5.0 版本），7.1.0 版本包含 6.6.0-DMR 和 7.0.0-DMR 中已发布的新功能、提升改进和错误修复，并引入了以下关键特性：

功能详情

性能

• 增强分区 Raft KV 存储引擎（实验特性）#11515 #12842 @busyjay @tonyxuqqi @tabokie @bufferflies @5kbpers @SpadeA-Tang @nolouch

  TiDB v6.6.0 引入了分区 Raft KV 存储引擎作为实验特性，该引擎使用多个 RocksDB 实例存储 TiKV 的 Region 数据，每个 Region 的数据都独立存储在单独的 RocksDB 实例中。分区 Raft KV 能够更好地控制 RocksDB 实例的文件数和层级，实现 Region 间数据操作的物理隔离，并支持平稳管理更多的数据。与原 TiKV 存储引擎相比，使用分区 Raft KV 引擎在相同硬件条件和读写混合场景下，可以实现大约两倍的写入吞吐并缩短大约 4/5 的弹性扩展时间。

  在 TiDB v7.1.0 中，分区 Raft KV 引擎与 TiFlash 兼容，并支持 TiDB Lightning、BR 和 TiCDC 等工具。

  该功能目前是实验特性，不推荐在生产环境中使用。目前仅支持在新集群中使用新引擎，暂不支持从原 TiKV 存储引擎直接升级到该引擎。

  更多信息，请参考用户文档。

• TiFlash 查询支持延迟物化功能 (GA) #5829 @Lloyd-Pottiger

  在 v7.0.0 中，TiFlash 引入了延迟物化实验特性，用于优化查询性能。该特性默认关闭（系统变量 tidb_opt_enable_late_materialization 默认为 OFF）。当 SELECT 语句中包含过滤条件（WHERE 子句）时，TiFlash 默认会先读取该查询所需列的全部数据，然后再根据查询条件对数据进行过滤、聚合等计算任务。开启该特性后，TiFlash 支持下推部分过滤条件到 TableScan 算子，即先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。

  从 v7.1.0 开始，TiFlash 延迟物化功能正式 GA，默认开启（系统变量 tidb_opt_enable_late_materialization 默认为 ON），TiDB 优化器会根据统计信息和查询的过滤条件，决定哪些过滤条件会被下推到 TableScan 算子。

  更多信息，请参考用户文档。

• TiFlash 支持根据网络交换数据量自动选择 MPP 模式的 Join 算法 #7084 @solotzg

  TiFlash MPP 模式有多种 Join 算法。在 v7.1.0 之前的版本中，TiDB 根据变量 tidb_broadcast_join_threshold_count 和 tidb_broadcast_join_threshold_size 以及实际数据量决定 TiFlash MPP 模式是否使用 Broadcast Hash Join 算法。

  在 v7.1.0 中，TiDB 引入变量 tidb_prefer_broadcast_join_by_exchange_data_size，控制是否基于最小网络数据交换策略选择 MPP Join 算法。该变量默认关闭，表示默认保持 v7.1.0 之前的算法选择策略。如需开启，请设置该变量为 ON。开启后，你无需再手动调整 tidb_broadcast_join_threshold_count 和 tidb_broadcast_join_threshold_size 的阈值（此时这两个变量将不再生效），TiDB 会自动估算不同 Join 算法所需进行网络交换的数据量，然后选择综合开销较小的算法，从而减少网络流量，提升 MPP 查询性能。

  更多信息，请参考用户文档。

• 支持自适应副本读取缓解读热点 #14151 @sticnarf @you06

  在读热点场景中，热点 TiKV 无法及时处理读请求，导致读请求排队。但是，此时并非所有 TiKV 资源都已耗尽。为了降低延迟，TiDB v7.1.0 引入了负载自适应副本读取功能，允许从其他有可用资源的 TiKV 节点读取副本，而无需在热点 TiKV 节点排队等待。你可以通过 tidb_load_based_replica_read_threshold 系统变量控制读请求的排队长度。当 leader 节点的预估排队时间超过该阈值时，TiDB 会优先从 follower 节点读取数据。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。

  更多信息，请参考用户文档。

• 增强缓存非 Prepare 语句执行计划的能力（实验特性）#36598 @qw4990

  TiDB v7.0.0 引入了非 Prepare 语句的执行计划缓存作为实验特性，以提升在线交易场景的并发处理能力。在 v7.1.0 中，TiDB 继续增强非 Prepare 语句执行计划，支持缓存更多模式的 SQL。

  为了提升内存利用率，TiDB v7.1.0 将非 Prepare 与 Prepare 语句的缓存池合并。你可以通过系统变量 tidb_session_plan_cache_size 设置缓存大小。原有的系统变量 tidb_prepared_plan_cache_size 和 tidb_non_prepared_plan_cache_size 被废弃。

  为了保持向前兼容，从旧版本升级到 v7.1.0 时，缓存池大小 tidb_session_plan_cache_size 的值与 tidb_prepared_plan_cache_size 保持一致，tidb_enable_non_prepared_plan_cache 保持升级前的设置。经过性能测试后，你可通过 tidb_enable_non_prepared_plan_cache 开启非 Parepare 语句的执行计划缓存功能。

  非 Prepare 语句执行计划缓存默认不支持 DML 语句，若要启用支持，你可以将 tidb_enable_non_prepared_plan_cache_for_dml 系统变量设置为 ON。

  更多信息，请参考用户文档。

• DDL 支持分布式并行执行框架（实验特性）#41495 @benjamin2037

  TiDB v7.1.0 之前的版本中，在同一时间只有一个 TiDB 节点能够担任 DDL Owner 并执行 DDL 任务。从 TiDB v7.1.0 开始，在新的分布式并行执行框架下，多个 TiDB 节点可以并行执行同一项 DDL 任务，从而更好地利用 TiDB 集群的资源，大幅提升 DDL 的性能。此外，你还可以通过增加 TiDB 节点来线性提升 DDL 的性能。需要注意的是，该特性是实验性特性，目前仅支持 ADD INDEX 操作。

  如果要使用分布式并行执行框架，只需将 tidb_enable_dist_task 的值设置为 ON：

  SET GLOBAL tidb_enable_dist_task = ON;

  更多信息，请参考用户文档。

稳定性

• 资源管控成为正式功能 (GA) #38825 @nolouch @BornChanger @glorv @tiancaiamao @Connor1996 @JmPotato @hnes @CabinfeverB @HuSharp

  TiDB 持续增强资源管控能力，在 v7.1.0 该功能正式 GA。该特性将极大地提升 TiDB 集群的资源利用率和性能表现。资源管控特性的引入对 TiDB 具有里程碑的意义，你可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据实际需求设置每个资源组的配额。当集群资源紧张时，同一资源组内的会话所使用的全部资源将受到配额限制，防止某一资源组的过度消耗对其他资源组的会话造成影响。

  该特性也可以将多个来自不同系统的中小型应用整合到同一个 TiDB 集群中。即使某个应用的负载增加，也不会影响其他应用的正常运行。而在系统负载较低的时候，繁忙的应用即使超出设定的配额，仍可获得所需系统资源，实现资源的最大化利用。此外，合理利用资源管控特性可以减少集群数量，降低运维难度及管理成本。

  在 TiDB v7.1.0 中，该特性增加了基于实际负载和硬件部署来估算系统容量上限的能力，为你进行容量规划提供更准确的参考。这有助于你更好地管理 TiDB 的资源分配，从而满足企业级场景的稳定性需求。

  为了更好的用户体验，TiDB Dashboard 增加了资源管控的管理页面。你可以在该页面查看资源组配置，并通过可视化的方式进行容量预估，便于合理配置资源。

  更多信息，请参考用户文档。

• 支持 Fast Online DDL 的检查点机制，提升容错性和自动恢复能力 #42164 @tangenta

  TiDB v7.1.0 引入 Fast Online DDL 的检查点机制，可以大幅提升 Fast Online DDL 的容错性和自动恢复能力。即使 TiDB owner 因故障重启或者切换，TiDB 也能够通过自动定期保存的检查点恢复部分进度，从而让 DDL 执行更加稳定高效。

  更多信息，请参考用户文档。

• BR 备份恢复工具支持断点恢复 #42339 @Leavrth

  快照恢复或日志恢复会因为一些可恢复性错误导致提前结束，例如硬盘空间占满、节点宕机等突发情况。在 TiDB v7.1.0 之前，即使错误被及时处理，之前恢复的进度也会作废，你需要重新进行恢复。对大规模集群来说，会造成大量额外成本。

  为了尽可能继续上一次的恢复，从 TiDB v7.1.0 起，备份恢复特性引入了断点恢复的功能。该功能可以在意外中断后保留上一次恢复的大部分进度。

  更多信息，请参考用户文档。

• 优化统计信息缓存加载策略 #42160 @xuyifangreeneyes

  TiDB v7.1.0 引入了轻量级的统计信息初始化功能作为实验特性。轻量级的统计信息初始化可以大幅减少启动时必须加载的统计信息的数量，从而提升启动过程中统计信息的加载速度。该功能提升了 TiDB 在复杂运行环境下的稳定性，并降低了部分 TiDB 节点重启对整体服务的影响。你可以通过修改 TiDB 配置参数 lite-init-stats 为 true 来开启该特性。

  在 TiDB 启动阶段，如果在初始统计信息加载完成之前执行 SQL，可能会产生不合理的执行计划，进而造成性能问题。为了避免这种情况，TiDB v7.1.0 引入了配置项 force-init-stats。你可以控制 TiDB 是否在统计信息初始化完成后再对外提供服务。该配置项默认关闭。

  更多信息，请参考用户文档。

• TiCDC 支持单行数据正确性校验功能 #8718 #42747 @3AceShowHand @zyguan

  从 v7.1.0 开始，TiCDC 引入了单行数据正确性校验功能。该功能基于 Checksum 算法对单行数据的正确性进行校验，可以校验一行数据从 TiDB 写入、通过 TiCDC 同步，到写入 Kafka 集群的过程中是否出现错误。TiCDC 数据正确性校验功能仅支持下游是 Kafka 的 Changefeed，目前支持 Avro 协议。

  更多信息，请参考用户文档。

• TiCDC 优化 DDL 同步操作 #8686 @hi-rustin

  在 v7.1.0 之前，当用户在一个大表上进行 DDL 操作时，如果 DDL 操作影响该表中的所有行（例如添加或删除列），TiCDC 的同步延迟会显著增加。从 v7.1.0 开始，TiCDC 对此进行了优化，减轻 DDL 操作对下游延迟的影响。

  更多信息，请参考用户文档。

• 提升 TiDB Lightning 导入 TiB 级别数据时的稳定性 #43510 #43657 @D3Hunter @lance6716

  从 v7.1.0 开始，TiDB Lightning 增加了四个配置项，可以提升在导入 TiB 级数据时的稳定性。

  • tikv-importer.region-split-batch-size 用于控制批量 split Region 时的 Region 个数，默认值为 4096。
  • tikv-importer.region-split-concurrency 用于控制 Split Region 时的并发度，默认值为 CPU 核心数。
  • tikv-importer.region-check-backoff-limit 用于控制 split 和 scatter 操作后等待 Region 上线的重试次数，默认值为 1800。重试符合指数回退策略，最大重试间隔为 2 秒。若两次重试之间有任何 Region 上线，该次操作不会被计为重试次数。
  • tikv-importer.pause-pd-scheduler-scope 控制 TiDB Lightning 暂停 PD 调度的范围。默认值为 "table"，可选值为 "table" 和 "global"。对于 TiDB v6.1.0 之前的版本，只能配置 "global" 选项，即导入数据过程中暂停全局调度。从 v6.1.0 开始，支持 "table" 选项，表示仅暂停目标表数据范围所在 Region 的调度。建议在数据量较大的场景将该配置项设置为 "global"，以提升稳定性。

  更多信息，请参考用户文档。

SQL 功能

• 支持通过 INSERT INTO SELECT 语句保存 TiFlash 查询结果 (GA) #37515 @gengliqi

  从 v6.5.0 起，TiDB 支持下推 INSERT INTO SELECT 语句中的 SELECT 子句（分析查询）到 TiFlash，你可以将 TiFlash 的查询结果方便地保存到 INSERT INTO 指定的 TiDB 表中供后续分析使用，起到了结果缓存（即结果物化）的效果。

  在 v7.1.0 版本中，该功能正式 GA。当 TiDB 执行 INSERT INTO SELECT 语句中的 SELECT 子句时，优化器将根据 SQL 模式及 TiFlash 副本的代价估算自行决定是否将查询下推至 TiFlash。因此，在实验特性阶段引入的系统变量 tidb_enable_tiflash_read_for_write_stmt 将被废弃。需要注意的是，TiFlash 对于 INSERT INTO SELECT 语句的计算规则不满足 STRICT SQL Mode 要求，因此只有当前会话的 SQL 模式为非严格模式（即 sql_mode 值不包含 STRICT_TRANS_TABLES 和 STRICT_ALL_TABLES），TiDB 才允许将 INSERT INTO SELECT 语句中的 SELECT 子句下推至 TiFlash。

  更多信息，请参考用户文档。

• MySQL 兼容的多值索引 (Multi-Valued Index) 成为正式功能 (GA) #39592 @xiongjiwei @qw4990 @YangKeao

  过滤 JSON 列中某个数组的值是一种常见操作，但使用普通索引无法加速此过程。在数组上创建多值索引可以大幅提升过滤性能。如果 JSON 列中的某个数组上存在多值索引，则函数 MEMBER OF()、JSON_CONTAINS() 和 JSON_OVERLAPS() 的检索条件可以利用该多值索引进行过滤，从而减少大量的 I/O 消耗，提升执行速度。

  在 v7.1.0 中，TiDB 多值索引成为正式功能 (GA)，支持更完整的数据类型，并与 TiDB 的工具链兼容。你可以在生产环境利用多值索引来加速对 JSON 数组的检索操作。

  更多信息，请参考用户文档。

• 完善 Hash 分区表和 Key 分区表的分区管理功能 #42728 @mjonss

  在 v7.1.0 之前，TiDB 中的 Hash 分区表和 Key 分区表只支持 TRUNCATE PARTITION 分区管理。从 v7.1.0 开始，Hash 分区表和 Key 分区表新增支持 ADD PARTITION 和 COALESCE PARTITION 分区管理。你可以根据需要灵活调整 Hash 分区表和 Key 分区表的分区数量。例如，通过 ADD PARTITION 语句增加分区数量，或通过 COALESCE PARTITION 语句减少分区数量。

  更多信息，请参考用户文档。

• Range INTERVAL 分区定义语法成为正式功能 (GA) #35683 @mjonss

  在 v6.3.0 中引入的 Range INTERVAL 的分区定义语法成为正式功能 (GA)。通过该语法，你可以根据所需的间隔 (interval) 定义 Range 分区，不需要枚举所有分区，可大幅度缩短 Range 分区表的定义语句长度。语义与原有 Range 分区等价。

  更多信息，请参考用户文档。

• 生成列 (Generated Columns) 成为正式功能 (GA) @bb7133

  生成列是数据库中非常有价值的一个功能。在创建表时，可以定义一列的值由表中其他列的值计算而来，而不是由用户显式插入或更新。这个生成列可以是虚拟列 (Virtual Column) 或存储列 (Stored Column)。TiDB 在早期版本就提供了与 MySQL 兼容的生成列功能，在 v7.1.0 中这个功能正式 GA。

  使用生成列可以提升 TiDB 对 MySQL 的兼容性，方便从 MySQL 平滑迁移到 TiDB，同时也能简化数据维护复杂度，增强数据一致性并提高查询效率。

  更多信息，请参考用户文档。

数据库管理

• 支持无需手动取消 DDL 的平滑升级集群功能 #39751 @zimulala

  在 TiDB v7.1.0 之前的版本中，升级集群时需要先手动取消正在运行或排队的 DDL 任务，并在升级完成后再手动添加这些任务。

  为了提供更平滑的升级体验，TiDB v7.1.0 引入了自动暂停和恢复 DDL 任务的功能。从 v7.1.0 开始，你在升级集群前无需手动取消 DDL 任务。系统会自动暂停正在执行或排队的用户 DDL 任务，等待整个集群完成滚动升级后再自动恢复这些任务，让你可以更加轻松地升级 TiDB 集群。

  更多信息，请参考用户文档。

可观测性

• 增加优化器诊断信息 #43122 @time-and-fate

  获取充足的信息是 SQL 性能诊断的关键。在 v7.1.0 中，TiDB 持续为各种诊断工具增加优化器运行信息，以便更好地解释执行计划如何被选择，从而协助定位 SQL 性能问题。这些信息包括：

  • 在 PLAN REPLAYER 的输出中增加 debug_trace.json 文件。
  • 在 EXPLAIN 的输出中为 operator info 添加部分统计信息详情。
  • 为慢日志的 Stats 字段添加部分统计信息详情。

  更多信息，请参考使用 PLAN REPLAYER 保存和恢复集群线程信息、使用 EXPLAIN 解读执行计划和慢日志查询。

安全

• 更换 TiFlash 系统表信息的查询接口 #6941 @flowbehappy

  从 v7.1.0 起，TiFlash 在向 TiDB 提供 INFORMATION_SCHEMA.TIFLASH_TABLES 和 INFORMATION_SCHEMA.TIFLASH_SEGMENTS 系统表的查询服务时，不再使用 HTTP 端口，而是使用 gRPC 端口，从而避免 HTTP 服务的安全风险。

• 支持 LDAP 身份认证 #43580 @YangKeao

  从 v7.1.0 起，TiDB 支持 LDAP 身份认证，并提供了两种认证插件：authentication_ldap_sasl 和 authentication_ldap_simple。

  更多信息，请参考用户文档。

• 增强数据库审计功能（企业版）

  在 v7.1.0 中，TiDB 企业版增强了数据库审计功能，大幅提升了能力范围，改善了使用体验，以满足企业对数据库安全合规的需要：

  • 引入“过滤器” (Filter) 与“规则” (Rule) 的概念，提供了更细分的审计事件定义，并支持更细粒度的审计设置。
  • 支持 JSON 格式的规则定义，提供了更加友好的设置方式。
  • 新增自动日志轮替 (Log Rotation) 和空间管理功能，支持保存时间和日志大小两个维度的设置。
  • 支持输出 TEXT 和 JSON 两种格式的审计日志，便于集成第三方工具。
  • 支持日志内容脱敏，可以替换所有字面值以增强安全性。

  数据库审计是 TiDB 企业版的重要功能之一，为企业提供了强大的监管和审计工具，以保证数据安全和合规性。TiDB 企业版的数据库审计功能可以帮助企业管理人员追踪数据库操作的来源和影响，确保数据不被非法窃取或篡改。同时，数据库审计还可以帮助企业遵守各种法规和合规要求，确保企业在法律和道德方面的合规性。该功能对企业信息安全具有非常重要的应用价值。

  该功能为企业版特性，要获取数据库审计功能及其文档，请在 TiDB 产品页面企业版区域点击立即咨询联系 PingCAP。

兼容性变更

行为变更

• 为了提高安全性，TiFlash 废弃了 HTTP 服务端口（默认 8123），采用 gRPC 端口作为替代

  如果你已经将 TiFlash 升级到 v7.1.0，那么在升级 TiDB 到 v7.1.0 的过程中，TiDB 无法读取 TiFlash 系统表（INFORMATION_SCHEMA.TIFLASH_TABLES 和 INFORMATION_SCHEMA.TIFLASH_SEGMENTS）。

• TiDB v6.2.0 ~ v7.0.0 版本的 TiDB Lightning 会根据 TiDB 集群的版本决定是否暂停全局调度。当 TiDB 集群版本 >= v6.1.0 时，TiDB Lightning 只会暂停目标表数据范围所在 Region 的调度，并在目标表导入完成后恢复调度。其他版本的 TiDB Lightning 则会暂停全局调度。自 TiDB v7.1.0 开始，你可以通过 pause-pd-scheduler-scope 来控制是否暂停全局调度，默认暂停目标表数据范围所在 Region 的调度。如果目标集群版本低于 v6.1.0 则报错，此时将参数取值改为 "global" 后重试即可。
• 在 TiDB v7.1.0 中使用 FLASHBACK CLUSTER TO TIMESTAMP 功能可能会出现 FLASHBACK 完成后部分 Region 仍处于 FLASHBACK 过程中的问题。请尽量避免在 v7.1.0 中使用该功能。详情可见 #44292。如果已经出现该问题，可以使用 TiDB 快照备份与恢复功能进行数据恢复。

更多 TiDB 7.1.0 Release Notes | PingCAP 文档中心