TiDB

• 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。

• 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

• Real-time HTAP 场景随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

• 数据汇聚、二次加工处理的场景当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。 ^[3]

SQL

• 支持通过 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 @CalvinNeo

  FLASHBACK 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 @erwadba

  FLASHBACK 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 数据同步的实际进度。

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

MySQL 兼容性

• 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 @tiancaiamao

  TiDB 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 表。你可以在该表中查看用户的注释和属性信息。