TiDB 7.4.0 Release Notes

发版日期：2023 年 10 月 12 日

TiDB 版本：7.4.0

试用链接：快速体验 | 下载离线包

在 7.4.0 版本中，你可以获得以下关键特性：

功能详情

可扩展性

• 支持设置 TiDB 节点的服务范围，用于选择适用的 TiDB 节点来执行并行的 ADD INDEX 或 IMPORT INTO 任务（实验特性）#46453 @ywqzzy

• 在资源密集型集群中，并行执行 ADD INDEX 或 IMPORT INTO 任务可能占用大量 TiDB 节点的资源，从而导致集群性能下降。从 v7.4.0 起，你可以通过变量 tidb_service_scope 控制 TiDB 后端任务分布式框架下各 TiDB 节点的服务范围。你可以从现有 TiDB 节点中选择几个节点，或者对新增 TiDB 节点设置服务范围。所有并行执行的 ADD INDEX 和 IMPORT INTO 的任务只会运行在这些节点，避免对已有业务造成性能影响。

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

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

• TiDB v6.6.0 引入了 Partitioned Raft KV 存储引擎作为实验特性，该引擎使用多个 RocksDB 实例存储 TiKV 的 Region 数据，每个 Region 的数据都独立存储在单独的 RocksDB 实例中。

• 在 TiDB v7.4.0 中，Partitioned Raft KV 引擎在兼容性和稳定性方面得到了进一步提升。通过大规模数据测试，确保了 Partitioned Raft KV 引擎与 DM、Dumpling、TiDB Lightning、TiCDC、BR、PITR 等关键生态组件或功能的兼容性。同时，在读写混合工作负载下，Partitioned Raft KV 引擎提供了更稳定的性能，特别适合写多读少的场景。此外，每个 TiKV 节点支持 8 core CPU，并可搭配 8 TB 的数据存储和 64 GB 的内存。

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

• TiFlash 存算分离架构成为正式功能 (GA) #6882 @JaySon-Huang @JinheLin @breezewish @lidezhu @CalvinNeo @Lloyd-Pottiger

• 在 v7.0.0 中，TiFlash 以实验特性引入了存算分离架构。经过一系列的改进，从 v7.4.0 起，TiFlash 正式支持存算分离架构。

• 在存算分离架构下，TiFlash 节点分为 Compute Node（计算节点）和 Write Node（写入节点）两种类型，并使用兼容 S3 API 的对象存储。这两种节点都可以单独扩缩容，独立调整计算或数据存储能力。在存算分离架构下，TiFlash 的使用方式与存算一体架构一致，例如创建 TiFlash 副本、查询、指定优化器 Hint 等。

• 需要注意的是，TiFlash 的存算分离架构和存算一体架构不能混合使用、相互转换，需要在部署 TiFlash 时进行相应的配置指定使用其中的一种架构。

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

性能

• 支持下推 JSON 运算符 MEMBER OF 到 TiKV #46307 @wshwsh12

  • value MEMBER OF(json_array)

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

• 支持下推包含任意帧定义类型的窗口函数到 TiFlash #7376 @xzhangxian1008

• 在 v7.4.0 之前的版本中，TiFlash 不支持包含 PRECEDING 或 FOLLOWING 的窗口函数，所有包含此类帧定义的窗口函数都无法下推至 TiFlash。从 v7.4.0 开始，TiFlash 支持了所有的窗口函数的帧定义。该功能自动启用，满足要求时，包含帧定义的窗口函数会自动下推至 TiFlash 执行。

• 引入基于云存储的全局排序能力，提升并行执行的 ADD INDEX 或 IMPORT INTO 任务的性能和稳定性 #45719 @wjhuang2016

• 在 v7.4.0 以前，当用户执行分布式并行执行框架的 ADD INDEX 或 IMPORT INTO 任务时，TiDB 节点需要准备一块较大的本地磁盘，对编码后的索引 KV pairs 和表数据 KV pairs 进行排序。由于无法从全局角度进行排序，各个 TiDB 节点间以及节点内部导入的数据可能存在重叠情况。这会导致在将这些 KV pairs 导入到 TiKV 时，TiKV 需要频繁进行数据整理 (compaction)，降低了 ADD INDEX 或 IMPORT INTO 的性能和稳定性。

• v7.4.0 引入全局排序特性后，编码后的数据不再写入本地进行排序，而是写入云存储，并在云存储中进行全局排序。然后，TiDB 将经过全局排序的索引数据和表数据并行导入到 TiKV 中，从而提升了性能和稳定性。

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

