共计 4946 个字符，预计需要花费 13 分钟才能阅读完成。
在 2023 伊始，咱们很快乐向大家发表，TiDB 6.5 LTS 版本曾经公布了。这是 TiDB V6 的第二个长期反对版（上一个是 TiDB 6.1），除了携带了诸多备受期待的新个性，同时也将失去 TiDB 开发社区的长期保护，是举荐企业级用户采纳的最新版本。
在这个版本中，TiDB 专一于如下几个主题：
- 产品易用性进一步晋升
- 内核一直打磨，更加成熟
- 多样化的灾备能力
- 利用开发者生态构建
置信长期关注咱们的敌人曾经发现，这些主题似曾相识。的确如此，TiDB 近年的倒退简直都围绕着它们发展。咱们冀望 TiDB 成为 更易用，对开发者更敌对，且更成熟的企业级数据库，而这个谋求也并没有止境。
产品易用性进一步晋升
大家兴许不止一次据说过，易用性之于 TiDB 是十分要害的理念。毕竟，TiDB 伊始是为了解决分库分表带来的麻烦，这也使得易用性在 TiDB 研发过程中贯通始终。在新版本中，咱们提供了更多的让用户解放心智的能力。
AND 运算下的索引归并读取
对于数据服务和洞察场景，用户往往会基于诸多查问条件的组合进行数据筛选。例如在物流场景中，用户可能会依据下单日，仓库 ID，转运人，送达日，指标地址等等不同维度进行筛选再剖析。而这些条件独自来看，并不一定具备很好的选择性，只有组合起来能力将数据限定在一个小范畴。如果条件的组合不多，咱们尚可应用特定的组合索引笼罩，但很可能在这类场景中，组合以数十记，齐全无奈为每个组合都创立特定索引。在新版本中，TiDB 反对依据 AND 条件组合同时选中多组索引，并计算它们的交加再读取理论表数据。这种能力，使得用户能够仅仅为单列创立大量索引，以达到更好的选择性以及更优的性能。
集群闪回
有时候，用户会心愿整个集群疾速复原到之前的某个工夫点。例如，因为游戏服务器新版本数据设定问题，将一把绝世好剑设定为 1 元，造成新版公布后一小时内人手一把。若仅仅如此也就算了，开发者能够很容易回收或这个道具，但这种事变还有次生灾祸，例如罕见 Boss 被滥杀，罕见掉落随之泛滥，整个游戏内容崩坏。这时候作为游戏设计师，你可能会心愿工夫能回到犯错之前的那一刻，让你修改那个令人追悔莫及的谬误。在新版本中，TiDB 就提供了这个能力，它反对用简略一条命令向 GC 工夫内的任意工夫点进行全集群闪回，就像上面这样。
FLASHBACK CLUSTER TO TIMESTAMP '2022-09-28 17:24:16'; 咱们当然心愿这不会是一个常见的情况，但这并不示意须要闪回的机会千年难遇：闪回能力也可用于日常操作，例如将测试环境复原到测试开始前的状态，以供重复应用。
残缺的大事务主动拆分反对
在前序版本中，咱们反对了针对删除的大事务主动拆分反对。而在新版本中，TiDB 残缺反对了针对插入和批改的大事务拆分。在以往版本中，TiDB 用户常常要面对的一个问题就是，一些大规模的数据变更保护操作，例如过期数据删除，大范畴数据订正，或者依据查问后果回写数据等操作，会遇到超过 TiDB 单条事务下限的问题，这是因为 TiDB 繁多事务须要由繁多 TiDB Server 作为提交方而带来的限度，这时候用户往往不得不手动想方法拆小事务以绕过该限度。但在理论应用中，上述类型的数据变更未必真的须要作为繁多事务确保原子性，例如数据淘汰和数据订正，只有最终执行实现，哪怕事务被拆开屡次执行也并不会影响应用。在 TiDB 6.5 中，咱们提供了将大事务主动拆分的能力，例如依照 t1.id 以 10000 条为大小分批数据更新，能够简略应用如下语句实现：
BATCH ON t1.id LIMIT 10000 update t1 join t2 on t1.a=t2.a set t1.a=t1.a*1000;更具体的阐明请参考文档。
TiFlash 后果物化（试验个性）
TiFlash 在过往版本中有一个很大的缺憾是无奈在读写事务中应用：常常用户心愿将 TiFlash 的计算结果进行回写以供高并发读取（相似物化成果）。从 v6.5.0 起，TiFlash 反对通过 INSERT SELECT 语句回写后果进行物化，节俭系统资源并进步响应速度。
INSERT INTO top_payments SELECT MAX(amount) FROM payments;在执行上述 INSERT INTO SELECT 语句时，TiDB 能够将 SELECT 子查问下推到 TiFlash 以提供高速剖析计算，并将返回后果通过 INSERT INTO 能够保留到指定的 TiDB 表中。值得一提的是，该性能联合前述大事务拆分能够实现大量后果集物化。
高性能全局枯燥递增 AUTO_INCREMENT 列
TiDB 作为一款分布式数据库，以往在应用 AUTO INCREMENT 列创立主键时，仅保障在每个 TiDB 实例中序列递增，而跨 TiDB 实例则无奈保障。但理论应用中，用户依然常常会遇到须要严格枯燥递增主键的时候，例如以主键隐式代表工夫维度，确定事件产生程序。在 6.4 版本中，咱们退出了高性能的全局枯燥递增主键的反对，以兼容 MySQL 的行为。该模式下，TiDB 将采取中心化的主键调配以确保枯燥递增，即便跨 TiDB 实例拜访，ID 也不会呈现回退，且针对其的写入也可轻松达到数万的 TPS。
应用 TTL (Time to Live) 来周期性地删除过期数据（试验个性）
保护数据的生命周期在 TB 以上规模下并不是很容易的事件：因为数据规模大，寻找并清理过期的数据往往须要耗费相当的算力，有时用户为了更快清理数据甚至被迫应用分区表，以删除分区的形式来进行疾速清理。更麻烦的是，用户须要保护特定的工作以一直定期淘汰数据。在新版本中，TiDB 提供了 Time to Live (TTL) 能力，使得用户能够设定行级别的生命周期控制策略。通过为表设置 TTL 属性，TiDB 能够周期性地主动查看并清理表中的过期数据。当开启时，TTL 会以表为单位，并发地散发不同的工作到不同的 TiDB 实例节点上，进行并行删除解决，且不影响集群性能。更具体的阐明请参考文档。
内核要害个性打磨和加强
TiDB 蕴含繁多的个性汇合，但其中有些仍需一直打磨，例如 JSON 尽管已获反对许久，但理论能力却尚需欠缺。在新版本中，咱们针对重要个性汇合使劲打磨，以期提供给用户更「丝滑」的体验，让 TiDB 的重大个性以更欠缺的形式出现在用户背后，也让 TiDB 演进形式更稳重更有品质。
首先是 DDL 增强。反对在线 DDL 是 TiDB 的外围劣势之一，在过往一年中，咱们退出了对并行 DDL 的反对，使得例如 SaaS 等多租户场景下不会因为同时进行的 DDL 相互阻塞，而 DDL 烦扰 DML 的状况也通过 Metadata Lock 得以解决。在新的 6.5 版本中，TiDB 反对了相似 Lightning 注入 SST 的设计，针对须要追溯的历史数据间接应用 SST 构建的形式进行生成，大幅提高了 DDL 的构建速度，最快可达 10 倍晋升。
如下图所示，以 TiDB 6.1 版本为基准值，新版除了获得了数量级的提速，且比照 CockroachDB v22.2 和以后版的 AWS Aurora 也快 2-3 倍。
其次是 JSON 的反对打磨。JSON 对于须要灵便数据结构的场景十分重要，因而在挪动端，游戏开发等场景中宽泛应用。从 6.2 版本以来，在这半年中 TiDB 陆续引入了残缺的 MySQL 5.7 兼容函数，针对 JSON 的表达式索引反对，更多的生态工具兼容以及更好的 TiFlash 引擎反对。
再者是 TiDB 全局内存管制。自 v6.5.0 起，TiDB 全局内存管制已可能跟踪到 TiDB 中次要的内存耗费。当单个会话的内存耗费达到零碎变量 tidb_mem_quota_query 所定义的阈值时，将会触发零碎变量 tidb_mem_oom_action 所定义的行为 (默认为 CANCEL，即勾销操作)。当全局内存耗费达到 tidb_server_memory_limit 所定义的预设值时，TiDB 会尝试 GC 或勾销 SQL 操作等办法限度内存应用，保障 TiDB 的稳定性，对内存的应用效率也更加高效。
最初是升高累积的乐观锁对性能的影响。在一部分交易系统，尤其是银行业务中，客户利用会在乐观事务中利用 select for update 先锁定一条记录，从而达到对数据一致性的爱护，缩小事务中后续操作失败的可能，比方
BEGIN;
SELECT c FROM sbtest1 WHERE id = 100 FOR UPDATE;
UPDATE sbtest1 SET k = k + 1 WHERE k = ?;
COMMIT;而在 TiDB 中，对一行记录重复的 select for update，会造成这条记录的查问性能降落。在 v6.5.0 中，咱们对这部分机制进行了优化，通过记录间断的锁标记，升高了累积的乐观锁对查问性能的影响，QPS 可大幅晋升 10 倍以上。
多样化的灾备能力
在过往版本中，TiDB 次要依赖 BR 进行动态的备份复原，而在 6.2 之后的新版中，TiDB 提供了 PITR 能力，使得数据库能够更灵便地复原到任意工夫点。
TiDB PITR（Point-in-Time Recovery）是联合了 BR 和变更捕捉（Change Data Capture）两种能力的灾备个性。以往 BR 的动态灾备只能将数据恢复到备份的工夫点，如果要更提供针对更新和更多工夫点的复原，则相应须要进步备份频率。这岂但会减轻备份对在线业务的累赘，也须要更多存储老本。应用 PITR 则能够解脱这个懊恼，用户无需一直进行全量备份，而是可经由一个全量备份联合增量共同完成针对任意工夫点的数据恢复。
通过半年左右的继续改良，在新版本中，咱们缩小了 PITR 备份文件大小和数量，增强了稳定性，晋升了性能。例如：确保在绝大多数异样场景下 RPO < 5mins, 单个 TiKV 的备份速度达到 100MB/ s 等，针对 PITR 更具体的介绍，请参考这篇博客。
与此同时，在 6.5 版本中，TiCDC 的吞吐取得了得了至数倍的晋升。通过对 TiCDC 外部的设计和实现的一直优化，针对数据复制场景，当上游为 Kafka 集群时，针对大单表场景的吞吐量失去了极大的晋升，单个 TiCDC 节点能够反对 35k row/s QPS，吞吐量能够达到 50MB/s，并将提早管制在 2 秒左右，而内存使用量只有之前版本的 50% 左右。针对跨区域主备集群容灾场景，TiCDC 单个节点的吞吐量能够达到 30MB/s，并且其提早也能够稳固在 2 秒左右，稳定性大幅度提高。
其次，在 6.5 版本中，DM 正式公布了在数据迁徙过程中的增量数据继续校验性能，该个性只对新增或变更的数据进行校验，而不是对整个数据集进行校验，在确保数据迁徙过程的准确性和可靠性的同时，大大减少数据校验的工夫和资源耗费。尤其是在迁徙一些重要零碎时，该个性能够让数据迁徙过程更加平安。
除此以外，新版本反对了在上游集群应用水位线进行一致性读取的能力：在新版本中，TiCDC 能够在向上游写入时提供非凡的工夫戳，而上游集群则能够主动应用该工夫戳进行一致性读取而无需放心读到的事务不残缺。这使得上游集群在须要严苛事务保障的场景下，也能够良好承当读流量分流的职责。
利用开发者生态构建
在以往版本中，TiDB 更强调 DBA 的应用体验。但在近期的更新中，你兴许曾经发现咱们逐步开始聚焦 DBA 以外的利用开发者体验。在新版中，咱们强化了利用开发所需的生态环境构建，例如这半年来 TiDB 通过减少对 Savepoint，User Level Lock，Multiple Schema Change 等性能的反对，欠缺了针对常见利用框架 django，prisma 等的反对。与此同时，咱们也引入了更多上下游生态厂商的策略单干：Vercel，Hashicorp，Retool 等。在 6.5 版本中，TiCDC 减少了针对向 Object Storage 写入的反对。对象存储是一种面向云的存储服务，具备高可扩展性、高可用性、低成本等劣势。应用 TiCDC 将数据同步到对象存储，能够帮忙用户实现数据的长期存储、数据的跨区域复制等目标。另外，这使得 TiDB 在云环境下能间接打通向数仓和数据湖环境的通路。更好的生态反对，将使得开发者在应用 TiDB 构建利用时，领有更多抉择，也更简便。
总结
作为 TiDB 版本 6 的第二个长期反对版，TiDB 6.5 曾经公布。咱们心愿借助这个版本为更多用户提供更易用且更成熟的企业级数据库。更具体的变更状况请参阅 Release Notes。欢送各位和咱们一起开启新的微妙旅程。
