TiDB 6.5.0 Release Notes
发版日期：2022 年 12 月 29 日
TiDB 版本：6.5.0
TiDB 6.5.0 为长期支持版本 (Long-Term Support Releases, LTS)。
相比于前一个 LTS (即 6.1.0 版本)，6.5.0 版本包含 6.2.0-DMR、6.3.0-DMR、6.4.0-DMR 中已发布的新功能、提升改进和错误修复，并引入了以下关键特性：
- 添加索引加速特性 GA，添加索引的性能约提升为 v6.1.0 的 10 倍。
- TiDB 全局内存控制特性 GA，通过
tidb_server_memory_limit即可管理全局内存阈值。 - 支持高性能、全局单调递增的
AUTO_INCREMENT列属性 GA，兼容 MySQL。 FLASHBACK CLUSTER TO TIMESTAMP特性新增对 TiCDC 和 PITR 的兼容性支持，该特性已 GA。- 优化器引入的更精准的代价模型 Cost Model Version 2 GA，同时优化器增强索引合并 INDEX MERGE 功能对
AND连接的表达式的支持。 - 支持下推
JSON_EXTRACT()函数至 TiFlash。 - 支持密码管理策略，满足密码合规审计需求。
- TiDB Lightning 和 Dumpling 支持导入和导出压缩格式文件。
- TiDB Data Migration (DM) 的增量数据校验特性 GA。
- TiDB 快照备份支持断点续传，此外 PITR 的恢复性能提升了 50%，一般场景下 RPO 降低到 5 分钟。
- TiCDC 同步数据到 Kafka，吞吐从 4000 行每秒提升到 35000 行每秒，复制延迟降低到 2 秒。
- 提供行级别 Time to live (TTL) 管理数据生命周期（实验特性）。
- TiCDC 支持 Amazon S3、Azure Blob Storage、NFS 的对象存储（实验特性）。
本期话题：
6.5.0 版本上线，说说你最期待的特性是哪些？
活动奖励：
参与奖
参与话题讨论奖励 50 积分～
活动时间：
2022.12.30-2023.1.6 快来立 flag 吧～
更多 6.5.0 的介绍，请点击查看
新功能
SQL
- TiDB 添加索引的性能约提升为原来的 10 倍 (GA) #35983 @benjamin2037 @tangentaTiDB v6.3.0 引入了添加索引加速作为实验特性，提升了添加索引回填过程的速度。该功能在 v6.5.0 正式 GA 并默认打开，预期大表添加索引的性能提升约为原来的 10 倍。添加索引加速适用于单条 SQL 语句串行添加索引的场景，在多条 SQL 并行添加索引时仅对其中一条添加索引的 SQL 语句生效。
- 提供轻量级元数据锁，提升 DDL 变更过程 DML 的成功率 (GA) #37275 @wjhuang2016TiDB v6.3.0 引入了元数据锁作为实验特性，通过协调表元数据变更过程中 DML 语句和 DDL 语句的优先级，让执行中的 DDL 语句等待持有旧版本元数据的 DML 语句提交，尽可能避免 DML 语句的
Information schema is changed错误。该功能在 v6.5.0 正式 GA 并默认打开，适用于各类 DDL 变更场景。当集群从 v6.5.0 之前的版本升级到 v6.5.0 及之后的版本时，TiDB 默认自动开启该功能。如果需要关闭该功能，你可以将系统变量tidb_enable_metadata_lock设置为OFF。更多信息，请参考用户文档。 - 支持通过
FLASHBACK CLUSTER TO TIMESTAMP命令将集群快速回退到特定的时间点 (GA) #37197 #13303 @Defined2014 @bb7133 @JmPotato @Connor1996 @HuSharp @CalvinNeoTiDB v6.4.0 引入了FLASHBACK CLUSTER TO TIMESTAMP语句作为实验特性，支持在 Garbage Collection (GC) life time 内快速回退整个集群到指定的时间点。该功能在 v6.5.0 新增对 TiCDC 和 PITR 的兼容性支持并正式 GA，适用于快速撤消 DML 误操作、支持集群分钟级别的快速回退、支持在时间线上多次回退以确定特定数据更改发生的时间。更多信息，请参考用户文档。 - 完整支持包含
INSERT、REPLACE、UPDATE和DELETE的非事务 DML 语句 #33485 @ekexium在大批量的数据处理场景，单一大事务 SQL 处理可能对集群稳定性和性能造成影响。非事务 DML 语句将一个 DML 语句拆成多个 SQL 语句在内部执行。拆分后的语句将牺牲事务原子性和隔离性，但是对于集群的稳定性有很大提升。TiDB 从 v6.1.0 开始支持非事务DELETE语句，v6.5.0 新增对非事务INSERT、REPLACE和UPDATE语句的支持。更多信息，请参考非事务 DML 语句 和BATCH语句。 - 支持 Time to live (TTL)（实验特性）#39262 @lcwangchaoTTL 提供了行级别的生命周期控制策略。在 TiDB 中，设置了 TTL 属性的表会根据配置自动检查并删除过期的行数据。TTL 设计的目标是在不影响在线读写负载的前提下，帮助用户周期性且及时地清理不需要的数据。更多信息，请参考用户文档。
- 支持通过
INSERT INTO SELECT语句保存 TiFlash 查询结果（实验特性）#37515 @gengliqi从 v6.5.0 起，TiDB 支持下推INSERT INTO SELECT语句中的SELECT子句（分析查询）到 TiFlash，你可以将 TiFlash 的查询结果方便地保存到INSERT INTO指定的 TiDB 表中供后续分析使用，起到了结果缓存（即结果物化）的效果。例如：
INSERT INTO t2 SELECT Mod(x,y) FROM t1;
在实验特性阶段，该功能默认关闭。要开启此功能，请设置系统变量 tidb_enable_tiflash_read_for_write_stmt 为 ON。使用该特性时，INSERT INTO 指定的结果表没有特殊限制，你可以自由选择是否为该表添加 TiFlash 副本。该特性典型的使用场景包括：
- 使用 TiFlash 做复杂分析
- 需重复使用 TiFlash 查询结果或响应高并发的在线请求
- 与查询的输入数据相比，所需的结果集比较小，推荐 100 MiB 以内更多信息，请参考用户文档。
- 支持绑定历史执行计划（实验特性）#39199 @fzzf678受 SQL 语句执行时各种因素的影响，之前最优的执行计划偶尔会被新的执行计划替代，进而影响 SQL 性能。在这种场景下，最优的执行计划可能仍旧在 SQL 执行历史中，还没有被清除。在 v6.5.0 中，TiDB 扩展了
CREATE [GLOBAL | SESSION] BINDING语句中的绑定对象，支持根据历史执行计划创建绑定。当 SQL 语句的执行计划发生改变时，只要原来的执行计划仍然在 SQL 执行历史内存表（例如，statements_summary）中，就可以在CREATE [GLOBAL | SESSION] BINDING语句中通过指定plan_digest绑定原来的执行计划，快速恢复 SQL 性能。此方式可以简化执行计划突变问题的处理，提升运维效率。更多信息，请参考用户文档。
安全
- 支持密码复杂度策略 #38928 @CbcWestwolfTiDB 启用密码复杂度策略功能后，在用户设置密码时，TiDB 会检查密码长度、大写和小写字符个数、数字字符个数、特殊字符个数、密码字典匹配、是否与用户名相同等，以此确保用户设置了安全的密码。TiDB 支持密码强度检查函数
VALIDATE_PASSWORD_STRENGTH()，用于判定一个给定密码的强度。更多信息，请参考用户文档。 - 支持密码过期策略 #38936 @CbcWestwolfTiDB 支持密码过期策略，包括手动密码过期、全局级别自动密码过期、账户级别自动密码过期。启用密码过期策略功能后，用户必须定期修改密码，防止密码长期使用带来的泄露风险，提高密码安全性。更多信息，请参考用户文档。
- 支持密码重用策略 #38937 @keeplearning20221TiDB 支持密码重用策略，包括全局级别密码重用策略、账户级别密码重用策略。启用密码重用策略功能后，用户不能使用最近一段时间使用过的密码或最近几次使用过的密码，以此降低密码的重复使用带来的泄漏风险，提高密码安全性。更多信息，请参考用户文档。
- 支持密码连续错误限制登录策略 #38938 @lastincisorTiDB 启用密码连续错误限制登录策略功能后，当用户登录时，如果连续多次密码错误，账户将被临时锁定，达到锁定时间后将自动解锁。更多信息，请参考用户文档。
可观测性
- TiDB Dashboard 在 Kubernetes 环境支持独立 Pod 部署 #1447 @SabaPingTiDB v6.5.0 且 TiDB Operator v1.4.0 之后，在 Kubernetes 上支持将 TiDB Dashboard 作为独立的 Pod 部署。在 TiDB Operator 环境，可直接访问该 Pod 的 IP 来打开 TiDB Dashboard。独立部署 TiDB Dashboard，可以获得以下收益：
- TiDB Dashboard 的计算将不会再对 PD 节点有压力，可以更好的保障集群运行。
- 如果 PD 节点因异常不可访问，也还可以继续使用 TiDB Dashboard 进行集群诊断。
- 在开放 TiDB Dashboard 到外网时，不用担心 PD 中的特权端口的权限问题，降低集群的安全风险。更多信息，请参考 TiDB Operator 部署独立的 TiDB Dashboard。
- Performance Overview 面板中新增 TiFlash 和 CDC (Change Data Capture) 面板 #39230 @dbsidTiDB 从 v6.1.0 起在 Grafana 中引入了 Performance Overview 面板，为 TiDB、TiKV、PD 提供了系统级别的总体性能诊断入口。在 v6.5.0 中，Performance Overview 面板中新增了 TiFlash 和 CDC 面板。通过此次新增，从 v6.5.0 起，使用单个 Performance Overview 面板即可分析 TiDB 集群中所有组件的性能。TiFlash 和 CDC 面板重新编排了 TiFlash 和 TiCDC 相关的监控信息，可以帮助你大幅提高 TiFlash 和 TiCDC 的性能分析和故障诊断效率：
- 通过 TiFlash 面板，你可以直观地了解 TiFlash 集群的请求类型、延迟分析和资源使用概览。
- 通过 CDC 面板，你可以直观地了解 TiCDC 集群的健康状况、同步延迟、数据流和下游写入延迟等信息。更多信息，请参考用户文档。
性能
- 索引合并 INDEX MERGE 功能支持
AND连接的表达式 #39333 @guo-shaoge @time-and-fate @hailanwhu在 v6.5.0 前，TiDB 只支持对OR连接词的过滤条件使用索引合并特性。自 v6.5.0 起，TiDB 支持对于在WHERE子句中使用AND连接的过滤条件使用索引合并特性。TiDB 的索引合并至此可以覆盖更多普遍的查询过滤条件组合，不再限定于并集（OR）关系。v6.5.0 仅支持优化器自动选择OR条件下的索引合并。要开启对于AND连接的索引合并，你需要使用USE_INDEX_MERGEHint。关于索引合并功能的更多信息，请参阅 v5.4.0 Release Notes，以及优化器相关的用户文档 - 新增支持下推以下 JSON 函数至 TiFlash #39458 @yibin87
->->>JSON_EXTRACT()JSON 格式为应用设计提供了灵活的建模方式，目前越来越多的应用采用 JSON 格式进行数据交换和数据存储。通过将 JSON 函数下推至 TiFlash，你可以提高 JSON 类型数据的分析效率，拓展 TiDB 实时分析的应用场景。
- 新增支持下推以下字符串函数至 TiFlash #6115 @xzhangxian1008
regexp_likeregexp_instrregexp_substr
- 新增全局 Hint 干预视图内查询计划的生成 #37887 @Reminiscent部分视图访问的场景需要用 Hint 对视图内查询的执行计划进行干预，以获得最佳性能。在 v6.5.0 中，TiDB 允许针对视图内的查询块添加全局 Hint，使查询中定义的 Hint 能够在视图内部生效。该特性为包含复杂视图嵌套的 SQL 提供 Hint 的注入手段，增强了执行计划控制能力，进而稳定复杂 SQL 的执行性能。全局 Hint 通过查询块命名和 Hint 引用来开启。更多信息，请参考用户文档。
- 支持将分区表的排序操作下推至 TiKV #26166 @winoros分区表特性在 v6.1.0 正式 GA 后，TiDB 仍然在持续提升分区表相关的性能。在 v6.5.0 中，TiDB 支持将
ORDER BY和LIMIT等排序操作下推至 TiKV 进行计算和过滤，降低网络 I/O 的开销，提升了使用分区表时 SQL 的性能。 - 优化器引入更精准的代价模型 Cost Model Version 2 (GA) #35240 @qw4990TiDB v6.2.0 引入了代价模型 Cost Model Version 2 作为实验特性，通过更准确的代价估算方式，有利于最优执行计划的选择。尤其在部署了 TiFlash 的情况下，Cost Model Version 2 自动选择合理的存储引擎，避免过多的人工介入。经过一段时间真实场景的测试，这个模型在 v6.5.0 正式 GA。新创建的集群将默认使用 Cost Model Version 2。对于升级到 v6.5.0 的集群，由于 Cost Model Version 2 可能会改变原有的执行计划，在经过充分的性能测试之后，你可以通过设置变量
tidb_cost_model_version = 2使用新的代价模型。Cost Model Version 2 成为正式功能大幅提升了 TiDB 优化器的整体能力，并使 TiDB 切实地向更加强大的 HTAP 数据库演进。更多信息，请参考用户文档。 - TiFlash 对获取表行数的操作进行优化 #37165 @elsa0520在数据分析的场景中，通过无过滤条件的
COUNT(*)获取表的实际行数是一个常见操作。TiFlash 在 v6.5.0 中优化了COUNT(*)的改写，自动选择带有“非空”属性且列定义最短的列进行计数，这样可以有效降低 TiFlash 上发生的 I/O 数量，进而提升获取表行数的执行效率。
稳定性
- TiDB 全局内存控制成为正式功能（GA）#37816 @wshwsh12TiDB v6.4.0 引入了全局内存控制作为实验特性。自 v6.5.0 起，全局内存控制成为正式功能，能够跟踪到 TiDB 中主要的内存消耗。当全局内存消耗达到
tidb_server_memory_limit所定义的阈值时，TiDB 会尝试 GC 或取消 SQL 操作等方法限制内存使用，保证 TiDB 的稳定性。需要注意的是，会话中事务所消耗的内存（由配置项txn-total-size-limit设置最大值）如今被内存管理模块跟踪：当单个会话的内存消耗达到系统变量tidb_mem_quota_query所定义的阀值时，将会触发系统变量tidb_mem_oom_action所定义的行为（默认为CANCEL，即取消操作）。为了保证向前兼容，当配置txn-total-size-limit为非默认值时，TiDB 仍旧会保证事务可以使用到txn-total-size-limit所设定的内存量而不被取消。在使用 v6.5.0 及以上版本时，建议移除配置项txn-total-size-limit，取消对事务内存做单独的限制，转而使用系统变量tidb_mem_quota_query和tidb_server_memory_limit对全局内存进行管理，从而提高内存的使用效率。更多信息，请参考用户文档。
易用性
- 完善
EXPLAIN ANALYZE输出结果中 TiFlash 的 TableFullScan 算子的执行信息 #5926 @hongyunyanEXPLAIN ANALYZE语句可以输出执行计划及运行时的统计信息。在 v6.5.0 中，TiFlash 对 TableFullScan 算子的执行信息进行了完善，补充了 DMFile 相关的执行信息。你可以更加直观地查看 TiFlash 的数据扫描状态信息，方便进行性能分析。更多信息，请参考用户文档。 - 支持将执行计划打印为 JSON 格式 #39261 @fzzf678在 v6.5.0 中，TiDB 扩展了执行计划的打印格式。通过在
EXPLAIN语句中指定FORMAT = "tidb_json"能够将 SQL 的执行计划以 JSON 格式输出。借助这个能力，SQL 调试工具和诊断工具能够更方便准确地解读执行计划，进而提升 SQL 诊断调优的易用性。更多信息，请参考用户文档。
MySQL 兼容性
- 支持高性能、全局单调递增的
AUTO_INCREMENT列属性 (GA) #38442 @tiancaiamaoTiDB v6.4.0 引入了AUTO_INCREMENT的 MySQL 兼容模式作为实验特性，通过中心化分配自增 ID，实现了自增 ID 在所有 TiDB 实例上单调递增。使用该特性能够更容易地实现查询结果按自增 ID 排序。该功能在 v6.5.0 正式 GA。使用该功能的单表写入 TPS 预期超过 2 万，并支持通过弹性扩容提升单表和整个集群的写入吞吐。要使用 MySQL 兼容模式，你需要在建表时将AUTO_ID_CACHE设置为1。
CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 1;
更多信息，请参考用户文档。
数据迁移
- 支持导出和导入 gzip、snappy、zstd 三种压缩格式的 SQL、CSV 文件 #38514 @lichunzhuDumpling 支持将数据导出为 gzip、snappy、zstd 三种压缩格式的 SQL、CSV 的压缩文件。TiDB Lightning 也支持导入这些格式的压缩文件。有这个功能之前，导出数据或者导入数据都需要较大的存储空间，用于存储已经导出或即将导入的 CSV 和 SQL 文件，需要较高的存储成本。该功能发布后，通过压缩数据文件，可以大幅降低存储成本。更多信息，请参考用户文档。
- 优化了 binlog 解析能力 #924 @gmhdbjd该功能允许过滤掉不在迁移任务里的库和表对象的 binlog event，不做解析，从而提升解析效率和稳定性。该策略在 v6.5.0 版本默认生效，无需额外操作。有这个功能之前，即使仅迁移几张表，也需要解析上游整个 binlog 文件，即仍要解析该 binlog 文件中不需要迁移的表的 binlog event，效率较低。同时，如果不在迁移任务里的库表的 binlog event 不支持解析，还会导致任务失败。推出该功能后，通过只解析在迁移任务里的库表对象的 binlog event，可以大大提升 binlog 解析效率，提升任务稳定性。
- Disk quota 功能 GA #446 @buchuitoudegou你可以为 TiDB Lightning 配置磁盘配额 (disk quota)。当磁盘配额不足时，TiDB Lightning 会暂停读取源数据以及写入临时文件，而是优先将已经完成排序的 key-value 写入 TiKV。TiDB Lightning 删除本地临时文件后，再继续导入过程。有这个功能之前，TiDB Lightning 在使用物理模式导入数据时，会在本地磁盘创建大量的临时文件，用来对原始数据进行编码、排序、分割。当用户本地磁盘空间不足时，TiDB Lightning 会由于写入文件失败而报错退出。推出该功能后，可避免 TiDB Lightning 任务写满本地磁盘。更多信息，请参考用户文档。
- DM 增量数据校验的功能 GA #4426 @D3Hunter在将增量数据从上游迁移到下游数据库的过程中，数据的流转有小概率导致错误或者丢失的情况。对于需要依赖强数据一致的场景，如信贷、证券等业务，你可以在数据迁移完成之后再对数据进行全量校验，确保数据的一致性。然而，在某些增量复制的业务场景下，上游和下游的写入是持续的、不会中断的。由于上下游的数据在不断变化，导致用户难以对表里的全部数据进行一致性校验。过去，需要中断业务才能进行全量数据校验，会影响业务。推出该功能后，你无需中断业务即可实现增量数据校验。更多信息，请参考用户文档。
数据共享与订阅
- TiCDC 支持输出变更数据至 storage sink（实验特性）#6797 @zhaoxinyuTiCDC 支持将 changed log 输出到 Amazon S3、Azure Blob Storage、NFS，以及兼容 Amazon S3 协议的存储服务中。Cloud storage 价格便宜，使用方便。对于不使用 Kafka 的用户，可以选择使用 storage sink。使用该功能，TiCDC 会将 changed log 保存到文件，发送到存储系统中。用户自研的消费程序定时从存储系统读取新产生的 changed log 进行数据处理。Storage sink 支持格式为 canal-json 和 csv 的 changed log。更多信息，请参考用户文档。
- TiCDC 支持在两个 TiDB 集群之间进行双向复制 #38587 @xiongjiwei @asddongmenTiCDC 支持在两个 TiDB 集群之间进行双向复制。如果业务上需要构建异地多活的 TiDB 集群架构，可以使用该功能作为 TiDB 多活的解决方案。只要为 TiDB 集群到另一个 TiDB 集群的 TiCDC 同步任务配置
bdr-mode = true参数，就可以实现两个 TiDB 集群之间的数据相互复制。更多信息，请参考用户文档。 - TiCDC 支持在线更新 TLS 证书 tiflow#7908 @CharlesCheung96为确保系统数据安全，用户会对系统使用的证书设置相应的过期策略，经过固定的时间后会将系统使用的证书更换成新证书。TiCDC v6.5.0 支持在线更新 TLS 证书，在不影响同步的任务的前提下，TiCDC 会自动检测和更新证书，无需用户手动操作，满足用户对证书更新的需求。
- TiCDC 性能提升 #7540 #7478 #7532 @sdojjy @3AceShowHand在 TiDB 场景测试验证中，TiCDC 的性能得到了比较大提升。单台 TiCDC 节点能处理的最大行变更吞吐可以达到 30K rows/s，同步延迟降低到 10s。即使在常规的 TiKV/TiCDC 滚动升级场景，同步延迟也小于 30s；在容灾场景测试中，打开 TiCDC redo log 和 Syncpoint 后，吞吐从 4000 行每秒提升到 35000 行每秒，容灾复制延迟可以保持在 2s。
备份和恢复
- TiDB 快照备份支持断点续传 #38647 @LeavrthTiDB 快照备份功能支持断点续传。当 BR 遇到可恢复的错误时会进行重试，但是超过固定重试次数之后会备份退出。断点续传功能允许对持续更长时间的可恢复故障进行重试恢复，比如几十分钟的网络故障。需要注意的是，如果你没有在 BR 退出后一个小时内完成故障恢复，那么还未备份的快照数据可能会被 GC 机制回收，而造成备份失败。更多信息，请参考用户文档。
- PITR 性能大幅提升 @joccauPITR 恢复的日志恢复阶段，单台 TiKV 的恢复速度可以达到 9 MiB/s，提升了 50%，并且恢复速度可扩展，有效地降低容灾场景的 RTO 指标；容灾场景的 RPO 优化到 5 分钟，在常规的集群运维，如滚动升级，单 TiKV 故障等场景下，可以达到 RPO = 5 min 的目标。
- TiKV-BR 工具 GA，支持 RawKV 的备份和恢复 #67 @pingyu @haojinmingTiKV-BR 是一个 TiKV 集群的备份和恢复工具。TiKV 可以独立于 TiDB，与 PD 构成 KV 数据库，此时的产品形态为 RawKV。TiKV-BR 工具支持对使用 RawKV 的产品进行备份和恢复，也支持将 TiKV 集群中的数据从
API V1备份为API V2数据，以实现 TiKV 集群api-version的升级。更多信息，请参考用户文档。
