{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/tidb-6.5-release",
"result": {"pageContext":{"blog":{"id":"Blogs_451","title":"TiDB 6.5 LTS 版本发布","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"在 2023 伊始，我们很高兴向大家宣布，TiDB 6.5 LTS 版本已经发布了。","body":"在 2023 伊始，我们很高兴向大家宣布，TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版（上一个是 [TiDB 6.1](/blog/tidb-6.1-release)），除了携带了诸多备受期待的新特性，同时也将得到 TiDB 开发社区的长期维护，是推荐企业级用户采用的最新版本。\n\n\n\n\n\n在这个版本中，TiDB 专注于如下几个主题：\n\n- **产品易用性进一步提升**\n- **内核不断打磨，更加成熟**\n- **多样化的灾备能力**\n- **应用开发者生态构建**\n\n相信长期关注我们的朋友已经发现，这些主题似曾相识。的确如此，TiDB 近年的发展几乎都围绕着它们开展。我们期望 TiDB 成为**更易用，对开发者更友好，且更成熟的企业级数据库**，而这个追求也并没有尽头。\n\n## 产品易用性进一步提升\n\n大家也许不止一次听说过，易用性之于 TiDB 是非常关键的理念。毕竟，TiDB 伊始是为了解决分库分表带来的麻烦，这也使得易用性在 TiDB 研发过程中贯穿始终。在新版本中，我们提供了更多的让用户解放心智的能力。\n\n### AND 运算下的索引归并读取\n\n对于数据服务和洞察场景，用户往往会基于诸多查询条件的组合进行数据筛选。例如在物流场景中，用户可能会根据下单日，仓库 ID，转运人，送达日，目标地址等等不同维度进行筛选再分析。而这些条件单独来看，并不一定具备很好的选择性，只有组合起来才能将数据限定在一个小范围。如果条件的组合不多，我们尚可使用特定的组合索引覆盖，但很可能在这类场景中，组合以数十记，完全无法为每个组合都创建特定索引。在新版本中，TiDB 支持根据 AND 条件组合同时选中多组索引，并计算它们的交集再读取实际表数据。这种能力，使得用户可以仅仅为单列创建少量索引，以达到更好的选择性以及更优的性能。\n\n\n\n### 集群闪回\n\n有时候，用户会希望整个集群快速恢复到之前的某个时间点。例如，由于游戏服务器新版本数据设定问题，将一把绝世好剑设定为 1 元，造成新版发布后一小时内人手一把。若仅仅如此也就算了，开发者可以很容易回收或这个道具，但这种事故还有次生灾害，例如稀有 Boss 被滥杀，稀有掉落随之泛滥，整个游戏内容崩坏。这时候作为游戏设计师，你可能会希望时间能回到犯错之前的那一刻，让你修正那个令人追悔莫及的错误。在新版本中，TiDB 就提供了这个能力，它支持用简单一条命令向 GC 时间内的任意时间点进行全集群闪回，就像下面这样。\n\n```sql\nFLASHBACK CLUSTER TO TIMESTAMP '2022-09-28 17:24:16'; \n```\n\n我们当然希望这不会是一个常见的状况，但这并不表示需要闪回的时机千年难遇：闪回能力也可用于日常操作，例如将测试环境恢复到测试开始前的状态，以供反复使用。\n\n### 完整的大事务自动拆分支持\n\n在前序版本中，我们支持了针对删除的大事务自动拆分支持。而在新版本中，TiDB 完整支持了针对插入和修改的大事务拆分。在以往版本中，TiDB 用户经常要面对的一个问题就是，一些大规模的数据变更维护操作，例如过期数据删除，大范围数据修订，或者根据查询结果回写数据等操作，会遇到超过 TiDB 单条事务上限的问题，这是由于 TiDB 单一事务需要由单一 TiDB Server 作为提交方而带来的限制，这时候用户往往不得不手动想办法拆小事务以绕过该限制。但在实际使用中，上述类型的数据变更未必真的需要作为单一事务确保原子性，例如数据淘汰和数据修订，只要最终执行完成，哪怕事务被拆开多次执行也并不会影响使用。在 TiDB 6.5 中，我们提供了将大事务自动拆分的能力，例如按照 t1.id 以 10000 条为大小分批数据更新，可以简单使用如下语句完成：\n\n```sql\nBATCH ON t1.id LIMIT 10000 update t1 join t2 on t1.a=t2.a set t1.a=t1.a*1000;\n```\n\n更详细的说明请[参考文档](https://docs.pingcap.com/zh/tidb/stable/non-transactional-dml)。\n\n### TiFlash 结果物化（实验特性）\n\nTiFlash 在过往版本中有一个很大的缺憾是无法在读写事务中使用：经常用户希望将 TiFlash 的计算结果进行回写以供高并发读取（类似物化效果）。从 v6.5.0 起，TiFlash 支持通过 INSERT SELECT 语句回写结果进行物化，节省系统资源并提高响应速度。\n\n```sql\nINSERT INTO top_payments SELECT MAX(amount) FROM payments;\n```\n\n在执行上述 INSERT INTO SELECT 语句时，TiDB 可以将 SELECT 子查询下推到 TiFlash 以提供高速分析计算，并将返回结果通过 INSERT INTO 可以保存到指定的 TiDB 表中。值得一提的是，该功能结合前述大事务拆分可以实现大量结果集物化。\n\n### 高性能全局单调递增 AUTO_INCREMENT 列\n\nTiDB 作为一款分布式数据库，以往在使用 AUTO INCREMENT 列创建主键时，仅保证在每个 TiDB 实例中序列递增，而跨 TiDB 实例则无法保证。但实际使用中，用户仍然经常会遇到需要严格单调递增主键的时候，例如以主键隐式代表时间维度，确定事件发生顺序。在 6.4 版本中，我们加入了高性能的全局单调递增主键的支持，以兼容 MySQL 的行为。该模式下，TiDB 将采取中心化的主键分配以确保单调递增，即使跨 TiDB 实例访问，ID 也不会出现回退，且针对其的写入也可轻松达到数万的 TPS。\n\n### 使用 TTL (Time to Live) 来周期性地删除过期数据（实验特性）\n\n维护数据的生命周期在 TB 以上规模下并不是很容易的事情：由于数据规模大，寻找并清理过期的数据往往需要消耗相当的算力，有时用户为了更快清理数据甚至被迫使用分区表，以删除分区的方式来进行快速清理。更麻烦的是，用户需要维护特定的任务以不断定期淘汰数据。在新版本中，TiDB 提供了 Time to Live (TTL) 能力，使得用户可以设定行级别的生命周期控制策略。通过为表设置 TTL 属性，TiDB 可以周期性地自动检查并清理表中的过期数据。当开启时，TTL 会以表为单位，并发地分发不同的任务到不同的 TiDB 实例节点上，进行并行删除处理，且不影响集群性能。更详细的说明请[参考文档](https://docs.pingcap.com/zh/tidb/stable/time-to-live)。\n\n## 内核关键特性打磨和增强\n\nTiDB 包含繁多的特性集合，但其中有些仍需不断打磨，例如 JSON 虽然已获支持许久，但实际能力却尚需完善。在新版本中，我们针对重要特性集合用力打磨，以期提供给用户更「丝滑」的体验，让 TiDB 的重大特性以更完善的方式呈现在用户面前，也让 TiDB 演进方式更稳重更有质量。\n\n**首先是 DDL 加强**。支持在线 DDL 是 TiDB 的核心优势之一，在过往一年中，我们加入了对并行 DDL 的支持，使得以往在 SaaS 等多租户场景因 DDL 串行执行互相阻塞导致的 DDL 语句间执行效率低的问题得以解决，通过引入 Metadata Lock 基本消除了 DDL 干扰 DML 的情况。在新的 6.5 版本中，TiDB 支持了类似 Lightning 注入 SST 的设计，针对需要追溯的历史数据直接使用 SST 构建的方式进行生成，大幅提高了 DDL 的构建速度，最快可达 **10 倍提升**。\n\n如下图所示，以 TiDB 6.1 版本为基准值，新版除了取得了数量级的提速，且对比 CockroachDB v22.2 和当前版的 AWS Aurora 也快 2-3 倍。\n\n\n\n**其次是 JSON 的支持打磨**。JSON 对于需要灵活数据结构的场景非常重要，因此在移动端，游戏开发等场景中广泛使用。从 6.2 版本以来，TiDB 陆续引入了完整的 MySQL 5.7 兼容函数，针对 JSON 的表达式索引支持，更多的生态工具兼容。新版本支持将 JSON 函数 \"->\"、\"->>\"、\"JSON_EXTRACT()\" 下推至 TiFlash，可以提高 JSON 类型数据的分析效率，拓展 TiDB 实时分析的应用场景。\n\n**再者是 TiDB 全局内存控制**。自 v6.5.0 起，TiDB 全局内存控制已能够跟踪到 TiDB 中主要的内存消耗。当单个会话的内存消耗达到系统变量 `tidb_mem_quota_query` 所定义的阈值时，将会触发系统变量 `tidb_mem_oom_action` 所定义的行为 (默认为 `CANCEL`，即取消操作)。当全局内存消耗达到 `tidb_server_memory_limit` 所定义的预设值时，TiDB 会尝试 GC 或取消 SQL 操作等方法限制内存使用，保证 TiDB 的稳定性，对内存的使用效率也更加高效。 \n\n**最后是降低累积的悲观锁对性能的影响**。 在一部分交易系统，尤其是银行业务中，客户应用会在悲观事务中利用 select for update 先锁定一条记录，从而达到对数据一致性的保护，减少事务中后续操作失败的可能，比如\n\n```sql\nBEGIN;\nSELECT c FROM sbtest1 WHERE id = 100 FOR UPDATE; \nUPDATE sbtest1 SET k = k + 1 WHERE k = ?; \nCOMMIT;\n```\n\n而在 TiDB 中，对一行记录反复的 select for update，会造成这条记录的查询性能下降。 在 v6.5.0 中，我们对这部分机制进行了优化， 通过记录连续的锁标记，降低了累积的悲观锁对查询性能的影响，QPS 可大幅提升 10 倍以上。\n\n## 多样化的灾备能力\n\n在过往版本中，TiDB 主要依赖 BR 进行静态的备份恢复，而在 6.2 之后的新版中，TiDB 提供了 PITR 能力，使得数据库可以更灵活地恢复到任意时间点。\n\nTiDB PITR（Point-in-Time Recovery）是结合了 BR 和变更捕获（Change Data Capture）两种能力的灾备特性。以往 BR 的静态灾备只能将数据恢复到备份的时间点，如果要更提供针对更新和更多时间点的恢复，则相应需要提高备份频率。这不但会加重备份对在线业务的负担，也需要更多存储成本。使用 PITR 则可以摆脱这个烦恼，用户无需不断进行全量备份，而是可经由一个全量备份结合增量共同完成针对任意时间点的数据恢复。\n\n\n\n经过半年左右的持续改进，在新版本中，我们减少了 PITR 备份文件大小和数量，加强了稳定性，提升了性能。 例如：确保在绝大多数异常场景下 RPO < 5mins, 单个 TiKV 的备份速度达到100MB/s等。\n\n与此同时，在 6.5 版本中，TiCDC 的吞吐获得了得了至数倍的提升。通过对 TiCDC 内部的设计和实现的不断优化，针对数据复制场景，当下游为 Kafka 集群时，针对大单表场景的吞吐量得到了极大的提升，单个 TiCDC 节点可以支持35k row/s QPS，吞吐量可以达到 50MB/s，并将延迟控制在 2 秒左右，而内存使用量只有之前版本的50%左右。 针对跨区域主备集群容灾场景，TiCDC 单个节点的吞吐量可以达到 30MB/s，并且其延迟也可以稳定在 2 秒左右，稳定性大幅度提高。\n\n其次，在6.5 版本中，DM 正式发布了在数据迁移过程中的增量数据持续校验功能，该特性只对新增或变更的数据进行校验，而不是对整个数据集进行校验，在确保数据迁移过程的准确性和可靠性的同时，大大减少数据校验的时间和资源消耗。尤其是在迁移一些重要系统时，该特性可以让数据迁移过程更加安全。\n\n除此以外，新版本支持了在下游集群使用水位线进行一致性读取的能力：在新版本中，TiCDC 可以在向下游写入时提供特殊的时间戳，而下游集群则可以自动使用该时间戳进行一致性读取而无需担心读到的事务不完整。这使得下游集群在需要严苛事务保证的场景下，也可以良好承担读流量分流的职责。\n\n\n\n## 应用开发者生态构建\n\n在以往版本中，TiDB 更强调 DBA 的使用体验。但在近期的更新中，你也许已经发现我们逐渐开始聚焦 DBA 以外的应用开发者体验。在新版中，我们强化了应用开发所需的生态环境构建，例如这半年来 TiDB 通过增加对 Savepoint，User Level Lock，Multiple Schema Change 等功能的支持，完善了针对常见应用框架 django，prisma 等的支持。与此同时，我们也引入了更多上下游生态厂商的战略合作：Vercel，Hashicorp，Retool 等。在 6.5 版本中，TiCDC 增加了针对向 Object Storage 写入的支持。对象存储是一种面向云的存储服务，具有高可扩展性、高可用性、低成本等优势。使用 TiCDC 将数据同步到对象存储，可以帮助用户实现数据的长期存储、数据的跨区域复制等目的。另外，这使得 TiDB 在云环境下能直接打通向数仓和数据湖环境的通路。更好的生态支持，将使得开发者在使用 TiDB 构建应用时，拥有更多选择，也更简便。\n\n## 总结\n\n作为 TiDB 版本 6 的第二个长期支持版，TiDB 6.5 已经发布。我们希望借助这个版本为更多用户提供更易用且更成熟的企业级数据库。更详细的变更情况请参阅 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-6.5.0)。欢迎各位和我们一起开启新的[奇妙旅程](https://docs.pingcap.com/zh/tidb/stable/quick-start-with-tidb)。","date":"2023-01-04","author":"马晓宇","fillInMethod":"writeDirectly","customUrl":"tidb-6.5-release","file":null,"relatedBlogs":[{"relatedBlog":{"body":"\n\n我们很高兴向大家宣布，TiDB 6.1 于 6 月 13 日发布，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support，简称 LTS）。\n\n\n\n## 长期支持版\n\n在两个月前发布 TiDB 6.0 版本时，我们提过在新发版流程中，我们引入了面向企业级用户的 LTS 版本的概念，与之相对的是开发里程碑版本（Development Milestone Release，简称 DMR）。引入这两种概念是为了让 TiDB 的发版节奏能兼顾快速变化的市场需求以及企业级用户对稳定性的要求。\n\n我们重新思考了发版模型，最后选择了长期支持版结合开发里程碑版的方式：我们保持 2 个月左右一次发版的节奏，以期快速应对市场节奏，但不再对所有发布进行长期维护，而是以半年左右为节奏拣选其中一个版本作为 LTS 长期支持版本。针对 LTS 版本我们提供针对问题的修复补丁而不再合并新功能。与此相对的，DMR 版本则保持快速发版的节奏，不断发布新特性，让用户所需的新需求不必等待很久（但并不提供基于 DMR 的问题修复）。对于用户而言，在没有特定需求开发的情况下，可以选择最新的 LTS 版本投产；如果需求某个 DMR 发布的新功能，则可以选择该版本进行 PoC 以及试运行，待到对应的 LTS 版本发布后升级 TiDB 到稳定生产状态。这样快慢结合的方式，可以最大限度兼顾快速迭代和稳定投产两方面的需求。\n\n对应 LTS 稳定版的主旨，6.1 版本中携带了重要的稳定性更新：\n\n1. 提升 TiKV 高压场景下的内存稳定性。\n2. 解决了由于 Raft Log 复制流量过大导致的 OOM 问题。\n3. 解决了在高压场景下宕机后重启过程中长时间持续反复 OOM 的问题。\n4. 完善了 TiDB Server 内存使用跟踪统计，加强查询内存使用配额限制。\n5. 优化了部分统计信息内存使用。\n\n另外，新版本也包含了 42 个问题修复和 20 个改进提升。\n\n## 是 LTS，也有新惊喜\n\nTiDB 6.1 除了作为第一个推荐企业级用户投产的 6 系版本，本身也携带了诸多强大的特性。\n\n### HTAP 基础能力提升\n\n在新版本中，部分分区表的实验特性 GA，且分析引擎加入了分区表和窗口函数支持。\n\n让我们先来看看分区表：我们在版本 5 中引入了 List 分区和动态裁剪特性，但一直保持实验特性状态。更重要的是，由于旧有的分区静态裁剪在 MPP 下表现欠佳，因此 TiFlash 引擎一直以来并未完整支持分区表特性。这次新发布中，我们宣布 List 分区 / 分区动态裁剪以及 MPP 模式下的分区表支持 GA。对于分区表本身在此无需过多赘述，各位可以参考官方文档，我们单独说下分析引擎下的分区表支持。\n\n对于列存引擎而言，由于并不支持类似行存的细粒度索引，仅仅依靠粗粒度索引并不能满足数据过滤需求。而分区表作为列存下最高效的数据过滤手段，是分析场景下需求优先级非常高的特性。例如在订单管理场景下，用户的数据天然可以将订单创建日期作为分区依据按天将一个月的数据分成 30 个分区，而用户的分析查询往往更高频查询最近一周甚至三五天的订单数据。在以往分析引擎不支持分区的情况下，TiDB MPP 只能进行全表扫描，这不但浪费了无谓的存储带宽，也会消耗 CPU 针对日期字段进行过滤。而在 6.1 版本中，对于上述例子，只要查询条件带有订单创建日，则可以数倍甚至数十倍提高查询效率。\n\n在 6.1 中另一个分析场景下常用的新功能是 MPP 下的窗口函数支持。在新版本中，MPP 执行器加入了对窗口函数的框架性支持，并随之推出了三个最常用窗口函数 rank，dense_rank 以及 row_number。这使得在 MPP 执行模式下，窗口函数除了内存消耗可以被分布式分担，性能也得到大幅提升。以 100G 规模数据集测试为例 ，新版本中查询使用单节点 MPP 模式进行窗口函数计算将提速 282%，使用更多节点将有更大幅度提速。与以往 MPP 模式下对内建函数的支持一样，我们将逐步增加对各类窗口函数的支持。\n\n新版本中，TiDB 引入了非事务性 DML 语句以应对大批量数据变更。新加入的非事务性 DML 将一个普通 DML 拆成多个 SQL 执行，以牺牲事务的原子性和隔离性为代价，增强批量数据处理场景下的性能和易用性。典型的，在新版本中可以使用如下语句淘汰过期数据，而无需担心事务大小限制问题：\n\n`BATCH ON id LIMIT 2 DELETE FROM orders where create_date < '2022-05-01';`\n\n上述 SQL 将会以 2 批次的方式执行 DELETE 操作，以控制单次操作的内存占用。过往版本中，TiDB 仅支持非事务性删除。\n\n### 更完整的生态对接\n\n数据库从来都不是单独被使用的，而 TiDB 也在持续改进和生态环境的对接。在新版本中，TiDB 引入了用户级别锁和 TiCDC 下的 Avro 格式向 Kafka 同步数据的支持。\n\n先说用户级别锁。用户级别锁是 MySQL 通过内置函数提供的用户命名锁管理系统。它们可以用在 SQL 语句的 SQL 函数中，比如 select，where 子句，group by 子句等位置使用。这些语句可以在不同的代码处阻塞，等待，实现用户级别锁管理。用户级别锁在 ORM 框架中也有较为广泛的应用，例如 RoR, Elixir 和 Ecto 等。TiDB 从 6.1 版本开始支持兼容 MySQL 的用户级别锁管理，支持 GET_LOCK，RELEASE_LOCK, RELEASE_ALL_LOCKS 等锁管理函数，这使得 TiDB 得以更好支持现有 ORM 框架的生态。\n\n对 TiDB 而言，TiCDC 是集群数据实时变更信息的出口，而支持常用的数据格式以方便消费者解析则是降低开发复杂度的必修课。Avro 作为一种数据序列化系统，采用了压缩二进制格式，传输效率高，数据格式丰富，已经被大量的数据分析、数据集成产品所支持。TiCDC 支持将 TiDB 数据库的增量数据转换为 Avro 格式，并发送到 Kafka 的方式，这将使得 TiDB 数据库和众多的生态系统，例如：Kafka、Snowflake、SQL Server 链接起来。在新版本中，向其他系统实时同步 TiDB 的数据变化，无论是用于实时数据集成还是变更订阅触发操作，都可以借助 Avro 格式变得更简单。更进一步，一些仰赖 Avro 格式的其他生态功能，现在也得以发挥热量，例如用户可以借助 Avro 格式通过 Kafka kSQL 对变更日志进行实时计算。\n\n## 行动起来\n\n除了上述所有新功能外，其实 TiDB 6.1 作为 6 系版本的第一个推荐企业级用户投产的 LTS 版本，是所有需求 6.0 版本特性的用户的理想选择。无论你已经在使用 6.0 版本，还是正在调研中，都推荐大家部署 6.1 版本或升级。相信新版本将为广大用户提供强大的功能和稳定的体验。\n\n查看 TiDB 6.1.0 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-6.1.0)，立即[下载试用](https://pingcap.com/zh/product/#SelectProduct)，开启 TiDB 6.1.0 企业级云数据库之旅。\n\n\n\n\n","author":"PingCAP","category":2,"customUrl":"tidb-6.1-release","fillInMethod":"writeDirectly","id":395,"summary":"TiDB 6.1 于 6 月 13 日发布，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support，简称 LTS）。","tags":["TiDB","Release"],"title":"TiDB 6.1 发版：LTS 版本来了"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}