| title |
|---|
TiDB 6.4.0 Release Notes |
发版日期：2022 年 11 月 17 日
TiDB 版本：6.4.0-DMR
在 6.4.0-DMR 版本中，你可以获得以下关键特性：
- 支持通过
FLASHBACK CLUSTER TO TIMESTAMP命令将集群快速回退到特定的时间点 (实验特性）。 - 支持对 TiDB 实例的全局内存使用进行追踪（实验特性）。
- TiDB 分区表兼容 LINEAR HASH 分区语法。
- 支持高性能、全局单调递增的
AUTO_INCREMENT列属性（实验特性）。 - 支持对 JSON 类型中的 Array 数据做范围选择。
- 实现磁盘故障、I/O 无响应等极端情况下的故障恢复加速。
- 新增动态规划算法来决定表的连接顺序。
- 引入新的优化器提示
NO_DECORRELATE来控制关联优化的解除。 - 集群诊断功能 GA。
- TiFlash 静态加密支持国密算法 SM4。
- 支持通过 SQL 语句立即对指定分区的 TiFlash 副本进行物理数据整理 (Compaction)。
- 支持基于 AWS EBS snapshot 的集群备份和恢复。
- 支持在分库分表合并迁移场景中标记下游表中的数据来自上游哪个分库、分表和数据源。
-
支持通过 SQL 语句立即对指定分区的 TiFlash 副本进行物理数据整理 (Compaction) #5315 @hehechen
TiDB v6.2.0 发布了针对全表的 TiFlash 副本立即进行物理数据整理 (Compaction) 的功能，支持用户自行选择合适的时机，手动执行 SQL 语句立即对 TiFlash 中的物理数据进行整理，从而减少存储空间占用，并提升查询性能。v6.4.0 细化了 TiFlash 副本数据整理的粒度，支持对表中指定分区的 TiFlash 副本立即进行数据整理。
通过 SQL 语句
ALTER TABLE table_name COMPACT [PARTITION PartitionNameList] [engine_type REPLICA]，你可以立即对指定分区的 TiFlash 副本进行数据整理。更多信息，请参考用户文档。
-
支持通过
FLASHBACK CLUSTER TO TIMESTAMP命令将集群快速回退到特定的时间点（实验特性）#37197 #13303 @Defined2014 @bb7133 @JmPotato @Connor1996 @HuSharp @CalvinNeoFLASHBACK CLUSTER TO TIMESTAMP支持在 Garbage Collection (GC) life time 内快速回退整个集群到指定的时间点。使用该特性可以快速撤消 DML 误操作。例如，在误执行了没有WHERE子句的DELETE后，使用FLASHBACK CLUSTER TO TIMESTAMP能够在几分钟内将集群数据恢复到指定的时间点。该特性不依赖于数据库备份，并支持在时间线上多次回退以确定特定数据更改发生的时间。需要注意的是，FLASHBACK CLUSTER TO TIMESTAMP不能替代数据库备份。在执行
FLASHBACK CLUSTER TO TIMESTAMP之前，需要暂停 PITR 和 TiCDC 等工具上运行的同步任务，待FLASHBACK执行完成后再启动，否则会造成同步失败等问题。更多信息，请参考用户文档。
-
支持通过
FLASHBACK DATABASE命令来恢复被删除的数据库 #20463 @erwadbaFLASHBACK DATABASE支持在 Garbage Collection (GC) life time 时间内恢复被DROP删除的数据库以及数据。该特性不依赖任何外部工具，可以轻松快速地通过 SQL 语句进行数据和元信息的恢复。更多信息，请参考用户文档。
-
TiFlash 静态加密支持国密算法 SM4 #5953 @lidezhu
TiFlash 的静态加密新增 SM4 算法，你可以将配置文件
tiflash-learner.toml中的data-encryption-method参数的值设置为sm4-ctr，以启用基于国密算法 SM4 的静态加密能力。更多信息，请参考用户文档。
-
集群诊断功能 GA #1438 @Hawkson-jee
集群诊断功能是在指定的时间范围内，对集群可能存在的问题进行诊断，并将诊断结果和一些集群相关的负载监控信息汇总成一个诊断报告。诊断报告是网页形式，通过浏览器保存后可离线浏览和传阅。
你可以通过该报告快速了解集群内的基本诊断信息，包括负载、组件、耗时和配置信息。若集群存在一些常见问题，在诊断信息部分可以了解 TiDB 内置自动诊断的结果。
-
引入 Coprocessor Task 并发度自适应机制 #37724 @you06
随着 Coprocessor Task 任务数增加，TiDB 将结合 TiKV 处理速度自动增加任务并发度（调整
tidb_distsql_scan_concurrency），减少 Coprocessor Task 任务排队，降低延迟。 -
新增动态规划算法来决定表的连接顺序 #37825 @winoros
在之前的版本中，TiDB 采用贪心算法来决定表的连接顺序。在 v6.4.0 中，优化器引入了动态规划算法。相比贪心算法，动态规划算法会枚举更多可能的连接顺序，进而有机会发现更好的执行计划，提升部分场景下 SQL 执行效率。
由于动态规划算法的枚举过程可能消耗更多的时间，目前 Join Reorder 算法由变量
tidb_opt_join_reorder_threshold控制，当参与 Join Reorder 的节点个数大于该阈值时选择贪心算法，反之选择动态规划算法。更多信息，请参考用户文档。
-
前缀索引支持对空值进行过滤 #21145 @xuyifangreeneyes
该特性是对前缀索引使用上的优化。当表中某列存在前缀索引，那么 SQL 语句中对该列的
IS NULL或IS NOT NULL条件可以直接利用前缀进行过滤，避免了这种情况下的回表，提升了 SQL 语句的执行性能。更多信息，请参考用户文档。
-
增强 TiDB Chunk 复用机制 #38606 @keeplearning20221
在之前的版本中，TiDB 只在
writechunk函数中复用 Chunk。TiDB v6.4.0 扩展 Chunk 复用机制到 Executor 的算子中，通过复用 Chunk 减少 TiDB 申请释放内存频率，进而提升部分场景下的 SQL 查询执行效率。你可以通过系统变量tidb_enable_reuse_chunk来控制是否启用 Chunk 对象复用，默认为开启。 -
引入新的优化器提示
NO_DECORRELATE来控制关联优化的解除 #37789 @time-and-fate默认情况下，TiDB 总是会尝试重写关联子查询以解除关联，这通常会提高执行效率。但是在一部分场景下，解除关联反而会降低执行效率。TiDB 在 v6.4.0 版本中引入了 hint
NO_DECORRELATE，用来提示优化器不要对指定的查询块解除关联，以提升部分场景下的查询性能。更多信息，请参考用户文档。
-
提升了分区表统计信息收集的性能 #37977 @Yisaer
在 v6.4.0 版本中，TiDB 优化了分区表统计信息的收集策略。你可以通过系统变量
tidb_auto_analyze_partition_batch_size定义并发度，用并行的方式同时收集多个分区的统计信息，从而加快统计信息收集的速度，减少 analyze 所需的时间。
-
磁盘故障、I/O 无响应等极端情况下的故障恢复加速 #13648 @LykxSassinator
数据库的可用性是企业用户最为关注的指标之一，但是在复杂的硬件环境下，如何快速检测故障并恢复一直是数据库面临的挑战之一。TiDB v6.4.0 全面优化了 TiKV 节点的状态检测机制。即使在磁盘故障或 I/O 无响应等极端情况下，TiDB 依然可以快速上报节点状态，同时搭配主动唤醒机制，提前发起 Leader 选举，加速集群自愈。通过这次优化，TiDB 在磁盘故障场景下，集群恢复时间可以缩短 50% 左右。
-
TiDB 全局内存控制（实验特性）#37816 @wshwsh12
v6.4.0 引入了全局内存控制，对 TiDB 实例的全局内存使用进行追踪。你可以通过系统变量
tidb_server_memory_limit设置全局内存的使用上限。当内存使用量接近预设的上限时，TiDB 会尝试对内存进行回收，释放更多的可用内存；当内存使用量超出预设的上限时，TiDB 会识别出当前内存使用量最大的 SQL 操作，并取消这个操作，避免因为内存使用过度而产生的系统性问题。当 TiDB 实例的内存消耗存在潜在风险时，TiDB 会预先收集诊断信息并写入指定目录，方便对问题的诊断。同时，TiDB 提供了系统表视图
INFORMATION_SCHEMA.MEMORY_USAGE和INFORMATION_SCHEMA.MEMORY_USAGE_OPS_HISTORY用来展示内存使用情况及历史操作，帮助用户清晰了解内存使用状况。全局内存控制是 TiDB 内存管理的重要一步，对实例采用全局视角，引入系统性方法对内存用量进行管理，这可以极大提升数据库的稳定性，提高服务的可用性，支持 TiDB 在更多重要场景平稳运行。
更多信息，请参考用户文档。
-
控制优化器在构造范围时的内存占用 #37176 @xuyifangreeneyes
v6.4.0 引入了系统变量
tidb_opt_range_max_size来限制优化器在构造范围时消耗的内存上限。当内存使用超出这个限制，则放弃构造精确的范围，转而构建更粗粒度的范围，以此降低内存消耗。当 SQL 语句中的IN条件较多时，这个优化可以显著降低编译时的内存使用量，保证系统的稳定性。更多信息，请参考用户文档。
-
支持统计信息的同步加载（GA）#37434 @chrysan
TiDB v6.4.0 起，正式开启了统计信息同步加载的特性（默认开启），支持在执行当前 SQL 语句时将直方图、TopN、CMSketch 等占用空间较大的统计信息同步加载到内存，提高优化该 SQL 语句时统计信息的完整性。
更多信息，请参考用户文档。
-
降低批量写入请求对轻量级事务写入的响应时间的影响 #13313 @glorv
定时批量 DML 任务存在于一部分系统的业务逻辑中。在此场景下，处理这些批量写入任务会增加在线交易的时延。在 v6.3.0 中，TiKV 对混合负载场景下读请求的优先级进行了优化，你可以通过
readpool.unified.auto-adjust-pool-size配置项开启 TiKV 对统一处理读请求的线程池 (UnifyReadPool) 大小的自动调整。在 v6.4.0 中，TiKV 对写入请求也进行了动态识别和优先级调整，控制 Apply 线程每一轮处理单个状态机写入的最大数据量，从而降低批量写入对交易事务写入的响应时间的影响。
-
TiKV API V2 成为正式功能 #11745 @pingyu
在 v6.1.0 之前，TiKV 的 RawKV 接口仅存储客户端传入的原始数据，因此只提供基本的 Key-Value 读写能力。此外，由于编码方式不同、数据范围没有隔离等，同一个 TiKV 集群中，TiDB、事务 KV、RawKV 无法同时使用，因此对于不同使用方式并存的场景，必须部署多个集群，增加了机器和部署成本。
TiKV API V2 提供了新的存储格式，功能亮点如下：
- RawKV 数据以 MVCC 方式存储，记录数据的变更时间戳，并在此基础上提供 Change Data Capture 能力（实验特性，见 TiKV-CDC）。
- 数据根据使用方式划分范围，支持单一集群 TiDB、事务 KV、RawKV 应用共存。
- 预留 Key Space 字段，为多租户等特性提供支持。
你可以通过在 TiKV 的
[storage]配置中设置api-version = 2来启用 TiKV API V2。更多信息，请参考用户文档。
-
优化 TiFlash 数据同步进度的准确性 #4902 @hehechen
TiDB 的
INFORMATION_SCHEMA.TIFLASH_REPLICA表中的PROGRESS字段表示 TiFlash 副本与 TiKV 中对应表数据的同步进度。在之前的版本中，PROCESS字段只显示 TiFlash 副本创建过程中的数据同步进度。在 TiFlash 副本创建完后，当在 TiKV 相应的表中导入新的数据时，该值不会更新数据的同步进度。v6.4.0 版本改进了 TiFlash 副本数据同步进度更新机制。在创建 TiFlash 副本后，进行数据导入等操作，TiFlash 副本需要和 TiKV 数据进行同步时，
INFORMATION_SCHEMA.TIFLASH_REPLICA表中的PROGRESS值将会更新，显示实际的数据同步进度。通过此优化，你可以方便地查看 TiFlash 数据同步的实际进度。更多信息，请参考用户文档。
-
TiDB 分区表兼容 Linear Hash 分区语法 #38450 @mjonss
TiDB 现有的分区方式支持 Hash、Range、List 分区。TiDB v6.4.0 增加了对 MySQL LINEAR HASH 分区语法的兼容。
在 TiDB 上，你可以直接执行原有的 MySQL Linear Hash 分区的 DDL 语句，TiDB 将创建一个常规的非线性 Hash 分区表（注意 TiDB 内部实际不存在 LINEAR HASH 分区）。你也可以直接执行原有的 MySQL LINEAR HASH 分区的 DML 语句，TiDB 将正常返回对应的 TiDB Hash 分区的查询结果。此功能保证了 TiDB 对 MySQL LINEAR HASH 分区的语法兼容，方便基于 MySQL 的应用无缝迁移到 TiDB。
当分区数是 2 的幂时，TiDB Hash 分区表中行的分布情况与 MySQL Linear Hash 分区表相同，但当分区数不是 2 的幂时，TiDB Hash 分区表中行的分布情况与 MySQL Linear Hash 分区表会有所区别。
更多信息，请参考用户文档。
-
支持高性能、全局单调递增的
AUTO_INCREMENT列属性（实验特性）#38442 @tiancaiamaoTiDB v6.4.0 引入了
AUTO_INCREMENT的 MySQL 兼容模式，通过中心化分配自增 ID，实现了自增 ID 在所有 TiDB 实例上单调递增。使用该特性能够更容易地实现查询结果按自增 ID 排序。要使用 MySQL 兼容模式，你需要在建表时将AUTO_ID_CACHE设置为1。CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 1;
更多信息，请参考用户文档。
-
支持对 JSON 类型中的 Array 数据做范围选择 #13644 @YangKeao
从 v6.4.0 起，TiDB 支持 MySQL 兼容的范围选择语法。
- 通过关键字
to，你可以指定元素起始和结束的位置，并选择 Array 中连续范围的元素，起始位置记为0。例如，使用$[0 to 2]可以选择 Array 中的前三个元素。 - 通过关键字
last，你可以指定 Array 中最后一个元素的位置，实现从右到左的位置设定。例如，使用$[last-2 to last]可以选择 Array 中的最后三个元素。
该特性简化了 SQL 的编写过程，进一步提升了 JSON 类型的兼容能力，降低了 MySQL 应用向 TiDB 迁移的难度。
- 通过关键字
-
支持对数据库用户增加额外说明 #38172 @CbcWestwolf
在 TiDB v6.4.0 中，你可以通过
CREATE USER或ALTER USER语句为数据库用户添加额外的说明信息。TiDB 提供了两种说明格式，你可以通过COMMENT添加一段文本注释，也可以通过ATTRIBUTE添加一组 JSON 格式的结构化属性。此外，TiDB v6.4.0 新增了
USER_ATTRIBUTES表。你可以在该表中查看用户的注释和属性信息。CREATE USER 'newuser1'@'%' COMMENT 'This user is created only for test'; CREATE USER 'newuser2'@'%' ATTRIBUTE '{"email": "[email protected]"}'; SELECT * FROM INFORMATION_SCHAME.USER_ATTRIBUTES;
+-----------+------+---------------------------------------------------+ | USER | HOST | ATTRIBUTE | +-----------+------+---------------------------------------------------+ | newuser1 | % | {"comment": "This user is created only for test"} | | newuser1 | % | {"email": "[email protected]"} | +-----------+------+---------------------------------------------------+ 2 rows in set (0.00 sec)
这个特性提升了 TiDB 对 MySQL 的语法的兼容性，使得 TiDB 更容易融入 MySQL 生态的工具或平台。
-
基于 AWS EBS snapshot 的集群备份和恢复 #33849 @fengou1
如果你的 TiDB 集群部署在 EKS 上，使用了 AWS EBS 卷，并且对数据备份有以下要求，可考虑使用 TiDB Operator 将 TiDB 集群数据以卷快照以及元数据的方式备份至 Amazon S3：
- 备份的影响降到最小，如备份对 QPS 和事务耗时影响小于 5%，不占用集群 CPU 以及内存。
- 快速备份和恢复，比如 1 小时内完成备份，2 小时内完成恢复。
更多信息，请参考用户文档。
-
支持将上游数据源信息以扩展列形式写入下游合表 #37797 @lichunzhu
在上游分库分表合并到 TiDB 的场景，你可以在目标表中手动额外增加几个字段（扩展列），并在配置 DM 任务时，对这几个扩展列赋值。例如，当赋予上游分库分表的名称时，通过 DM 写入到下游的记录会包含上游分库分表的名称。在一些数据异常的场景，你可以通过该功能快速定位目标表的问题数据源信息，如该数据来自上游哪个分库，哪个分表。
更多信息，请参考提取分库分表数据源信息写入合表。
-
优化 DM 的前置检查项，将部分必须通过项改为非必须通过项 #7333 @lichunzhu
为了使数据迁移任务顺利进行，DM 在启动迁移任务时会自动触发任务前置检查，并返回检查结果。只有当前置检查通过后，DM 才开始执行迁移任务。
在 v6.4.0，DM 将如下三个检查项由必须通过项改为非必须通过项，提升了前置检查通过率：
- 检查字符集是否存在兼容性差异
- 检查上游表中是否存在主键或唯一键约束
- 数据库主从配置，上游数据库必须设置数据库 ID
server_id
-
增量迁移任务支持 binlog position 和 GTID 作为选配参数 #7393 @GMHDBJD
v6.4.0 之前，只配置增量迁移任务时，需要传入 binlog position 或者 GTID 才能启动任务，配置复杂，用户理解成本高。自 v6.4.0 起，如果只需要执行增量迁移任务，则可以不指定 binlog position 或者 GTID 的参数取值，DM 将默认按任务的启动时间从上游获取该时间之后的 binlog file，并将这些增量数据迁移到下游 ，降低了使用时的理解成本和配置复杂度。
更多信息，请参考 DM 任务完整配置文件介绍。
-
DM 任务增加一些状态信息的展示 #7343 @okJiang
在 v6.4.0，DM 数据迁移任务新增了一些性能指标和进度指标，方便用户更直观地了解迁移性能和进度，同时为问题排查提供参考信息：
- 增加了 DM 任务当前数据导出、数据导入的性能指标，单位 bytes/s。
- 将当前 DM 写入目标库的性能指标命名从 TPS 改为 RPS (rows/second)。
- 新增了 DM 全量任务数据导出的进度展示。
关于这些指标的详细介绍，请参考 TiDB Data Migration 查询状态。
-
TiCDC 支持同步数据到
3.2.0版本的 Kafka #7191 @3AceShowHandTiCDC 下游支持的 Kafka 最高版本从
3.1.0变为3.2.0。你可以通过 TiCDC 将数据同步到不高于3.2.0版本的 Kafka。
| 变量名 | 修改类型 | 描述 |
|---|---|---|
tidb_constraint_check_in_place_pessimistic |
修改 | 该变量用于控制悲观事务中唯一约束检查的时间点。v6.4.0 去掉了它的 GLOBAL 作用域并支持通过配置项 pessimistic-txn.constraint-check-in-place-pessimistic 控制它的默认值。 |
tidb_ddl_flashback_concurrency |
修改 | 该变量从 v6.4.0 开始生效，用来控制 FLASHBACK CLUSTER TO TIMESTAMP 的并发数。默认值为 64。 |
tidb_enable_clustered_index |
修改 | 该变量默认值从 INT_ONLY 修改为 ON，表示表的主键默认使用聚簇索引。 |
tidb_enable_paging |
修改 | 该变量默认值 OFF 修改为 ON，表示默认使用分页 (paging) 方式发送 Coprocessor 请求。 |
tidb_enable_prepared_plan_cache |
修改 | 该变量用来控制是否开启 Prepared Plan Cache。v6.4.0 新增了 SESSION 作用域。 |
tidb_memory_usage_alarm_ratio |
修改 | 该变量用于设置触发 tidb-server 内存告警的内存使用比率，默认值从 0.8 修改为 0.7。 |
tidb_opt_agg_push_down |
修改 | 该变量用来设置优化器是否执行聚合函数下推到 Join，Projection 和 UnionAll 之前的优化操作。v6.4.0 新增了 GLOBAL 的作用域。 |
tidb_prepared_plan_cache_size |
修改 | 该变量用来控制单个 session 的 Prepared Plan Cache 最多能够缓存的计划数量。v6.4.0 新增了 SESSION 作用域。 |
tidb_stats_load_sync_wait |
修改 | 该变量默认值从 0 修改为 100，代表 SQL 执行同步加载完整统计信息默认等待 100 毫秒后会超时。 |
tidb_stats_load_pseudo_timeout |
修改 | 该变量默认值从 OFF 修改为 ON，代表统计信息同步加载超时后，SQL 会退回使用 pseudo 的统计信息。 |
last_sql_use_alloc |
新增 | 该变量是一个只读变量，用来显示上一个语句是否使用了缓存的 Chunk 对象 (Chunk allocation)。默认值为 OFF。 |
tidb_auto_analyze_partition_batch_size |
新增 | 该变量用于设置 TiDB 自动 analyze 分区表（即自动收集分区表上的统计信息）时，每次同时 analyze 分区的个数。默认值为 1。 |
tidb_enable_external_ts_read |
新增 | 该变量用于控制 TiDB 是否会读取 tidb_external_ts 指定的时间戳前的历史数据。默认值为 OFF。 |
tidb_enable_gogc_tuner |
新增 | 该变量来用控制是否开启 GOGC Tuner，默认为 ON。 |
tidb_enable_reuse_chunk |
新增 | 该变量用于控制 TiDB 是否启用 Chunk 对象缓存，默认为 ON，代表 TiDB 优先使用缓存中的 Chunk 对象，缓存中找不到申请的对象时才会从系统内存中申请。如果为 OFF，则直接从系统内存中申请 Chunk 对象。 |
tidb_enable_prepared_plan_cache_memory_monitor |
新增 | 该变量用来控制是否统计 Prepared Plan Cache 中所缓存的执行计划占用的内存，默认为 ON。 |
tidb_external_ts |
新增 | 默认值为 0。当 tidb_enable_external_ts_read 设置为 ON 时，TiDB 会依据该变量指定的时间戳读取历史数据。 |
tidb_gogc_tuner_threshold |
新增 | 该变量用来控制 GOGC Tuner 自动调节的最大内存阈值，超过阈值后 GOGC Tuner 会停止工作。默认值为 0.6。 |
tidb_memory_usage_alarm_keep_record_num |
新增 | 当 tidb-server 内存占用超过内存报警阈值并触发报警时，TiDB 默认只保留最近 5 次报警时所生成的状态文件。通过该变量可以调整该次数。 |
tidb_opt_prefix_index_single_scan |
新增 | 该变量用于控制 TiDB 优化器是否将某些过滤条件下推到前缀索引，尽量避免不必要的回表，从而提高查询性能。默认为 ON。 |
tidb_opt_range_max_size |
新增 | 该变量用于指定优化器构造扫描范围的内存用量上限。默认值为 67108864（即 64 MiB）。 |
tidb_server_memory_limit |
新增 | 该变量用于指定 TiDB 实例的内存限制（实验特性）。默认值为 0，表示不设内存限制。 |
tidb_server_memory_limit_gc_trigger |
新增 | 该变量用于控制 TiDB 尝试触发 GC 的阈值（实验特性）。默认值为 70%。 |
tidb_server_memory_limit_sess_min_size |
新增 | 开启内存限制后，TiDB 会终止当前实例上内存用量最高的 SQL 语句。本变量指定此情况下 SQL 语句被终止的最小内存用量（实验特性），默认值为 134217728（即 128 MiB）。 |
| 配置文件 | 配置项 | 修改类型 | 描述 |
|---|---|---|---|
| TiDB | tidb_memory_usage_alarm_ratio |
废弃 | 该配置不再生效。 |
| TiDB | memory-usage-alarm-ratio |
废弃 | 该配置项被系统变量 tidb_memory_usage_alarm_ratio 所取代。如果在升级前设置过该配置项，升级后原配置将不再生效。 |
| TiDB | pessimistic-txn.constraint-check-in-place-pessimistic |
新增 | 用于控制系统变量 tidb_constraint_check_in_place_pessimistic 的默认值，默认值为 true。 |
| TiDB | tidb-max-reuse-chunk |
新增 | 用于控制每个连接最多缓存的 Chunk 对象数，默认值为 64。 |
| TiDB | tidb-max-reuse-column |
新增 | 用于控制每个连接最多缓存的 column 对象数，默认值为 256。 |
| TiKV | cdc.raw-min-ts-outlier-threshold |
废弃 | 该配置不再生效。 |
| TiKV | causal-ts.alloc-ahead-buffer |
新增 | 预分配给 TSO 的缓存大小（以时长计算），默认值为 3s。 |
| TiKV | causal-ts.renew-batch-max-size |
新增 | 单次时间戳请求的最大数量，默认值为 8192。 |
| TiKV | raftstore.apply-yield-write-size |
新增 | Apply 线程每一轮处理单个状态机写入的最大数据量，默认值为 32KiB。这是个软限制。 |
| PD | tso-update-physical-interval |
新增 | 这个配置项从 v6.4.0 开始生效，用来控制 TSO 物理时钟更新周期，默认值为 50ms。 |
| TiFlash | data-encryption-method |
修改 | 扩展可选值范围：增加 sm4-ctr。设置为 sm4-ctr 时，数据将采用国密算法 SM4 加密后进行存储。 |
| DM | routes.route-rule-1.extract-table |
新增 | 可选配置。用于提取分库分表场景中分表的源信息，提取的信息写入下游合表，用于标识数据来源。如果配置该项，需要提前在下游手动创建合表。 |
| DM | routes.route-rule-1.extract-schema |
新增 | 可选配置。用于提取分库分表场景中分库的源信息，提取的信息写入下游合表，用于标识数据来源。如果配置该项，需要提前在下游手动创建合表。 |
| DM | routes.route-rule-1.extract-source |
新增 | 可选配置。用于提取分库分表场景中的源信息，提取的信息写入下游合表，用于标识数据来源。如果配置该项，需要提前在下游手动创建合表。 |
| TiCDC | transaction-atomicity |
修改 | 默认值由 table 改为 none。该修改可降低同步延迟，减少系统出现 OOM 的风险。同时，修改默认值后，系统只拆分少量的事务（即超过 1024 行的事务），而不是拆分所有事务。 |
- 从 v6.4.0 开始，
mysql.user表新增User_attributes和Token_issuer两个字段。如果从 v6.4.0 之前版本的备份数据恢复mysqlschema 下的系统表 到 v6.4.0 集群，BR 将返回mysql.user表的column count mismatch错误。如果你未选择恢复mysqlschema 下的系统表，则不会报错。 - 针对命名规则符合 Dumpling 输出文件格式但后缀名并非 gzip 压缩格式的文件（例如
test-schema-create.sql.origin和test.table-schema.sql.origin），Lightning 的处理方式发生了变化。在 v6.4.0 之前的版本中，如果待导入的文件中包含这类文件，Lightning 将跳过对这类文件的导入。从 v6.4.0 起，Lightning 将认为这些文件使用了不支持的压缩格式，导致导入失败。 - 从 v6.4.0 开始，TiCDC 使用 Syncpoint 功能需要同步任务拥有下游集群的
SYSTEM_VARIABLES_ADMIN或者SUPER权限。
-
TiDB
-
TiKV
-
PD
- 热点均衡调度器 v2 版本算法成为正式功能，在特定场景下 v2 版本算法可以在配置的两个维度均取得更好的均衡效果，并减少无效调度 #5021 @HundunDM
- 改进 Operator step 超时机制，防止过早超时 #5596 @bufferflies
- 优化调度器在大集群下的性能 #5473 @bufferflies
- 支持使用非 PD 提供的外部时间戳 #5637 @lhy1024
-
TiFlash
-
Tools
-
TiDB Dashboard
-
Backup & Restore (BR)
-
TiCDC
- 支持同步 Exchange Partition 的 DDL 语句 #639 @asddongmen
- 提升 MQ sink 模块非攒批发送的性能 #7353 @hi-rustin
- 提升单表大量 Region 场景下 TiCDC puller 的性能 #7078 #7281 @sdojjy
- 支持在 Syncpoint 功能开启时在下游 TiDB 集群使用
tidb_enable_external_ts_read来读取历史数据 #7419 @asddongmen - 默认情况下关闭 safeMode 并开启大事务拆分功能，提升同步的稳定性 #7505 @asddongmen
-
TiDB Data Migration (DM)
- 移除 dmctl 中无用的
operate-source update指令 #7246 @buchuitoudegou - 解决了 TiDB 不兼容上游数据库的建表 SQL 导致 DM 全量迁移报错的问题，当上游的建表 SQL TiDB 不兼容时，用户可以提前在 TiDB 手动创建好目标表，让全量迁移任务继续运行 #37984 @lance6716
- 移除 dmctl 中无用的
-
TiDB Lightning
-
-
TiDB
- 修复新建索引之后有可能导致数据索引不一致的问题 #38165 @tangenta
- 修复
INFORMATION_SCHEMA.TIKV_REGION_STATUS表的权限问题 #38407 @CbcWestwolf - 修复
mysql.tables_priv表中grantor字段缺失的问题 #38293 @CbcWestwolf - 修复公共表表达式在 join 时可能得到错误结果的问题 #38170 @wjhuang2016
- 修复公共表表达式在 union 时可能得到错误结果的问题 #37928 @YangKeao
- 修复监控面板 transaction region num 信息不准确的问题 #38139 @jackysp
- 修复
tidb_constraint_check_in_place_pessimistic可能影响内部事务问题，修改该变量作用域为 SESSION #38766 @ekexium - 修复条件在某些场景下被错误下推至 projection 的问题 #35623 @Reminiscent
- 修复
AND和OR条件的isNullRejected检查错误导致查询结果错误的问题 #38304 @Yisaer - 修复外连接消除时没有考虑
GROUP_CONCAT内部的ORDER BY导致查询出错的问题 #18216 @winoros - 修复错误下推的条件被 Join Reorder 丢弃后导致查询结果错误的问题 #38736 @winoros
-
TiKV
-
PD
- 修复 Stream 超时问题，提高 Leader 切换的速度 #5207 @CabinfeverB
-
TiFlash
- 修复由于 PageStorage GC 未能正确清除 Page 删除标记导致 WAL 文件过大从而导致 TiFlash OOM 的问题 #6163 @JaySon-Huang
-
Tools
-
TiDB Dashboard
-
Backup & Restore (BR)
-
TiCDC
- 修复
changefeed query的输出中sasl-password显示为明文的问题 #7182 @dveeden - 修复在一个 etcd 事务中提交太多数据导致 TiCDC 服务不可用问题 #7131 @asddongmen
- 修复 redo log 文件可能被错误删除的问题 #6413 @asddongmen
- 修复 Kafka Sink V2 协议在同步宽表时性能回退的问题 #7344 @hi-rustin
- 修复 checkpoint ts 可能被提前推进的问题 #7274 @hi-rustin
- 修复 mounter 模块的日志级别设置不当导致 log 打印太多的问题 #7235 @hi-rustin
- 修复一个 TiCDC 集群可能存在两个 owner 的问题 #4051 @asddongmen
- 修复
-
TiDB Data Migration (DM)
- 修复 DM WebUI 产生错误
allow-list参数的问题 #7096 @zoubingwu - 修复 DM-worker 在启动、停止时有一定概率触发 data race 的问题 #6401 @liumengya94
- 修复当同步
UPDATE、DELETE语句且下游行数据不存在时，DM 静默忽略的问题 #6383 @GMHDBJD - 修复运行
query-status命令后未显示secondsBehindMaster字段的问题 #7189 @GMHDBJD - 修复更新 Checkpoint 时可能触发大事务的问题 #5010 @lance6716
- 修复在全量任务模式下，任务进入 sync 阶段且立刻失败时，DM 可能丢失上游表结构信息的问题 #7159 @lance6716
- 修复开启一致性校验时可能触发死锁的问题 #7241 @buchuitoudegou
- 修复任务预检查对
INFORMATION_SCHEMA表需要SELECT权限的问题 #7317 @lance6716 - 修复空的 TLS 配置导致报错的问题 #7384 @liumengya94
- 修复 DM WebUI 产生错误
-
TiDB Lightning
-
TiDB Dumpling
-
感谢来自 TiDB 社区的贡献者们：
- 645775992
- An-DJ
- AndrewDi
- erwadba
- fuzhe1989
- goldwind-ting（首次贡献者）
- h3n4l
- igxlin（首次贡献者）
- ihcsim
- JigaoLuo
- morgo
- Ranxy
- shenqidebaozi（首次贡献者）
- taofengliu（首次贡献者）
- TszKitLo40
- wxbty（首次贡献者）
- zgcbj