关于tidb:Runaway-Queries-管理提升-TiDB-稳定性的智能引擎

在数字化零碎表演重要角色的明天，数据库稳定性成为企业关注的外围问题。对于重要计算机系统而言，突发的性能降落可能对业务造成不可估量的损失。为了稳固数据库性能，用户能够从治理流程动手标准变更的测试，或者利用产品伎俩缩小预期外的变动。然而，这仍旧无奈齐全躲避突发的 SQL 性能问题，其中的起因包含但不仅限于：

数据量和数据分布激烈变动，从前被验证过的执行打算可能变得效率更低。
数据库中的查问变得越来越简单，优化器对执行打算的抉择存在不可控因素。
频繁的业务更新给测试带来微小压力，未经充沛验证的 SQL 有潜在的性能问题。

对于一些对提早十分敏感的利用而言，这些潜在问题有可能对业务造成不可估量的损失。如何升高这类不可控的突发问题对业务的影响，是摆在每个管理者背后的难题。

做为资源管控的一部分，TiDB 在 7.2.0 引入 Runaway Queries 治理，并继续加强，旨在通过系统化的伎俩缓解上述难题。

本文将从从实用场景、实现原理等角度具体介绍 TiDB 的 Runaway Queries 治理性能，并通过一个示例展现其在零碎中的作用。

Runaway Queries 是指执行工夫或耗费资源超出预期的查问，在运行工夫和资源耗费上有显著特色。

Runaway Queries 治理旨在提供一种高效、可控、自动化的资源辨认和管控机制，以升高突发 SQL 性能问题带来的负面影响，爱护简单工作负载下零碎的稳定性，让 TiDB 更加牢靠。

● 为了保障重要零碎的服务质量，须要可能自动识别并解决异样 SQL 性能问题。

● 当遇到突发 SQL 性能问题，但又没有立刻无效的修复伎俩时，心愿长期缓解其影响。

● 当已知个别 SQL 有平安或性能问题，心愿退出黑名单或对其进行限流。

Runaway Queries 治理次要提供两个重要能力，即对查问的 “辨认” 和 “处理”。

TiDB 资源管控模块提供两类辨认形式

● 动静辨认 – 依据运行时规定辨认 。指依据 SQL 理论运行指标自动识别（通过 resource group 定义），目前反对利用 EXEC_ELAPSED 设置理论执行工夫，即当查问运行工夫超过 EXEC_ELAPSED 的定义时，这个查问会被辨认为 Runaway Query。比方：

ALTER RESOURCE GROUP default QUERY_LIMIT=(EXEC_ELAPSED='5s', ACTION=KILL);

○ 下面命令执行的成果是，属于 default 资源组的查问运行超过 5 秒钟，那么这个查问会被辨认为 Runaway Query。(辨认规定的失效范畴为“资源组”，如果你没有创立任何资源组，那么能够批改 default 资源组的规定将会对全局无效。)

○ TiDB 特意提供了每个资源组 Query Max Duration 的监控指标，可能查看一段时间内运行工夫最长的查问，这个指标可能帮助设置一个正当的 EXEC_ELAPSED .

Resource Group 的定义同时反对将辨认到的 SQL 特色同时退出监控列表特定一段时间，即一段时间内，资源管控间接辨认 SQL 特色而无需用规定辨认。相当于将 SQL 放入监控名单，并阶段性查看是否它曾经恢复健康。

ALTER RESOURCE GROUP default QUERY_LIMIT=(EXEC_ELAPSED='5s', ACTION=KILL, WATCH=SIMILAR DURATION='10m');

○ 上述例子里，咱们向配置里退出了 WATCH 规定，那么和被辨认成 Runaway Query 查问相似的查问（比方只有过滤值不同），在接下来的 10 分钟里，会间接执行对应操作，而不会再期待 5 秒。10 分钟之后，如果这个查问的性能曾经复原，则不再对其进行限度；如果没有复原，则再次对这个查问监控 10 分钟。

● 动态辨认 – 依据 SQL 特色辨认 。主动筛选规定并不能准确的辨认出所有有问题的查问，因而咱们退出了对监控列表的人工治理。通过 query watch 命令定义 SQL 特色辨认及处理规定，可能达到数据库查问黑名单的作用。目前已反对的 SQL 特色的设置：

○ SQL Text : 依据 SQL 文本做准确匹配。

