我们很高兴地宣布，TiDB 6.6 版本已经发布了。在这个版本中，TiDB 一如既往地沿着更省心、更便捷、更快的方向前进。
更省心
资源组
在省心运维的主题下，新版本包含了重要的实验特性资源组功能。通过 TiDB 中的资源控制，一个应用的会话使用资源受设定的上限所限制。如果其工作负载变大，它的资源分配就会受到限制，以防止拖慢其他应用。这使得 TiDB 将更合适用于多租户的场景：
- 用户可以将多个小型或中型应用程序合并到一个TiDB集群中，从而降低整体TCO，同时仍然保证用于不同目的的资源。
- 用户能够在工作时间安全地运行批处理作业。批处理任务消耗的资源可以包含在特定的资源组中。
- 所有 Staging 环境都可以共享一个具有托管资源限制的TiDB集群，甚至可以与生产环境一起共享。
用户可以为不同租户定义资源组，每个资源组包含了虚拟资源量，并且用户可以设定资源组是否可以在资源闲置时超额使用资源。
例如一个典型的资源组设定可以是这样的：
| Resource Group | RU limit （资源上限） |
Burstable （是否可超额使用） |
特征 |
|---|---|---|---|
| Payment | 4000 | YES | 支付业务，需要确保资源供给，且在高峰时刻可以占用其他组的资源。 |
| User Configuration | 2000 | NO | 用户信息管理，资源需求少于支付，且响应延迟需求低于支付，也无明显高峰低谷。 |
| Nightly Batch | 1000 | NO | 夜间跑批业务，需要确保其不会过多占用资源。 |
CREATE RESOURCE GROUP payment RU_PER_SEC=4000 BURSTABLE;
CREATE RESOURCE GROUP user_conf RU_PER_SEC=2000;
CREATE RESOURCE GROUP nightly_batch RU_PER_SEC=1000;随着资源组功能的加入，用户不再需要为诸多大大小小的业务和用户划分独立的 TiDB 集群（这样做在 SaaS 场景下甚至是不可能的），这不但节省了开销，也大大简化了运维管理。更进一步，将不同相关业务归于统一集群，也使得跨业务数据互通变得异常简单，无论是打造数据中台，还是架构微服务，都更方便省心。
从历史创建执行计划绑定
SQL 绑定是保持执行计划正确和稳定的重要方法。在关键业务中，用户往往希望执行计划保持稳定，不会因为数据变更等诱因而变化，因为突变的执行计划可能意味着查询效率大幅下降，资源使用飙升，以及严重的事故。在以往版本中，应对计划突变比较麻烦，哪怕已经明确最优计划是什么，用户也必须自己组装带有提示的计划，并在其之上创建绑定：
CREATE BINDING for
SELECT id, name, score FROM table1 WHERE id = 1 AND name = 'tidb';
USING
SELECT /*+ use_index(@sel_1 table1, idx_id) */ * FROM table1 WHERE id = 1 AND name = 'tidb';在新版中，用户可以在 TiDB Dashboard 中找到最优的执行计划并绑定（也可使用命令行完成类似工作）：
更简单易用
外键支持
在新版本中，TiDB 支持了外键。外键是 TiDB 一直缺失的 MySQL 兼容功能，在以往版本中 TiDB 可以理解外键约束的语法，但无法施加约束，这使得部分用户需要依赖应用代码去实现相应逻辑，这为使用增添了诸多麻烦，也引入了丢失数据完整性的风险。在新版本中，TiDB 终于支持了外键约束。用户可以通过为一张表定义外键的方式引用其他表的主键，从而达到强制约束两张表之间的数据完整性和一致性。例如，你可以为订单数据中的客户信息定义指向客户表的外键，这样在进行数据变更的同时，数据库会保证每个订单都确有对应的用户存在。
多值索引
新版中，TiDB 加入了实验特性多值索引（Multi-Valued Index）。多值索引有些类似搜索引擎的倒排索引，它允许用户针对数据中的 JSON 数组进行索引。例如单一客户信息的可能包含多个送货邮编，于是应用程序使用 JSON 数组字段进行保存。在以往版本中，TiDB 的索引仅仅能对单一值进行索引，因此在这个场景下，如果需要以邮编进行索引查找，你必须将邮编数组展开复制成多行（每行确保只有一个邮编），否则只能进行全表扫描，这无疑费心又难于管理。在新版本中，你可以为 JSON 中的数组字段创建多值索引：
ALTER TABLE customers ADD INDEX zips( (CAST(cust_profile->'$.zipcode' AS VARCHAR(10) ARRAY)) );
并在查询条件中搜索所有送货地址在某个邮编的用户，这样就能使用多值索引快速检索返回结果：
SELECT * FROM customers WHERE ('200040' MEMBER OF (cust_profile->'$.zipcode'));
更快
TiKV 和 TiFlash 引擎加速
在新版中，TiKV 迎来了巨大的优化变更。
首先是实验特性 Partitioned-Raft-KV 存储引擎，以往同一个 TiKV 节点使用一个 RocksDB 存储数据，无论数据量多大，有多少 Region 和表；在 TiDB 6.6 中，TiKV 可以让单一 Region 更大（默认 10 GB），并使用独立的 RocksDB 实例，这将大大减少 LSM Tree 的深度，降低写入的压力，并提升性能。根据测试，写入吞吐提升可达 273%，集群扩缩容可提速 5 倍。
| 写吞吐 | 扩容 | 缩容 | |
|---|---|---|---|
| 单 RocksDB | ~60MB/s | 0.73GB/min | 2.86GB/min |
| Partitioned-Raft-KV | ~224MB/s (+273%) | 3.6GB/min (+500%) | 13.7GB/min (+480%) |
其次，TiKV 在新版中可以通过协处理器攒批的方式减少诸如读取索引等操作带来的大量 RPC 调用，在通过索引读取百万以上规模行的场景下，可提速一倍以上。
再来说说 TiDB 的分析引擎 TiFlash。
TiFlash 的最基础能力是，支持计算时让数据在不同节点之间交换。为了完成计算，有时分析引擎节点之间需要交换大量数据，例如执行大表的关联时，需要将两张表分别按照关联键进行哈希并相互分发。这种情况下，网卡有时候会成为性能瓶颈。在新版中，分析引擎支持了将数据进行压缩后再分发的能力，这使得 TiDB 针对标准 TPC-H 测试下的性能有 12%-32% 的提升，以及超过 50% 的网络带宽节省。
与此同时，TiDB 分析引擎在新版中支持了 Stale Read。当用户不追求严格读取实时数据的前提下，使用该功能读取历史数据可带来 30% 左右的性能提升。
DM 支持物理导入模式
新版本中，DM 的全数据（存量数据）迁移能力集成了TiDB Lightning 的物理导入模式。相较于以往的逻辑模式导入数据，新版本中 DM 的迁移性能提升高达 10 倍，大大缩短了数据量大的场景下的迁移时间；现在，要迁移超过 1 TB 的数据，你只需要在 DM 任务中设置参数即可实现高达 500 GB/小时的存量数据迁移性能。用户再也无需额外配置 TiDB Lightning 迁移存量数据以加快导入速度，大大简化了使用：
import-mode："physical"
总结
以上是 TiDB 6.6 所带来的重要功能概览，除此之外，新版本共发布了 32 个新特性，37 个增强以及 80 个问题修复，希望了解详情可参考 TiDB 6.6 Release Notes。
目录