• 优化 Parallel Multi Schema Change，提升一个 SQL 语句添加多个索引的性能 #41602 @tangenta @Defined2014

• 在 v7.4.0 之前，用户使用 Parallel Multi Schema Change 在一个 SQL 语句中提交多个 ADD INDEX 操作时，其性能与使用多个独立的 SQL 语句进行 ADD INDEX 操作的性能相同。经过 v7.4.0 的优化后，在一个 SQL 语句中添加多个索引的性能得到了大幅提升。

• 支持缓存非 Prepare 语句的执行计划 (GA) #36598 @qw4990

• TiDB v7.0.0 引入了非 Prepare 语句的执行计划缓存作为实验特性，以提升在线交易场景的并发处理能力。在 v7.4.0 中，该功能正式 GA。执行计划缓存技术将会被应用于更广泛的场景，从而提升 TiDB 的并发处理能力。

• 开启非 Prepare 语句执行计划缓存可能会带来额外的内存和 CPU 开销，并不一定适用于所有场景。从 v7.4.0 开始，非 Prepare 语句的执行计划缓存默认关闭。你可以通过系统变量 tidb_enable_non_prepared_plan_cache 控制是否开启该功能并通过 tidb_session_plan_cache_size 设置缓存大小。

• 此外，该功能默认不支持 DML 语句，对 SQL 的模式也有一定的限制，具体参见使用限制。

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

稳定性

• TiFlash 支持查询级别的数据落盘 #7738 @windtalker

• 从 v7.0.0 起，TiFlash 支持控制 GROUP BY、ORDER BY、JOIN 这三种算子的数据落盘功能，避免数据量超过内存总大小时，导致查询终止甚至系统崩溃的问题。然而，单独控制每个算子的落盘较为麻烦，也无法有效进行整体资源控制。

• 在 v7.4.0 中，TiFlash 引入了查询级别数的据落盘功能。通过设置单个查询在单个 TiFlash 节点使用内存的上限 tiflash_mem_quota_query_per_node 及触发数据落盘的内存阈值 tiflash_query_spill_ratio，你可以方便地控制单个查询的内存使用，更好地管控 TiFlash 内存资源。

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

• 支持自定义 TiKV 读取超时时间 #45380 @crazycs520

• 在通常情况下，TiKV 处理请求非常快，只需几毫秒。但是，当某个 TiKV 节点遇到磁盘 I/O 抖动或网络延迟时，请求处理时间可能会大幅增加。在 v7.4.0 以前的版本中，TiKV 请求的超时限制是固定的，不能调整。因此，当 TiKV 节点出现问题时，TiDB 必须等待固定时长的超时响应，这导致了抖动期间应用程序的查询性能受到明显影响。

• TiDB 在 v7.4.0 中引入了一个新系统变量 tikv_client_read_timeout，你可以自定义查询语句中 TiDB 发送给 TiKV 的 RPC 读请求的超时时间。这意味着，当某个 TiKV 节点因磁盘或网络问题导致请求延迟时，TiDB 可以更快地超时并将请求重新发送给其他 TiKV 节点，从而降低查询延迟。如果所有 TiKV 节点的请求都超时，TiDB 将使用默认的超时时间进行重试。此外，你也可以在查询语句中使用 Optimizer Hint /*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */ 来设置 TiDB 发送 TiKV RPC 读请求的超时时间。这一改进将使 TiDB 在面对不稳定的网络或存储环境时，更灵活地适应各种情况，提高查询性能，提升用户体验。

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

• 支持通过优化器提示临时修改部分系统变量的值 #45892 @winoros

• TiDB v7.4.0 新增支持与 MySQL 8.0 相似的优化器提示 SET_VAR()。通过在 SQL 语句中添加 Hint SET_VAR()，可以在语句运行过程中临时修改部分系统变量，以针对不同语句设置环境。例如，可以主动提升高消耗 SQL 的并行度，或者通过变量修改优化器行为。

• 支持使用 Hint SET_VAR() 修改的系统变量请参考系统变量。强烈建议不要利用此 Hint 修改没有明确支持的变量，这可能会引发不可预知的行为。

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

• TiFlash 支持资源管控特性 #7660 @guo-shaoge

• 在 TiDB v7.1.0 中，资源管控成为正式功能，提供对 TiDB 和 TiKV 的资源管理能力。在 v7.4.0 中，TiFlash 支持资源管控特性，完善了 TiDB 整体的资源管控能力。TiFlash 的资源管控与已有的 TiDB 资源管控特性完全兼容，现有的资源组将同时管控 TiDB、TiKV 和 TiFlash 中的资源。

