我们很高兴向大家宣布，TiDB 6.1 于 6 月 xx 日发布了，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support）。
长期支持版
在两个月前发布 TiDB 6.0 版本时，我们提过在新发版流程中，我们引入了 LTS 版本的概念，与之相对的是开发里程碑版本（Development Milestone Release）。引入这两种概念是为了让 TiDB 的发版节奏能兼顾快速变化的市场需求以及企业版对稳定性的要求。
我们重新思考了发版模型，最后选择了长期支持版结合开发里程碑版的方式：我们保持 2 个月左右一次发版的节奏，以期快速应对市场节奏，但不再对所有发布进行长期维护，而是以半年左右为节奏拣选其中一个版本作为 LTS 长期支持版本。针对 LTS 版本我们提供针对问题的修复补丁而不再合并新功能。与此相对的，DMR 版本则保持快速发版的节奏，不断发布新特性，让用户所需的新需求不必等待很久（但并不提供基于 DMR 的问题修复）。对于用户而言，在没有特定需求开发的情况下，可以选择最新的 LTS 版本投产；如果需求某个 DMR 发布的新功能，则可以选择该版本进行 PoC 以及试运行，待到对应的 LTS 版本发布后升级 TiDB 到稳定生产状态。这样快慢结合的方式，可以最大限度兼顾快速迭代和稳定投产两方面的需求。
对应 LTS 稳定版的主旨，6.1 版本中携带了重要的稳定性更新：
- 提升 TiKV 高压场景下的内存稳定性。
- 解决了由于 Raft Log 复制流量过大导致的 OOM 问题。
- 解决了在高压场景下宕机后重启过程中长时间持续反复 OOM 的问题。
- 完善了 TiDB Server 内存使用跟踪统计，加强查询内存使用配额限制。
- 优化了部分统计信息内存使用。
另外，新版本也包含了 42 个问题修复和 20 个改进提升。
虽是 LTS，仍有新惊喜
TiDB 6.1 除了作为第一个推荐投产的 6 系版本，本身也携带了诸多强大的特性。
HTAP 基础能力提升
在新版本中，部分分区表的实验特性 GA，且分析引擎加入了分区表和窗口函数支持。
让我们先来看看分区表：我们在版本 5 中引入了 List 分区和动态裁剪特性，但一直保持实验特性状态。更重要的是，由于旧有的分区静态裁剪在 MPP 下表现欠佳，因此 TiFlash 引擎一直以来并未完整支持分区表特性。这次新发布中，我们宣布 List 分区 / 分区动态裁剪以及 MPP 模式下的分区表支持 GA。对于分区表本身在此无需过多赘述，各位可以参考官方文档，我们单独说下分析引擎下的分区表支持。
对于列存引擎而言，由于并不支持类似行存的细粒度索引，仅仅依靠粗糙索引并不能满足数据过滤需求。而分区表作为列存下最高效的数据过滤手段，是分析场景下需求优先级非常高的特性。例如在订单管理场景下，用户的数据天然可以将订单创建日期作为分区依据按天将一个月的数据分成 30 个分区，而用户的分析查询往往更高频查询最近一周甚至三五天的订单数据。在以往分析引擎不支持分区的情况下，TiDB MPP 只能进行全表扫描，这不但浪费了无谓的存储带宽，也会消耗 CPU 针对日期字段进行过滤。而在 6.1 版本中，对于上述例子，只要查询条件带有订单创建日，则可以数倍甚至数十倍提高查询效率。
在 6.1 中另一个分析场景下常用的新功能是 MPP 下的窗口函数支持。在新版本中，MPP 执行器加入了对窗口函数的框架性支持，并随之推出了三个最常用窗口函数 rank，dense_rank 以及 row_number。这使得在 MPP 执行模式下，窗口函数除了内存消耗可以被分布式分担，性能也得到大幅提升。以 100G 规模数据集测试为例 ，新版本中查询使用单节点 MPP 模式进行窗口函数计算将提速 282%，使用更多节点将有更大幅度提速。与以往 MPP 模式下对内建函数的支持一样，我们将逐步增加对各类窗口函数的支持。
新版本中，TiDB 引入了非事务性 DML 语句以应对大批量数据变更。新加入的非事务性 DML 是将一个普通 DML 拆成多个 SQL 执行，以牺牲事务的原子性和隔离性为代价，增强批量数据处理场景下的性能和易用性。典型的，在新版本中可以使用如下语句淘汰过期数据，而无需担心事务大小限制问题：
代码语言：sql复制BATCH ON id LIMIT 2 DELETE FROM orders where create_date < '2022-05-01';上述 SQL 将会以 2 批次的方式执行 DELETE 操作，以控制单次操作的内存占用。当前版本中，TiDB 仅支持非事务性删除。
除了上述三个功能外，TiFlash 列式存储引擎进行了性能优化，使得在写入场景下大幅度节省了硬件资源。实际混合负载业务测试显示，写流量从峰值 140MB/s 下降为 50MB/s，峰值 CPU 从 3000% 下降到 2500%，内存峰值从 28GB 降为 18GB，且大幅减少 IO 抖动。
更完善的生态对接
数据库从来都不是单独被使用的，而 TiDB 也在持续改进和生态环境的对接。在新版本中，TiDB 引入了用户级别锁和 TiCDC 下的 Avro 格式向 Kafka 同步数据的支持。
先说用户级别锁。用户级别锁是 MySQL 通过内置函数提供的用户命名锁管理系统。它们可以用在 SQL 语句的 SQL 函数中，比如 select，where 子句，group by 子句等位置使用。这些语句可以在不同的代码处阻塞，等待，实现用户级别锁管理。用户级别锁在 ORM 框架中也有较为广泛的应用，例如 RoR, Elixir 和 Ecto 等。TiDB 从 6.1 版本开始支持兼容 MySQL 的用户级别锁管理，支持 GET_LOCK，RELEASE_LOCK, RELEASE_ALL_LOCKS 等锁管理函数，这使得 TiDB 得以更好支持现有 ORM 框架的生态。
对 TiDB 而言，TiCDC 是集群数据实时变更信息的出口，而支持常用的数据格式以方便消费者解析则是降低开发复杂度的必修课。Avro 作为一种数据序列化系统，采用了压缩二进制格式，传输效率高，数据格式丰富，已经被大量的数据分析、数据集成产品所支持。TiCDC 支持将 TiDB 数据库的增量数据转换为 Avro 格式，并发送到 Kafka 的方式，这将使得 TiDB 数据库和众多的生态系统，例如：Kafka、Snowflake、SQL Server 链接起来。在新版本中，向其他系统实时同步 TiDB 的数据改变，无论是用于实时数据集成还是变更订阅触发操作，都可以借助 Avro 格式变得更简单。更进一步，一些仰赖 Avro 格式的其他生态功能，现在也得以发挥热量，例如用户可以借助 Avro 格式通过 Kafka kSQL 对变更日志进行实时计算。
行动起来
除了上述所有新功能外，其实 TiDB 6.1 作为 6 系版本的第一个推荐生产的 LTS 版本，是所有需求 6.0 版本特性的用户的理想选择。无论你已经在使用 6.0 版本，还是正在调研中，都推荐大家部署 6.1 版本或升级。相信新版本将为广大用户提供强大的功能和稳定的体验。