○ SQL Digest : 依据 SQL Digest 匹配模式雷同的查问。比方 select c from t1 where a=1 和 select c from t1 where a=2 领有雷同的 Digest。

○ Plan Digest : 依据 Plan Digest 匹配执行打算雷同的查问。雷同 SQL 可能存在多个执行打算，造成性能问题的往往是其中少部分执行打算。

SQL 特色能够通过“慢查问”等形式采集，这里是一个“慢查问”示例

SELECT count(1)    FROM  sbtest.sbtest1 AS S1        ,sbtest.sbtest2 AS S2        ,sbtest.sbtest3 AS S3  WHERE S1.c=S2.c     AND S1.c=S3.c;
# Time: 2023-09-19T17:16:56.640436+08:00
...
# Digest: d3c7846bb8f6b817ae395db30eadedec57af08f7983466f68db93d9ce1ac5872
...
# Plan_digest: 41fee801f07e06aa4aba4c0142ce4c624e8dc932c9e14d49854b8ce57366b443

用户能够依据教训抉择其中一种辨认形式，比方上面例子里用 SQL DIGEST 子句将相似的查问退出监控队列，那么和此查问相似的查问会被辨认并做出对应的处理。

mysql> QUERY WATCH ADD ACTION KILL SQL DIGEST 'd3c7846bb8f6b817ae395db30eadedec57af08f7983466f68db93d9ce1ac5872';
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT * FROM INFORMATION_SCHEMA.RUNAWAY_WATCHES ORDER BY id\G
*************************** 1. row ***************************
                 ID: 54
RESOURCE_GROUP_NAME: default
         START_TIME: 2023-09-20 01:59:14
           END_TIME: UNLIMITED
              WATCH: Similar
         WATCH_TEXT: d3c7846bb8f6b817ae395db30eadedec57af08f7983466f68db93d9ce1ac5872
             SOURCE: manual
             ACTION: Kill
1 row in set (0.04 sec)

处理，指被辨认到的 Runaway Queries 要如何解决。目前反对以下几个解决形式。

● DRYRUN：仅辨认不做解决，在日志和对应视图中显示。初期配置的时候，能够利用 DRYRUN 试运行一段时间，检测是否有误判的危险。

● COOLDOWN：将查问置于资源组的最低优先级，限度其处理速度。

● KILL：终止被辨认的查问，避免其进一步影响数据库性能。

○ 在 7.5.0 版本，COOLDOWN 在简单场景下的限度作用无限，如果对服务质量要求比拟高，则举荐设置 KILL

在这个例子里，被辨认为 Runaway Queries 的查问会被主动勾销。

ALTER RESOURCE GROUP default QUERY_LIMIT=(EXEC_ELAPSED='5s', ACTION=KILL, WATCH=SIMILAR DURATION='10m');

以上所有的设置，及辨认和处理的历史记录，TiDB 提供了一组零碎表用于查问：

● INFORMATION_SCHEMA.RESOURCE_GROUPS：资源组定义，包含对 Runaway Queries 辨认规定和处理设置。

● INFORMATION_SCHEMA.RUNAWAY_WATCHES：监控队列中的规定。

● MYSQL.TIDB_RUNAWAY_QUERIES：记录被辨认和处理的 Runaway Queries 历史记录。

失常负载下，整体 QPS 靠近 11k , P999 在 50ms 高低。
呈现一个异样查问，每秒提交一次，运行工夫在 3~8 秒，QPS 从 11K 急剧下降至 3K 左右，P999 由 60ms 减少到 200ms。
这时咱们尝试向 default 资源组退出一条规定，主动杀掉运行工夫超过 1 秒的查问。QPS 回升至 7.5k，P999 降落。

mysql> alter resource group default QUERY_LIMIT=(EXEC_ELAPSED='1s', ACTION=KILL);
Query OK, 0 rows affected (1.02 sec)

mysql> SELECT * FROM information_schema.resource_groups;
+---------+------------+----------+-----------+--------------------------------+------------+
| NAME    | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT                    | BACKGROUND |
+---------+------------+----------+-----------+--------------------------------+------------+
| default | UNLIMITED  | MEDIUM   | YES       | EXEC_ELAPSED='1s', ACTION=KILL | NULL       |
+---------+------------+----------+-----------+--------------------------------+------------+
1 row in set (0.01 sec)

通过零碎表 mysql.tidb_runaway_queries，咱们看到 Runaway 治理开始染指，有问题的 SQL 被继续标记并解决。