• 通过配置 TiFlash 参数 enable_resource_control，你可以控制是否开启 TiFlash 资源管控特性。开启后，TiFlash 将根据 TiDB 的资源组配置进行资源调度管理，确保整体资源的合理分配和使用。

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

• TiFlash 支持 Pipeline 执行模型 (GA) #6518 @SeaRise

• 在 v7.2.0 中，TiFlash 引入了 Pipeline 执行模型作为实验特性。该模型对所有线程资源进行统一管理，并对所有任务的执行进行统一调度，充分利用线程资源，同时避免资源超用。从 v7.4.0 开始，TiFlash 完善了线程资源使用量的统计，Pipeline 执行模型成为正式功能 (GA) 并默认开启。由于该功能与 TiFlash 资源管控特性相互依赖，TiDB v7.4.0 移除了之前版本中用于控制是否启用 Pipeline 执行模型的变量 tidb_enable_tiflash_pipeline_model。现在你可以通过 TiFlash 参数 tidb_enable_resource_control 同时开启或关闭 Pipeline 执行模型和 TiFlash 资源管控特性。

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

• 新增优化器模式选择 #46080 @time-and-fate

• TiDB 在 v7.4.0 引入了一个新的系统变量 tidb_opt_objective，用于控制优化器的估算方式。默认值 moderate 维持之前版本的优化器行为，即优化器会利用运行时统计到的数据修改来校正估算。如果设置为 determinate，则优化器不考虑运行时校正，只根据统计信息来生成执行计划。

• 对于长期稳定的 OLTP 业务，或者用户对已有的执行计划非常有把握的情况，推荐在测试后切换到 determinate 模式，减少执行计划跳变的可能。

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

• 资源管控支持自动管理后台任务（实验特性）#44517 @glorv

  后台任务是指那些优先级不高但是需要消耗大量资源的任务，如数据备份和自动统计信息收集等。这些任务通常定期或不定期触发，在执行的时候会消耗大量资源，从而影响在线的高优先级任务的性能。在 TiDB v7.4.0 中，资源管控引入了对后台任务的自动管理。该功能有助于降低低优先级任务对在线业务的性能影响，实现资源的合理分配，大幅提升集群的稳定性。

  目前 TiDB 支持如下几种后台任务的类型：

  • lightning：使用 TiDB Lightning 或 IMPORT INTO 执行导入任务。
  • br：使用 BR 执行数据备份和恢复。目前不支持 PITR。
  • ddl：对于 Reorg DDL，控制批量数据回写阶段的资源使用。
  • stats：对应手动执行或系统自动触发的收集统计信息任务。

• 默认情况下，被标记为后台任务的任务类型为空，此时后台任务的管理功能处于关闭状态，其行为与 TiDB v7.4.0 之前版本保持一致。你需要手动修改 default 资源组的后台任务类型以开启后台任务管理。

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

• 增强锁定统计信息的能力 #46351 @hi-rustin

• 在 v7.4.0 中，TiDB 增强了锁定统计信息的能力。现在，锁定和解锁统计信息需要与收集统计信息 (ANALYZE TABLE) 相同的权限，以确保操作的安全性。此外，还新增了对特定分区的统计信息进行锁定和解锁操作的支持，提高了功能灵活性。当用户对数据库中的查询和执行计划有把握，并且不希望发生变化时，可以使用锁定统计信息来提升统计信息的稳定性。

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

• 引入系统变量控制是否选择表的哈希连接 #46695 @coderplay

• 表的哈希连接是 MySQL 8.0 引入的新特性，主要用于连接两个相对较大的表和结果集。但对于交易类负载，或者一部分在 MySQL 5.7 稳定运行的业务来说，选择表的哈希连接可能会对性能产生风险。MySQL 通过优化器开关 optimizer_switch能够在全局或者会话级控制哈希连接的选择。

• 从 v7.4.0 开始，TiDB 引入系统变量 tidb_opt_enable_hash_join 对表的哈希连接进行控制。默认开启 (ON)。如果你非常确定执行计划中不需要选择表之间的哈希连接，则可以修改变量为 OFF，降低执行计划回退的可能性，提升系统稳定性。

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

SQL 功能

• TiDB 支持完整的分区类型管理功能 #42728 @mjonss

• 在 v7.4.0 之前，TiDB 中的分区表不能调整分区类型。从 v7.4.0 开始，TiDB 支持将分区表修改为非分区表、将非分区表修改为分区表、修改分区类型功能。你可以根据需要灵活调整表的分区类型、数量。例如，通过 ALTER TABLE t PARTITION BY ... 语句修改分区类型。

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

