{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/tidb-7.4-release",
    "result": {"pageContext":{"blog":{"id":"Blogs_516","title":"TiDB 7.4 发版：正式兼容 MySQL 8.0","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"从项目初期开始，TiDB 坚持拥抱 MySQL 生态的产品战略一直延续至今。TiDB v7.4.0 版本发布了对 MySQL 8.0 常用功能的支持，这使得平滑迁移 MySQL 8.0 的应用变得轻而易举。","body":"![tidb7.4-banner.jpeg](https://img1.www.pingcap.com/prod/tidb7_4_banner_52d79a9f67.jpeg)\n\nMySQL 是全球最受欢迎的开源数据库，长期位于 DB-Engines Ranking 排行榜第二名，在世界范围内拥有数量庞大的企业用户和开发者。然而，随着时间的推移，MySQL 用户正面临新挑战。Oracle 官宣将在 2023 年 10 月终止 MySQL 5.7 版本的官方技术支持。据第三方统计显示，目前仍有超过一半的 MySQL 服务器运行在 5.7 版本。在未来几个月，大量的 MySQL 实例必须升级至 8.0 及更高版本，否则将无法享受 Oracle 提供的技术支持和重要补丁更新，企业级用户将面临重大考验。\n\nTiDB 作为新一代分布式关系型数据库，从诞生第一天起拥抱 MySQL 生态，不断地兼容 MySQL 5.7 和 MySQL 8.0，为用户带来更加顺畅的迁移和使用体验。本文将介绍 TiDB 7.4 DMR 在 MySQL 8.0 兼容方面的新进展，探讨 TiDB 如何从根本上解决 MySQL 用户面临的各种挑战。\n\n## MySQL 用户的五大挑战\n\n- 升级影响业务连续性。单实例或 \"主从模式\" 运行的 MySQL 升级时会造成数据库服务的停机，可能会对业务运营造成冲击。运行着大量 MySQL 实例的企业级用户，为了应对升级存在的潜在风险，需要投入大量的人力、物力进行测试和演练。\n- 业务规模扩展困难。随着业务规模的扩大和数据使用场景的增多，用户通常需要在单机容量限制和分片管理复杂度之间进行权衡，数据库扩展的难度制约了业务规模和发展速度。\n- 缺乏极致高可用方案。对于支撑核心业务场景的 MySQL 数据库来说，如果遇到不可预测的宕机事件，恢复业务变得复杂，达成极低的恢复时间目标（RTO）成为数据库管理员的挑战。\n- 实时分析能力不足。MySQL 在处理大规模数据实时分析时性能不如在 OLTP（联机事务处理）场景下出色。这对于需要进行复杂查询和数据分析的业务是一个挑战。\n- 原厂托管服务受限。虽然云服务商都会提供 MySQL 托管服务，但大多缺乏 Oracle 原厂的官方支持。这意味着在处理深层次的产品问题和发现通用功能需求时，用户无法获得来自数据库原厂的快速反馈和支持。\n\n因此，迁移到一个成熟的产品并一举解决上述难题，无疑是明智之举。TiDB 就是 MySQL 全面升级的理想之选。选择 TiDB，不仅可以摆脱 MySQL 升级和扩展性的困境，还能够享受 HTAP、数据库整合等多方面的额外收益。  \n\n## 高度兼容 MySQL 的分布式关系型数据库 TiDB\n\nTiDB 是由 PingCAP 自主研发的企业级分布式关系型数据库，具备水平扩缩容、金融级高可用、实时 HTAP、云原生、兼容 MySQL 5.7 协议和生态等重要特性。TiDB 采用原生分布式架构设计，具备灵活的弹性伸缩能力，整个过程对业务透明，无需人工干预。TiDB 的多副本存储和 Multi-Raft 协议确保数据的强一致性和高可用性，在部分副本发生故障时不影响数据的可用性。TiDB 通过滚动升级的方式使得版本更新的影响降至最低，此外可采用增加临时节点的方式，确保 TiDB 在升级过程中的性能波动和连接闪断控制在 5% 以内，大幅降低升级对业务的影响。  \n\n另外，作为 TiDB 的缔造者，PingCAP 基于全球领先云服务商推出数据库托管服务 TiDB Cloud，服务支持涵盖复杂问题诊断、升级支持、紧急救援等，充分体现了原厂服务的优势。\n\n## 自 TiDB 7.4 DMR 开始，TiDB 正式兼容 MySQL 8.0\n\n从项目初期开始，TiDB 坚持拥抱 MySQL 生态的产品战略一直延续至今。TiDB 兼容 MySQL 的 wire protocol 和语法命令，这意味着 MySQL 客户端、MySQL 驱动程序以及部分 MySQL 工具可以直接在 TiDB 上运行。对于绝大多数在 MySQL 上运行的应用程序来说，几乎不需要修改任何代码。  \n\n随着 MySQL 8.0 的发布，TiDB 在兼容 MySQL 5.7 的基础之上，积极扩展了对 MySQL 8.0 的兼容。TiDB v7.4.0 版本发布了对 MySQL 8.0 常用功能的支持，这使得平滑迁移 MySQL 8.0 的应用变得轻而易举。本文列举了部分功能：  \n\n### 公共表表达式（CTE）  \n\n作为 MySQL 8.0 引入的重要能力， TiDB 从 5.1 版本开始支持 ANSI SQL 99 标准的 CTE 及其递归的写法。在编写复杂查询的时候，利用公共表表达式 (CTE) 可以构建一个临时的中间结果集，在 SQL 语句中引用多次，提高 SQL 语句编写效率，可读性，执行效率。目前版本中，TiFlash 也同样支持 CTE。  \n\n比如表 `authers` 保存了作家的信息，`book_authors` 记录了作家 id 与其所编写书籍 id 的对应关系。  \n  \n```\nmysql> desc authors;\n+------------+--------------+------+------+---------+-------+\n| Field      | Type         | Null | Key  | Default | Extra |\n+------------+--------------+------+------+---------+-------+\n| id         | bigint(20)   | NO   | PRI  | NULL    |       |\n| name       | varchar(100) | NO   |      | NULL    |       |\n| gender     | tinyint(1)   | YES  |      | NULL    |       |\n| birth_year | smallint(6)  | YES  |      | NULL    |       |\n| death_year | smallint(6)  | YES  |      | NULL    |       |\n+------------+--------------+------+------+---------+-------+\n\nmysql> desc book_authors;\n+-----------+------------+------+------+---------+-------+\n| Field     | Type       | Null | Key  | Default | Extra |\n+-----------+------------+------+------+---------+-------+\n| book_id   | bigint(20) | NO   | PRI  | NULL    |       |\n| author_id | bigint(20) | NO   | PRI  | NULL    |       |\n+-----------+------------+------+------+---------+-------+  \n```\n\n利用 CTE， 能够很容易编写出 SQL，列出最年长的 50 位作家分别编写过多少书籍。  \n\n```\nmysql> WITH top_50_eldest_authors_cte AS (\n    ->     SELECT a.id, a.name, (IFNULL(a.death_year, YEAR(NOW())) - a.birth_year) AS age\n    ->     FROM authors a\n    ->     ORDER BY age DESC\n    ->     LIMIT 50\n    -> )\n    -> SELECT\n    ->     ANY_VALUE(ta.id) AS author_id,\n    ->     ANY_VALUE(ta.age) AS author_age,\n    ->     ANY_VALUE(ta.name) AS author_name,\n    ->     COUNT(*) AS books\n    -> FROM top_50_eldest_authors_cte ta\n    -> LEFT JOIN book_authors ba ON ta.id = ba.author_id\n    -> GROUP BY ta.id;\n+-----------+------------+----------------------+-------+\n| author_id | author_age | author_name          | books |\n+-----------+------------+----------------------+-------+\n| 524470241 |         80 | Alexie Kirlin        |     7 |\n|  67511645 |         80 | Bridgette Tromp      |     9 |\n...\n|  48355494 |         80 | Audrey Mayert        |     7 |\n+-----------+------------+----------------------+-------+\n50 rows in set (0.23 sec)  \n```\n \n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/dev-guide-use-common-table-expression \n\n### 窗口函数 (window function)\n\n窗口函数(Window Function)，又被叫做分析函数， 在对数据进行分析、汇总、排序时会被用到。窗口函数能够以 SQL 形式的写法，来完成一些复杂的数据整理工作，协助用户发掘数据价值。例如，数据分组排序， 变化趋势分析等。  \n\nTiDB 目前已经完整支持了 MySQL 8.0 提供的窗口函数，大部分可以下推到 TiFlash 运行。\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/window-functions\n\n### 资源管控\n\nTiDB 在 7.1 版本引入了资源管控，目的是能够对集群资源做合理分配，提升数据库的稳定性，并降低数据库的使用成本。在多个应用共享一个 TiDB 集群的场景下， 资源隔离可以有效降低应用负载变化对其他应用产生的影响， 资源管理还能解决批量作业及后台任务对核心业务的影响，以及突发的 SQL 性能问题拖慢整个集群，是提升大集群稳定性的重要能力。  \n\n尽管和 MySQL 的实现方式有差别，TiDB 兼容了 MySQL 指定资源组的语法以及 hint，降低用户学习成本和迁移成本。另外，TiDB 的资源隔离能够更有效地对最重要的 I/O 资源进行管控，达到和 MySQL 同等甚至更好的效果。  \n\n下面展示了利用资源管控，将 `usr1` 使用的所有资源控制在每秒 500 RU 以内。  \n\n- 预估集群容量\n  \n```\nmysql> CALIBRATE RESOURCE\n``` \n\n- 创建 app1 资源组，限额是每秒 500 RU\n\n```  \nmysql> CREATE RESOURCE GROUP IF NOT EXISTS app1 RU_PER_SEC = 500;\n```\n\n- 将用户与资源组关联， usr1 的会话自动关联到资源组 app1\n\n```\nmysql> ALTER USER usr1 RESOURCE GROUP app1;\n```\n\n- 也可以修改会话所属的资源组\n\n```\nmysql> SET RESOURCE GROUP `app1`;\n```\n\n- 或者利用 hint RESOURCE_GROUP() 指定语句所属的资源组  \n\n```\nmysql> SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10;\n```\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control\n\n\n### 基于角色的权限管理\n\nTiDB 支持 MySQL 兼容的角色管理。基于角色的授权，可以简化权限管理的工作，并降低了出错的风险。通过将权限与角色相关联，可以更好地控制数据库的访问。客户可以将不同场景的工作进行分类，创建对应角色，并把角色授予有权限的数据库用户， 数据库用户在实际操作时，根据场景不同，切换角色，降低误操作的可能。  \n\n这里举一个利用角色拆分权限场景的例子。用户 `dev_adm_usr` 作为应用管理员，要操作数据库 `app_db` 的数据，多数情况下只是查询，偶尔在需要做数据修正的时候才会做修改。为了防止 `dev_adm_usr` 的误操作，我们将两部分权限利用角色拆开，只有必要的时候，才给自己赋予读写的角色。  \n\n- 创建角色 app_read_role 和 app_write_role\n\n```\nmysql> CREATE ROLE 'app_read_role', 'app_write_role';\n```\n\n- 为角色授予对应的权限，这里为两个角色分别授予 `app_db` 的读和写的权限  \n\n```\nmysql> GRANT SELECT ON app_db.* TO 'app_read_role'@'%';\nmysql> GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write_role'@'%';\n```\n\n- 将两个角色授予用户 `dev_adm_usr`\n\n```\nmysql> GRANT 'app_read_role','app_write_role' TO 'dev_adm_usr'@'localhost';\n```\n\n- 把 `app_read_role` 设为 `dev_adm_usr` 的默认角色，这样用户 `dev_adm_usr` 登录时默认是只读权限\n\n```\nmysql> SET DEFAULT ROLE 'app_read_role' TO 'dev_adm_usr'@'localhost';\n```\n\n- 当 `dev_adm_usr` 需要修改数据时，启用角色 `app_write_role`\n\n```\nmysql> SET ROLE app_read_role,app_write_role;\n```\n\n或者启用所有角色\n\n```\nmysql> SET ROLE ALL;\n```\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/role-based-access-control\n\n\n### 增强 uft8mb4 字符集  \n\nMySQL 8.0 的一个重要变化是默认字符集变成了更通用的 `uft8mb4`，默认排序方式变为 `utf8mb4_0900_ai_ci`。TiDB 在新版本里也加入了 `utf8mb4_0900_ai_ci` 的排序方式，以便更轻松地进行系统迁移。  \n\n为了同时兼容 MySQL 5.7 和 MySQL 8.0，TiDB 支持了 MySQL 兼容的变量 `default_collation_for_utf8mb4`。允许用户调整 `utf8mb4` 字符集的默认排序方式。这个方式确保了 TiDB 在不同 MySQL 版本之间的平滑过渡，并能够适应不同应用程序的需求。  \n\n如果从 MySQL 8.0 迁移，设为 8.0 默认排序 `utf8mb4_0900_ai_ci`\n\n```\nset global default_collation_for_utf8mb4='utf8mb4_0900_ai_ci';\n```\n\n如果从 MySQL 5.7 迁移，设为 5.7 为 `utf8mb4` 的默认排序 `utf8mb4_general_ci`  \n\n```\nset global default_collation_for_utf8mb4='utf8mb4_general_ci';\n```\n\n### JSON 多值索引 (Multi-valued Index)  \n\n在支持了 MySQL 5.7 的完整函数之后，TiDB 在不断添加对 MySQL 8.0 新发布功能的支持。最近的版本支持了\"多值索引\"，允许对 JSON 类型中的某个\"数组\"进行索引，从而提高了对 JSON 数据的检索效率。与 MySQL 用法完全相同，这意味着在迁移过程中，无需修改数据建模或应用程序，用户可以继续按照熟悉的方式操作 JSON 数据。  \n\n多值索引是对普通索引结构的延伸。不同于普通索引与表 1:1 的对应关系， 多值索引与表的对应是 N:1。与 MySQL 相同， 条件中利用 `MEMBER OF()`，`JSON_CONTAINS()`，`JSON_OVERLAPS() `这几个函数检索时，都可能会选择到多值索引。  \n\n比如，我们假定有一张客户信息表，所有详细信息以 JSON 格式编入一个 JSON 类型的列中， 其中有一个数组结构保存客户所在的几个城市。  \n\n![客户信息表示意.png](https://img1.www.pingcap.com/prod/_2cc07b7ff4.png)\n\n当我们需要检索哪些客户在北京时，如果没有多值索引，这个查询需要扫描整张表。  \n\n```\nSELECT name FROM customer\nWHERE 'beijing' MEMBER OF $.city;\n```\n\n这时我们可以针对 `city` 这个数组创建多值索引，上述查询就可以利用索引检索符合的记录，大幅提升查询性能。  \n\n```\nALTER TABLE customers add index idx_city (name, (CAST(custinfo->'$.city' AS char(20) ARRAY)));\n```\n\n和普通索引一样， 当优化器没有选择到多值索引时，可以利用优化器提示 `USE_INDEX()`或 `USE_INDEX_MERGE()` 强制优化器做选择。  \n\n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/choose-index#%E4%BD%BF%E7%94%A8%E5%A4%9A%E5%80%BC%E7%B4%A2%E5%BC%95\n\n### 修改会话变量的 hint ( SET_VAR())  \n\nMySQL 8.0 引入了一个特殊的 hint `SET_VAR()`。利用这个 hint，可以在语句运行期间修改某个会话级系统变量。TiDB 在 v7.4.0 也支持了这个 hint，提升了系统变量设置的灵活度， 能够针对 SQL 语句做“定制”。包括优化器相关的，执行时相关的多个变量都支持用 hint 修改。  \n\n比如，针对大表的分析处理，适当增加 SQL 的执行并行度。  \n\n```\nSELECT /*+ set_var(tidb_executor_concurrency=20) */\n    l_orderkey,\n    SUM(\n        l_extendedprice * (1 - l_discount)\n    ) AS revenue,\n    o_orderdate,\n    o_shippriority\nFROM\n    customer,\n    orders,\n    lineitem\nWHERE\n    c_mktsegment = 'BUILDING'\nAND c_custkey = o_custkey\nAND l_orderkey = o_orderkey\nAND o_orderdate < DATE '1996-01-01'\nAND l_shipdate > DATE '1996-02-01'\nGROUP BY\n    l_orderkey,\n    o_orderdate,\n    o_shippriority\nORDER BY\n    revenue DESC,\n    o_orderdate\nlimit 10;\n```\n\n你也可以利用这个 hint 强制刚才的查询选择 TiFlash，而其他查询保持不变。  \n\n```\nSELECT /*+ set_var(tidb_isolation_read_engines='tidb,tiflash') */\n    l_orderkey,\n    SUM(\n        l_extendedprice * (1 - l_discount)\n    ) AS revenue,\n    o_orderdate,\n    o_shippriority\nFROM\n    customer,\n    orders,\n    lineitem\nWHERE\n    c_mktsegment = 'BUILDING'\nAND c_custkey = o_custkey\nAND l_orderkey = o_orderkey\nAND o_orderdate < DATE '1996-01-01'\nAND l_shipdate > DATE '1996-02-01'\nGROUP BY\n    l_orderkey,\n    o_orderdate,\n    o_shippriority\nORDER BY\n    revenue DESC,\n    o_orderdate\nlimit 10;\n```\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/v7.4/optimizer-hints#set_varvar_namevar_value\n\n### CHECK 约束  \n\n`CHECK 约束` 是一致性约束检查的一种，用来维护数据的准确性。`CHECK 约束`可以用于限制表中某个字段的值必须满足指定条件。当为表添加 CHECK 约束后，在插入或者更新数据时，TiDB 会检查约束条件是否满足，如果不满足，则会报错。  \n\nMySQL 在 8.0 之前只支持 CHECK 约束的语法，在实际运行中并不会真正去检查， 在 8.0 之后才全面支持。TiDB 在新版本中也添加了这个功能， 为了防止客户的 DDL 中有残存的 CHECK 条件，可能会因为这个特性产生问题，TiDB 默认并不会开启 CHECK 约束的检查，而是通过变量 `tidb_enable_check_constraint` 手工开启， 这充分体现了 TiDB 同时兼容 MySQL 5.7 和 8.0 的产品策略。  \n\n```\nmysql> set global tidb_enable_check_constraint=on;\n\nmysql> CREATE TABLE t\n    -> ( a INT CHECK(a > 10) NOT ENFORCED, -- 不生效 check\n    ->   b INT,\n    ->   c INT,\n    ->   CONSTRAINT c1 CHECK (b > c)\n    -> );\n\nmysql> insert into t values (20,20,20);\nERROR 3819 (HY000): Check constraint 'c1' is violated.\n```\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/dev/constraints#check-%E7%BA%A6%E6%9D%9F\n\n## TiDB 工具生态提供平滑迁移体验  \n\n为了降低用户数据迁移的复杂度，TiDB 推出了一款工具 TiDB Data Migration (DM) 。它能够协助用户从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的全量数据迁移和增量数据同步。DM 支持 DDL 同步，分库分表合并，并内置多种过滤器以灵活适应不同场景，切实地提升了数据迁移的效率。  \n\n## 写在最后  \n\nTiDB 7.4 将是 TiDB 7 系列最后一个 DMR 版本，针对 MySQL 8.0 做出了诸多优化。作为 MySQL 的全面升级，TiDB 的技术领先性帮助用户应对不断变化的业务数据挑战，实现业务的持续增长和创新。TiDB 在高度兼容 MySQL 5.7 和 MySQL 8.0 特性的同时，也将持续提供技术支持，确保用户能够平滑地迁移各类业务应用程序，从而减少迁移过程中的工作量和风险。\n\n浏览 [TiDB 7.4 Release Notes](https://docs.pingcap.com/zh/tidb/v7.4/release-7.4.0)，了解更多新增和优化特性。","date":"2023-10-12","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-7.4-release","file":null,"relatedBlogs":[{"relatedBlog":{"body":"关系型数据库管理系统（RDBMS）的世界正在发生变化，分布式架构和大数据规模下的一致性比以往任何时候都更加必要。分布式SQL引擎的创造者和维护者面临着提供易用性的新范式。虽然 PingCAP 一直将此作为首要任务，但 TiDB 7.2 则直接致力于使 TiDB 数据的管理更加容易。\n\n*版本 7.2 是一个开发里程碑版本（DMR），旨在引入实验性功能，因此不适用于生产环境。对于生产部署，请参考我们最新的稳定版本（LTS）7.1，以及[相应的博客](/blog/tidb-7.1-release)。*\n\n与所有 TiDB 发布博客一样，本文专注于版本发布的主要功能亮点。有关版本的更全面信息，请参阅文档中的官方[发布说明](https://docs.pingcap.com/zh/tidb/v7.2/release-7.2.0)。\n\n## 暂停和恢复 DDL 以优先处理关键流量\n\n在前序版本中，TiDB 极大提高了 DDL 尤其是添加索引的速度。即便如此，构建索引仍然是数据库相对最为昂贵的操作之一。在线 Schema 变更使得 TiDB 的用户可以不用因此暂停业务，但数据重组的在线性质可能会对前台工作负载产生影响，尤其是对延迟和抖动敏感度高的在线业务：数据规模越大，耗时越长，您的在线流量暴露的风险就越高。虽然用户可以通过限制并发度来减少对前台流量的干扰。然而，即使如此，仍然可能会出现资源干扰的情况。\n\n为了解决这类问题，TiDB 7.2 引入了在 DDL 操作暂停能力：用户可以暂停正在进行的 DDL 操作，并在合适的时机恢复操作。\n\n总体而言，这使 DDL 操作能够在大规模数据重组对性能的影响提供了手动干预的手段，并且无需重新启动操作而因此丢失 DDL 操作进度。\n\n## 通过资源组控制不良查询的影响\n\n在最新的[稳定版本 7.1 ](/blog/tidb-7.1-release)中，通过资源组实现资源控制的功能正式 GA。该功能的目的是在同一集群上保持多个独立工作负载的性能稳定。该功能的底层机制也正好适用于一些可操作性的增强。\n\nTiDB 7.2 基于执行时间引入了基于[资源组](https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control)的全局查询超时概念，并将该控制功能提升到资源组的层面，使其更加细粒度。现在，归类为业务逻辑组的查询可以拥有自己的超时设置，避免了在集群中为所有工作负载和查询组确定“一刀切”的超时时间的需求。\n\n## 从远程对象存储中导入到 TiDB\n\n如果您是当前的 TiDB 用户，您可能已经熟悉导入服务 [TiDB Lightning](https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview)。它是一个独立的服务，具备完整的导入功能，可以通过事务层逻辑方式和通过文件系统直接进行物理导入数据。\n\n为了使从其他来源加载数据更简单，并且避免用户需要部署这个独立的服务，TiDB 7.2 将 Lightning 的物理导入服务整合到 TiDB 本身中。通过直接整合到 TiDB 中，不仅部署变得更简单，而且还为管理数据加载提供了一个 SQL 接口。在这里包含 Lightning 的功能还意味着可以直接从 AWS S3 和 Google Cloud Storage (GCS) 加载数据。\n\n有关更多信息，请[参考文档](https://docs.pingcap.com/zh/tidb/v7.2/release-7.2.0)。","author":"PingCAP","category":1,"customUrl":"tidb-7.2-release","fillInMethod":"writeDirectly","id":494,"summary":"TiDB 7.2 致力于简化数据管理，引入了暂停和恢复 DDL 操作、资源组控制查询影响以及将 TiDB Lightning 导入服务整合到 TiDB 中的功能。","tags":["TiDB","Release"],"title":"TiDB 7.2 - 更平滑的操作体验"}},{"relatedBlog":{"body":"![活动 banner.jpeg](https://img1.www.pingcap.com/prod/banner_8a580af0b8.jpeg)\n\nTiDB 7.1 是 2023 年度发布的首个 LTS（Long Term Support） 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本（TCO）。用户可在生产环境中使用 TiDB 7.1。\n\n## 半年版本回顾\n\nTiDB 7.1 LTS 距离上一个 LTS 版本 6.5 已经过去了整半年，在这期间，我们对产品的关键能力做了大量的增强和优化，其中最重要的特性有：\n\n- TiDB 7.0 提供了基于资源组的资源管控（Resource Control）：这使得 TiDB 在针对多租户场景有了很好的应对。事实上，经常有用户希望借助 TiDB 的可伸缩特性将多套业务系统归一到一个集群中，从而使得集群管理、资源利用都能得到有效的改进。资源管控特性提供了对多租户的支持，并解决了不同租户间资源争抢的问题。在新版本中，用户可以很方便地借助这个功能完善数据库整合的使用场景。\n- Multi-RocksDB 特性：借助将单一 TiKV 实例中的 RocksDB 拆成多份，TiKV 的写吞吐提升近三倍；此外，在新架构中数据分片（Region）大小将变得更大，由此减小维护分片所带来的开销，减少单位存储所需的固定 CPU 消耗，更节省成本。这使得大写入吞吐，或者需要大量存放温数据的 Data Serving 场景下，TiDB 的表现得到了本质的提升。\n\n对于这些重要的重量级特性，在新版本中也将持续得到打磨和加强。这半年中，TiDB 在一些关键场景的性能也得到长足提升：\n\n- 数据导入 Lightning 性能提升近 30%；\n- 真实业务测试下，Analyze Table 性能提升 42%+；\n- 标准测试 TPC-H 和真实业务测试下，TiDB 分析能力分别提升 15% 和 25%；\n- TiCDC 针对大型单表复制性能提升可达 90%+。\n\n## TiDB 7.1 介绍\n\nTiDB 7.1 是我们计划在 2023 年发布的两个长期可支持（LTS）版本中的第一个，它为您提供了一个面向未来的数据库，可以为各种关键业务应用程序提供动力。TiDB 7.1 为您带来：\n\n- 更稳定地支持关键业务负载，为 DBA 提供多工作负载稳定性控制，并显著改善尾部延迟；\n- 以更少的资源提供更佳的性能，通过架构增强实现更高的吞吐以及更快的在线 DDL。\n\n此外，TiDB 7.1 企业版增强了数据库审计功能，通过更细粒度的事件过滤控制、更友好的过滤条件设置方式、新增的 JSON 文件输出格式以及审计日志的生命周期管理，大幅提升系统的审计能力。\n\n### 更稳定地支持关键业务负载\n\n本节中的功能增强都属于集群稳定性的主题。更具体地说，即使在工作负载较大的情况下，TiDB 也可以保障稳定运行，并稳定处理具有特殊情况的工作负载的延迟。\n\n#### 通过资源组改进资源管控的用户体验，提供更好的隔离性\n\n我们在[文章（TiDB 7.0）](/blog/tidb-7.0-release)中介绍了通过资源组进行资源管控的功能，为 TiDB database consolidation （数据库整合）方案奠定了基础，具有里程碑的意义。多个业务可共享同一个 TiDB 集群，DBA 可为不同的工作负载设置资源配额和优先级，例如为关键业务分配更高的优先级，确保其能够优先获得资源，避免受到其他工作负载的干扰。\n\n在 TiDB 7.1 中，资源管控特性正式 GA 了，并加入了两个特性增强：\n\n- 降低了在重写入密集型工作负载中出现的尾延迟：资源组通过资源配额和优先级控制工作负载。优先级由存储级别控制。当工作负载写入繁重时，基于优先级重新调度机制有时会造成更高的尾延迟（Tail Latency）。在 7.1 版本中，尾延迟被修正到预期水准。\n- 增加原生负载校准工具，帮助用户设置更准确的资源资源分配：资源分配的基础是用户对负载的资源使用量有所了解。新增的校准工具将很好的帮助您评估相关信息，以合理配置资源组。最快的方法是从 SQL 接口运行校准命令来估计基准测试（如 TPC-C 和 sysbench）的资源使用情况。\n\n#### 多个热点场景下性能和稳定性提升\n\n对 TiDB 的底层行存储 TiKV 有三个关键增强，以降低延迟提升稳定性（通过 p99 延迟衡量）。新版本引入了三项优化，分别针对三个级别热点进行处理：Key 级别、分片（Region）级别和节点级别：\n\n- Key 级热点：锁冲突优化\n- Region 级热点：TiKV 子任务的批处理化\n- 节点级热点：引入了基于负载的副本读取\n\n**锁冲突优化（GA）**\n\nTiDB 引入了处理 Key 级热点的优化。在遇到许多单点悲观锁冲突的负载中，唤醒等待请求的算法在新版本中将表现得更稳定，最大限度地减少了重试的资源浪费，从而节省了整个集群的资源并降低了尾延迟。测试表明，当启用锁冲突优化时，如果吞吐量相对较小，即使在冲突最严重的工作负载中，新版本的尾延迟也将降低 40-60%。\n\n![QPS.png](https://img1.www.pingcap.com/prod/QPS_08931bca5b.png)\n\n![99 Latency.png](https://img1.www.pingcap.com/prod/99_Latency_b8134dcf7c.png)\n\n**批处理 TiKV 子任务（GA）**\n\n选择性较差的查询可能会导致需要读取许多数据。在 TiDB 的分布式存算分离架构中，这样的查询可能会带来数万或数十万个 RPC 请求用于获取数据，如果使用索引读取则将更进一步加重这一负担。\n\nTiDB 服务器作为 TiKV 客户端，现在可以识别针对同一分片的批处理任务，并将这些批量发送到对应的存储节点。这大大减少了网络的 RPC 开销，使得这些查询更稳定。这个增强可以将相应场景中的延迟减少多达 50%。\n\n**基于负载的副本读取（GA）**\n\n这个特性用于优化节点级读热点。当大批量查询以不均匀的方式发起读取，可能会出现节点热点。注入 Index Lookup JOIN 这类常见的事情都可能会导致这种情况。一旦发生，读取请求会排队，当队列塞满时，一些请求可能会等待相当长时间。我们希望通过更均匀地分配工作来减少延迟。\n\n新版本中，TiDB 引入了基于负载的副本读取来实现这一点。它为队列提供了一个可配置的持续时间阈值，当超过该阈值时，它会告诉 TiDB 开始优先考虑副本读取。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。\n\n有关此优化的更多信息，请[参阅文档](https://docs.pingcap.com/tidb/dev/troubleshoot-hot-spot-issues#scatter-read-hotspots)。\n\n### 更少的资源，更佳的性能\n\n本节中的功能和改进，提升了 TiDB 读、写以及管理操作的性能，以提供更好的用户体验。新版本中，TiDB 增加了多值索引以提供对 JSON 的查询效率。此外，在写入吞吐、分析查询速度和后台任务效率方面也进行了大量的改进和优化。\n\n#### 多值索引（GA）以增加速度和灵活性\n\n多值索引也称为“JSON 索引”，这种新型辅助索引在 TiDB 6.6 中引入并在 7.1 中 GA。多值索引支持索引记录到数据记录的 N:1 映射，使得查询可以快速检查存储在 JSON 数组中的特定值。\n\n例如，假设您将这样的数据存储在列中：\n\n```\n{\n\n    \"user\":\"Bob\",\n\n    \"user_id\":31,\n\n    \"zipcode\":[94477,94536]\n\n}\n```\n\n无论该数据存储为 blob，还是邮政编码直接存储为 zip 数组，用户都可以创建多值索引来定位特定邮政编码存在于哪一行。\n\n索引是使用表达式创建的，该表达式将 JSON 数据逻辑解析为生成列（Generated Column）和该列上的二级索引。如果您将 JSON 存储为 blob，并且需要支持遍历多层嵌套的查询，您只需创建一个索引以检索。\n\n有关用法和注意事项的更多详细信息，请参阅[多值索引文档](https://docs.pingcap.com/tidb/dev/sql-statement-create-index/#multi-valued-index)。\n\n#### 更快的 TTL（GA）\n\nTTL (Time to live) 在我们的 [TiDB 6.5 发布的文章](/blog/tidb-6.5-release)中作为一个实验特性进行了介绍，而在 7.1 中这个特性 GA 了。此外在新版本中，TiDB 节点可以共享 TTL 相关任务并并发执行，从而拥有了更好的性能和资源利用率。\n\n#### 延迟物化加速分析查询（GA）\n\nTiFlash 是 TiDB 的列式存储引擎，在 7.1 版本中延迟物化特性 GA。当表扫描拥有高过滤性的时候，TiDB 优化器可选择让 TiFlash 启用延迟物化。开启该特性后，TiFlash 支持下推部分过滤条件到 TableScan 算子，即先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。\n\n此功能的影响取决于实际负载和数据分布。在某些情况下，它可以显著减少延迟（在我们的测试中延迟最高可降低 70%）。TiDB 的查询优化器可以决定是否使用它，默认情况下打开是安全的。\n\n#### Multi-RocksDB 存储引擎带来巨大性能提升\n\n在 TiDB 6.6 中，我们引入了对 TiKV 存储架构的重大更改。虽然这个架构仍然是实验性的（默认关闭，并且只能在新集群中启用），但在这个 LTS 版本中，该特性获得重大加强，并在预生产环境中收到了很好的测试反馈。\n\n在 TiDB 6.6 之前，单一 TiKV 节点所有 Region 共享一个 RockDB 存储引擎。新架构则将不同 Region 分别存放在不同 RocksDB。新架构的好处是显著的：\n\n- 减少 RocksDB 对应的 LSM 负担，增加了吞吐量，测试结果显示写入吞吐量增加了 200%。\n- 使用不同 RocksDB 也会减少 Compaction 带来的写放大，降低资源消耗。\n- 更好的写入吞吐使集群的扩展速度提高 500%。\n- 在测试一些真实的客户工作负载时，我们观察到尾部延迟减少了近 50%。\n- 更小的单位存储消耗，使得集群可扩展性进一步增强。\n\n在 TiDB 7.1 中，我们进一步提高了该特性的性能和稳定性，并添加了网络带宽优化。当前仍然缺失的是 TiCDC、BR 等生态工具的支持，当这些完成后我们将宣布这个特性 GA。\n\n有关更多详细信息，请[参阅产品文档](https://docs.pingcap.com/tidb/dev/partitioned-raft-kv)。\n\n#### Online DDL 的大幅提升（实验特性）\n\n在《[天下武功唯快不破：TiDB 在线 DDL 性能提升 10 倍](/blog/10-times-online-ddl-performance-improvement)》中，我们介绍了 TiDB 索引构建操作性能的提高方式，并在 7.0 版本 GA。在 TiDB 7.1 中，类似于前述 TTL 改进，我们引入了跨 TiDB 节点分配 DDL 作业的框架，以进一步提高性能。\n\n## 立即体验 TiDB 7.1\n\n浏览 [TiDB 7.1 Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-7.1.0)，下载 TiDB [社区版](/product-community/)，了解更多新增和优化特性。\n\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-7.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n</div>\n","author":"PingCAP","category":2,"customUrl":"tidb-7.1-release","fillInMethod":"writeDirectly","id":492,"summary":"TiDB 7.1 是 2023 年度发布的首个 LTS 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本。","tags":["TiDB","Release"],"title":"TiDB 7.1 LTS 发版：为关键业务提供业务稳定性和多租户场景支持"}},{"relatedBlog":{"body":"![TiDB 7.0发版.jpeg](https://img1.www.pingcap.com/prod/Ti_DB_7_0_dd0bec1e31.jpeg)\n\n我们很高兴地宣布，TiDB 7.0 正式发布。TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。新版本中，TiDB 在可扩展性与性能、稳定性与高可用、SQL 以及可观测性几个领域获得持续提升，累计引入新特性 20 余项，优化功能 50 余项。TiDB 7.0 是 TiDB 7 系列首个 DMR 版本，适用于开发、测试和 PoC 等场景。\n\n在 7 系列版本以及之后 2-3 年的时间里，我们希望 TiDB 在不断迭代中拥有：\n\n- 更强的基础能力（核心性能，扩展性，性价比，云原生等）；\n- 更加多元化的场景支持（多租户，更多数据模型支持，更好的生态适配）；\n- 更顺滑的运维体验（更强的 DDL 能力，以 SQL 为统一界面的运维体验等，智能运维）；\n- 更可靠更安全（更高的可用性，更好的安全体系整合，更多合规认证）。这些主题都将逐步在 7 系列以及后续版本中落实，给予用户更优的使用体验，让 TiDB 变成一个好用且泛用，可靠且经济的选择。具体到 7.0 版本，TiDB 初步提供了更好的资源管控能力，让 TiDB 针对 SaaS 和多平台统一共存等场景有了根本性的解决方案；其次，TiFlash 发布了面向云的存算分离新架构，这使其可以真正做到存算资源解耦，计算资源可以按需启停，且基于 S3 的存储设计也将大幅降低存储成本；而诸如分析引擎支持落盘，自动执行计划缓存等，则是针对企业级场景做出的必要强化；最后，TiDB 7.0 提供了对 MySQL 8.0 的兼容，这将使得相关用户能更方便地迁移到 TiDB。\n\n接下来让我们具体看看新版本的情况。\n\n## 资源管控增强多租户形态下工作负载稳定性\n\n资源管控特性（Resource Control）在 TiDB 6.6 中引入（实验特性），在 TiDB 7.0 中得到增强和优化，极大地提升 TiDB 集群的资源利用效率和性能表现，为稳定的多租户奠定了基础。资源管控特性对 TiDB 具有里程碑的意义，用户可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据需要设置每个资源组的配额。该功能允许为一个或多个会话组设置资源上限，如果来自某个工作负载或应用程序的消耗异常重，则其资源消耗将被限制在配额内，以防止对其他更关键的工作负载造成干扰。  \n\n资源管控适用于以下场景：  \n\n- 用户可以将多个应用程序合并到单个 TiDB 集群中，降低 TCO 并保证重要工作负载所需的资源。\n- 用户可以在业务运营时间内安全运行批处理任务。\n- 模拟环境（Staging Environments）可共享具有受资源管控限制的单个 TiDB 集群。\n\n会话可通过三种方式绑定到资源组：通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组，使得用户会话始终受到设定边界约束；通过 `SET RESOURCE GROUP` 设置当前会话的资源组；也可通过优化器 Hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n## TiFlash 支持数据落盘来稳定分析工作负载\n\nTiFlash 是 TiDB 的列存储和计算引擎，是数据库分析工作负载能力的支柱。在 TiDB 7.0 之前，TiFlash 在内存中处理所有数据。从这个版本开始，TiFlash 支持数据落盘功能（Spill to disk），通过调整算子内存使用阈值，控制对应算子的最大内存使用量。对于大查询而言，当算子使用内存超过一定阈值时会自动将数据落盘，牺牲一定的性能换取整体分析查询的稳定性。数据落盘操作根据用户配置参数进行，并适用于单个推送下去的操作。由于该优化发生在单个运算符级别上，因此必须在多个位置执行数据落盘操作。在 TiDB 7.0 中，它首先被应用于以下情况：  \n\n- 相等条件下的哈希连接；\n- GROUP BYs 上的哈希聚合；\n- 窗口函数中 TopN 和排序运算符。\n\n在执行这些操作期间，如果运算符使用的内存量超过了配置限制，会自动将数据落盘并继续进行后续处理。为了说明目标工作负载受影响程度，我们模拟了决策支持系统，使用 TPC-H 基准测试工具进行测试，结果如下表所示：  \n\n![TPC-H 基准测试工具测试结果.png](https://img1.www.pingcap.com/prod/TPC_H_54be3f1f7f.png)\n\n## 自动计划缓存减少查询延迟  \n\n在此之前，TiDB 已经支持使用 PREPARE 准备语句来进行计划缓存。TiDB 7.0 中，非 Prepare 语句的执行计划也能够被缓存，使执行计划缓存能够应用于更广泛的场景。该功能支持在会话级别上对查询进行缓存，全局级别的支持将在未来发布中推出。会话级别的缓存将减少由于查找正确计划而导致的延迟，但可能也会增加全局缓存中可能存在重复数据时所需内存。目前可以通过此功能进行单表过滤和范围查询类型的查询进行缓存，但不能够处理单表复杂查询和 JOIN 查询等其他类型。  \n\n## TiFlash 支持存算分离架构，降低数据分析成本\n\n在 TiDB 7.0 版本，TiFlash 支持存算分离和 S3 对象存储（实验特性）。之前版本的 TiFlash 是存算一体架构，TiFlash 节点既是存储节点，也是计算节点，其计算和存储能力扩展受到一定限制。同时，TiFlash 节点只能使用本地存储。在 7.0 版本中，TiFlash 支持存算分离架构，分为 Write Node 和 Compute Node 两种节点，可以分别部署，单独按需扩展，并支持将数据存储在 Amazon S3 或兼容 S3 API 的对象存储中。  \n\n![TiFlash 存算分离架构.png](https://img1.www.pingcap.com/prod/Ti_Flash_4db2295760.png)\n<center>图：TiFlash 存算分离架构</center>\n\nTiFlash 存算分离架构适用于高性价比的数据分析场景。在数据量很大，但是只有少量数据被频繁查询，大部分冷数据很少被查询的场景下，将经常被查询的数据缓存在 Compute Node 的本地 SSD 上，可以提供较快查询性能，将大量冷数据存储在成本较低的 S3 或者其他对象存储上，从而节省存储成本。在计算资源需求有明显的波峰和波谷场景下，例如晚上执行的重型对账查询，对计算资源要求较高，可以临时扩展 Compute Node，其他时间可以用较少的 Compute Node 完成查询任务。TiFlash 的存算分离架构大幅降低了使用 TiFlash 支持分析工作负载的成本，并且提供了一定程度的工作负载隔离。目前，TiUP 和 TiDB Operator 已经支持部署和缩放 TiFlash 独立组件的能力。  \n\n## TTL 定期删除过期数据为系统减负\n\nTiDB 6.5 引入了 Time to live（TTL）实验特性，提供了行级别的生命周期控制策略，该项特性在 TiDB 7.0 中正式 GA。TTL 是一种通过 SQL 配置设置表中行到期时间的方式，帮助用户周期性且及时地清理不需要的数据，并尽量减少对用户负载的影响。TTL 以表为单位，并发地分发不同的任务到不同的 TiDB Server 节点上，进行并行删除处理。在某些情况下，较大的表格意味着查询时间更长；较大的表格意味着更多的存储成本；在 TiDB 中，一个表越大，Region 就越多，限制表格大小可以减轻系统负担；各种合规性要求可能需要设置数据过期。基于成本、性能或安全等因素考虑，数据库管理员可以配置自动检查并删除过期的表格行数据，例如定期删除验证码、短网址记录、不需要的历史订单、计算的中间结果等。  \n\n## 使用 Key 分区提高可扩展性  \n\n在 7.0 之前，TiDB 支持 Hash、Range 和 List 分区。新版本引入了 key 分区，与 Hash 分区类似，Key 分区可以保证将数据均匀地分散到一定数量的分区里面。Hash 分区只能根据一个指定的整数表达式或字段进行分区，而 Key 分区可以根据字段列表进行分区，且 Key 分区的分区字段不局限于整数类型。Key 分区提供了一种更灵活的方式来对数据集进行划分以改善集群的可扩展性。\n\n## 使用 REORGANIZE PARTITION 适应不断变化的需求  \n\nTiDB 长期以来一直支持分区，修改分区表的唯一方法是添加或删除分区和截断 LIST/RANGE 分区。TiDB 7.0 TiDB 支持 ALTER TABLE... REORGANIZE PARTITION 语法，用户可以对表的部分或所有分区进行重新组织，包括合并、拆分、或者其他修改，并且不丢失数据，增加了可用性和灵活性以满足不断变化的需求。  \n\n## 使用 LOAD DATA 从远程存储导入数据  \n\nTiDB 7.0 中，`LOAD DATA` 语句集成 TiDB Lightning，用户可以使用 `LOAD DATA` 语句完成原先需要使用 TiDB Lightning 才能完成的数据导入任务（实验特性），不仅可以省去 TiDB Lightning 的部署和管理成本，还可以借助 TiDB Lightning 的功能极大扩展 `LOAD DATA` 语句的能力，包括：支持从 Amazon S3 和 Google Cloud Storage 导入数据到 TiDB，且支持使用通配符一次性匹配多个源文件导入到 TiDB；支持查询任务状态，添加操作便利性等。  \n\n浏览 TiDB 7.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v7.0/release-7.0.0)，了解更多新增和优化特性。立即下载试用，开启崭新的 TiDB 探索之旅。企业级用户期待的 TiDB 7.1 LTS 版本将很快与大家见面，敬请期待！\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-7.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n","author":"PingCAP","category":2,"customUrl":"tidb-7.0-release","fillInMethod":"writeDirectly","id":473,"summary":"TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。","tags":["TiDB","Release"],"title":"TiDB 7.0 发版"}}]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}