mysql> select * from mysql.tidb_runaway_queries limit 1 \G
*************************** 1. row ***************************
resource_group_name: default
               time: 2023-09-19 15:18:10
         match_type: identify
             action: kill
       original_sql: SELECT count(1)
  FROM  sbtest.sbtest1 AS S1
       ,sbtest.sbtest2 AS S2
       ,sbtest.sbtest3 AS S3
 WHERE S1.c=S2.c
    AND S1.c=S3.c
        plan_digest: 41fee801f07e06aa4aba4c0142ce4c624e8dc932c9e14d49854b8ce57366b443
        tidb_server: 127.0.0.1:4000


mysql> select count(*) from mysql.tidb_runaway_queries;
+----------+
| count(*) |
+----------+
|       56 |
+----------+
1 row in set (0.02 sec)

这里 QPS 仍没有回升至原先的程度，因为尽管会把运行超过 1 秒的查问杀掉，但每个查问仍旧都会运行 1 秒，对系统仍旧造成耗费 。

批改资源组规定，把合乎 runaway 规定的查问的文本，退出到监控列表中，时长为 5 分钟。这意味着，如果文本匹配到被标记为 runaway 的查问，那么会被间接杀掉，不再期待 1 秒；而每隔 5 分钟，TiDB 会主动放开限度，检查一下查问的性能是否复原。如果复原，则不再对此查问进行勾销解决。这时零碎的 QPS 和 P999 复原到阶段 1 的程度。

mysql> alter resource group default QUERY_LIMIT=(EXEC_ELAPSED='1s', ACTION=KILL, WATCH=EXACT DURATION='5m');
Query OK, 0 rows affected (0.53 sec)

mysql> SELECT * FROM information_schema.resource_groups;
+---------+------------+----------+-----------+-------------------------------------------------------------+------------+
| NAME    | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT                                                 | BACKGROUND |
+---------+------------+----------+-----------+-------------------------------------------------------------+------------+
| default | UNLIMITED  | MEDIUM   | YES       | EXEC_ELAPSED='1s', ACTION=KILL, WATCH=EXACT DURATION='5m0s' | NULL       |
+---------+------------+----------+-----------+-------------------------------------------------------------+------------+
1 row in set (0.00 sec)

查看视图，有一条 watch 规定生成：

mysql> SELECT * FROM INFORMATION_SCHEMA.RUNAWAY_WATCHES ORDER BY id\G
*************************** 1. row ***************************
                 ID: 50
RESOURCE_GROUP_NAME: default
         START_TIME: 2023-09-19 16:58:20
           END_TIME: 2023-09-19 17:03:20
              WATCH: Exact
         WATCH_TEXT: SELECT count(1)
  FROM  sbtest.sbtest1 AS S1
       ,sbtest.sbtest2 AS S2
       ,sbtest.sbtest3 AS S3
 WHERE S1.c=S2.c
    AND S1.c=S3.c
             SOURCE: 127.0.0.1:4000
             ACTION: Kill
1 row in set (0.01 sec)

有问题的查问被执行时会间接退出，告知曾经被监控隔离：

ERROR 8254 (HY000): Quarantined and interrupted because of being in runaway watch list

至此，咱们看到，通过对异样查问的自动识别和监测，可能无效限度个别 SQL 的资源耗费，缓解其对整体性能的影响。

在上述示例中，即便没有设置资源组对查问的自动识别，在呈现 SQL 性能问题时，咱们仍能够通过“慢日志”或者零碎表找出问题查问的“特色”，用 QUERY WATCH 手工将查问退出监督列表，达到设置黑名单的成果。

TiDB Runaway Queries 治理的一个显著劣势是晋升了用户体验。通过自动化和手动治理的联合，用户可能更轻松地监控和管制数据库中的 Runaway Queries，防止它们对失常业务的烦扰。

将来，TiDB 会继续加强治理 Runaway Queries 的能力， 反对更多且简单的辨认规定，减少更丰盛的解决伎俩，全面晋升可观测性，通过引入图形化治理的形式进一步晋升用户体验 ，为 TiDB 迈向企业级数据库平台保驾护航。

关于tidb:Runaway-Queries-管理提升-TiDB-稳定性的智能引擎

什么是 Runaway Queries

Runaway Queries 治理实用哪些场景

Runaway Queries 治理能做什么

3.1 查问的辨认

3.2 查问的处理

3.3 历史记录及观测性

运行示例

瞻望