• TiDB 支持 WITH ROLLUP 修饰符和 GROUPING 函数 #44487 @AilinKid

• WITH ROLLUP 修饰符和 GROUPING 函数是数据分析中常用的功能，用于对数据进行多维度的汇总。从 v7.4.0 开始，TiDB 支持在 GROUP BY 子句中使用 WITH ROLLUP 修饰符和 GROUPING 函数。例如，你可以通过 SELECT ... FROM ... GROUP BY ... WITH ROLLUP 语法使用 WITH ROLLUP 修饰符。

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

数据库管理

• 新增排序规则 utf8mb4_0900_ai_ci 和 utf8mb4_0900_bin #37566 @YangKeao @zimulala @bb7133

• TiDB v7.4.0 增强了从 MySQL 8.0 迁移数据的支持。新增两个排序规则 (Collation) utf8mb4_0900_ai_ci 和 utf8mb4_0900_bin。其中 utf8mb4_0900_ai_ci 为 MySQL 8.0 的默认排序规则。

• 同时新增支持 MySQL 8.0 兼容的系统变量 default_collation_for_utf8mb4，允许用户为 utf8mb4 字符集指定默认的排序方式，以兼容从 MySQL 5.7 或之前版本迁移或数据复制的场景。

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

可观测性

• 支持向日志中添加会话标识和会话别名 #46071 @lcwangchao

• 在对 SQL 执行问题做故障定位的时候，经常需要把 TiDB 各组件日志中的内容进行关联，由此找到问题的根本原因。从 v7.4.0 开始，TiDB 将会话标识 (CONNECTION_ID) 写入与会话相关的日志内容中，包括 TiDB 日志、慢查询日志、以及 TiKV 上 coprocessor 的慢日志记录。你可以根据会话标识，将几个日志中的内容关联起来，提升故障定位和诊断的效率。

• 除此之外，通过设置会话级变量 tidb_session_alias，你可以向上述日志中添加自定义的标识。借助这个能力，把业务识别信息注入日志，可以将日志中的内容与业务关联，打通了业务到日志的链路，降低了诊断工作的难度。

• TiDB Dashboard 提供表格视图的执行计划 #1589 @baurine

• 在 v7.4.0 中，TiDB Dashboard 的 Slow Query 页面和 SQL Statement 页面提供表格视图的执行计划，以提升用户的诊断体验。

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

数据迁移

• 增强 IMPORT INTO 功能 #46704 @D3Hunter

  从 v7.4.0 起，你可以通过在 IMPORT INTO 的 CLOUD_STORAGE_URI 选项中指定编码后数据的云存储地址，开启全局排序功能（实验特性），提升性能和稳定性。

  此外，在 v7.4.0 中，IMPORT INTO 还引入了以下功能：

  • 支持配置 Split_File 选项，可将单个大 CSV 文件切分成多个 256 MiB 的小 CSV 文件进行并行处理，提升导入性能。
  • 支持导入压缩后的 CSV 和 SQL 文件，支持的压缩格式包括 .gzip、.gz、.zstd、.zst 和 .snappy。

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

• Dumpling 在将数据导出为 CSV 文件时支持用户自定义换行符 #46982 @GMHDBJD

• 在 v7.4.0 之前，Dumpling 导出数据为 CSV 文件时，换行符为 "\r\n"，导致一些只能解析 "\n" 换行符的下游系统无法解析该 CSV 文件，或者要通过第三方工具转换后才能解析。

• 从 v7.4.0 起，Dumpling 引入了新的参数 --csv-line-terminator。当你将数据导出为 CSV 文件时，可以通过该参数传入所需的换行符。该参数支持 "\r\n\" 和 "\n"，默认值为 "\r\n"，即和历史版本保持一致。

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

• TiCDC 支持同步数据至 Pulsar #9413 @yumchina @asddongmen

• Pulsar 是一款云原生的分布式消息流平台，它能够显著提升你的实时数据流体验。从 v7.4.0 起，TiCDC 支持以 canal-json 格式同步变更数据至 Pulsar，实现与 Pulsar 的无缝集成。通过该功能，TiCDC 可以让你轻松捕获和同步 TiDB 变更数据到 Pulsar，为数据处理和分析功能提供新的可能性。你可以开发自己的消费应用程序，从 Pulsar 中读取并处理新生成的变更数据，以满足特定的业务需求。

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

• TiCDC 支持 Claim-Check 功能，改进对大型消息的处理 #9153 @3AceShowHand

• 在 v7.4.0 之前，TiCDC 无法向下游发送超过 Kafka 最大消息大小 (max.message.bytes) 的大型消息。从 v7.4.0 开始，在配置下游为 Kafka 的 Changefeed 的时候，你可以指定一个外部存储位置，用于存储超过 Kafka 限制的大型消息。TiCDC 会向 Kafka 发送一条引用消息，其中记录了该大型消息在外部存储中的地址。当消费者收到该引用消息后，可以根据其中记录的外部存储地址信息，获取对应的消息内容。

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

兼容性变更

注意

以下为从 v7.3.0 升级至当前版本 (v7.4.0) 所需兼容性变更信息。如果从 v7.2.0 或之前版本升级到当前版本，可能也需要考虑和查看中间版本 release notes 中提到的兼容性变更信息。

行为变更

• 自 v7.4.0 起，TiDB 已经兼容 MySQL 8.0 的核心功能，version() 将返回以 8.0.11 为前缀的版本信息。
• 升级到 TiFlash v7.4.0 后，不支持原地降级到之前的版本。这是因为，从 v7.4.0 开始，为了减少数据整理时产生的读、写放大，TiFlash 对 PageStorage V3 数据整理时的逻辑进行了优化，导致底层部分存储文件名发生了改动。详情请参考 TiFlash 升级帮助。

系统变量

配置文件参数

改进提升

• TiDB

  • 优化 ANALYZE 分区表的内存使用和性能 #47071 #47104 #46804 @hawkingrei
  • 优化统计信息垃圾回收的内存使用和性能 #31778 @winoros
  • 优化索引合并进行交集操作时的 limit 下推，提高查询性能 #46863 @AilinKid
  • 改进代价模型 (Cost Model) 以尽量避免在 IndexLookup 回表任务多时错误地选择全表扫描 #45132 @qw4990
  • 优化 join 消除规则，提高 join on unique keys 时的查询性能 #46248 @fixdb
  • 将多值索引列的排序规则变更为 binary，避免执行失败 #46717 @YangKeao

• TiKV

  • 改进 Resolver 的内存使用，防止 OOM #15458 @overvenus
  • 消除 Router 对象中的 LRUCache，降低内存占用，防止 OOM #15430 @Connor1996
  • 降低 TiCDC Resolver 的内存占用 #15412 @overvenus
  • 降低 RocksDB compaction 带来的内存抖动 #15324 @overvenus
  • 降低 Partitioned Raft KV 中流控模块的内存占用 #15269 @overvenus
  • 新增 PD Client 连接重试过程中的 backoff 机制。异常错误重试期间，逐步增加重试时间间隔，减小 PD 压力 #15428 @nolouch
  • 支持动态调整 RocksDB 的 background_compaction #15424 @glorv

• PD

  • 优化 TSO 的追踪信息，方便调查 TSO 相关问题 #6856 @tiancaiamao
  • 支持复用 HTTP Client 连接，降低内存占用 #6913 @nolouch
  • 优化无法连接到备份集群时 PD 自动更新集群状态的速度 #6883 @disksing
  • 改进 resource control client 的配置获取方式，使其可以动态获取最新配置 #7043 @nolouch

• TiFlash

  • 改进 TiFlash 写入过程的落盘策略，提升随机写入负载下的写性能 #7564 @CalvinNeo
  • 为 TiFlash 处理 Raft 同步过程添加更多观测指标 #8068 @CalvinNeo
  • 改进 TiFlash 文件格式，减少小文件数量以避免造成文件系统 inode 耗尽的问题 #7595 @hongyunyan

• Tools

  • Backup & Restore (BR)

    • 缓解了 Region leadership 迁移导致 PITR 日志备份进度延迟变高的问题 #13638 @YuJuncen
    • 通过设置 HTTP 客户端 MaxIdleConns 和 MaxIdleConnsPerHost 参数，增强日志备份以及 PITR 恢复任务对连接复用的支持 #46011 @Leavrth
    • 增强 BR 在连接 PD 或外部 S3 存储出错时的容错能力 #42909 @Leavrth
    • 新增 restore 参数 WaitTiflashReady。当打开这个参数时，restore 操作将会等待 TiFlash 副本复制成功后才结束 #43828 #46302 @3pointer
    • 减少日志备份 resolve lock 的 CPU 开销 #40759 @3pointer

  • TiCDC

    • 优化同步 ADD INDEX DDL 的执行逻辑，从而不阻塞后续的 DML 语句 #9644 @sdojjy

  • TiDB Lightning

    • 优化 TiDB Lightning 在 Region scatter 阶段的重试逻辑 #46203 @mittalrishabh
    • 优化 TiDB Lightning 在导入数据阶段对 no leader 错误的重试逻辑 #46253 @lance6716