MySQL 8.0 资源组（Resource Groups）深度解读

最新推荐文章于 2023-03-20 23:22:02 发布
最新推荐文章于 2023-03-20 23:22:02 发布
阅读量1.1k 收藏 3
点赞数 1
原文链接：https://mp.weixin.qq.com/s?__biz=MzUzOTc2MjcwOQ==&mid=2247485109&idx=1&sn=0a7512c0f3eabdd98c4b8b8f7fabc568&chksm=fac2cfcfcdb546d9ea019d900dd2b96057b762f70b4f76c4b04c1d12d31d5799fc1c844da4a6&token=1972471647&lang=zh_CN#rd
版权

MySQL 8.0 资源组（Resource Groups）深度解读

原创 tiredboy 网易游戏运维平台 

 

tiredboy

网易游戏运维工程师，目前主要负责数据库相关的运维工作。

熟悉容器化（docker/k8s）的同学，可能经常听到 cgroups 或者 taskset，通过 cgroups 我们可以在系统层面为不同的进程分配不同的 CPU，以实现对进程使用资源的精细化控制。MySQL 8.0 也给我们带来了一个新的特性：Resource Groups
(https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html)。
后文简称 RG，通过 RG 我们也可以实现对 MySQL 内部线程资源的精细化控制（目前仅支持 CPU 方面的绑定调度）。

相信经常使用 MySQL 的同学都碰到过让自己头痛的问题：某个「烂」 SQL 占用了大量的 CPU 资源，导致其它正常查询不能被响应，甚至导致 MySQL 直接挂掉，为了解决这个问题，通过我们会用下面两个办法来解决：

  1. 设置 max_execution_time 来阻止长时间运行的 SQL。当然，后果就是当你确实有个 SQL 就是要跑这么久的时候，会被一视同仁的干掉；

  2. 自己通过外部工具或脚本，周期性检查，并杀掉相应 thread。且不说在负载高的时候，可能这个脚本都无法正常连接 MySQL Server，周期性检查这种明显具备滞后性的操作，对业务的影响是不可避免的。

RG 的引入可以在很大程度上解决这个问题，对于复杂、执行时间长、消耗资源多，但又不希望它们影响业务的任务（比如一些计算、统计性质的批处理），我们可以对这部份任务设置特定的资源组，限制任务的使用资源，避免对其它业务线程的影响，保证服务质量。

测试样例

为了更直观的观察 CPU 占用情况，我利用存储过程制造了一个 MySQL CPU 炸弹 bomb，样例如下：

mysql> DELIMITER //
mysql> CREATE PROCUDURE bomb(OUT ot BIGINT)
    -> BEGIN
    ->     DECLARE cnt BIGINT DEFAULT 0;
    ->     SET @FUTURE = (SELECT NOW() + INTERVAL 120 SECOND);
    ->     WHILE NOW() < @FUTURE DO
    ->         SET cnt = (SELECT cnt + 1);
    ->     END WHILE;
    ->     SELECT cnt INTO ot;
    -> END
    -> //
mysql> DELIMITER ;

该存储过程 bomb 主要实现三个功能：

  1. 通过简单的 SELECT +1 死循环快速占用大量 CPU；

  2. 存储过程将执行 2 分钟；

  3. 存储过程会统计实际计算次数，并保存至存储过程的 OUT 变量。

其中 2 和 3 主要是为了测试 RG 的线程优先级用的（THREAD PRIORITY）。

如何使用 Resource Groups

特别留意：对于启用了线程池的 MySQL 目前是用不了 RG 的，当然了，我们这里用的是官方开源版，线程池当然是没有了。

MySQL 的 RG 信息保存在 infromation_schema.resource_groups 通过命令：

mysql> SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS\G

可以看到系统默认已经有了两个 RG：URS_default 和 SYS_default，分别对应用户（前台）线程和系统（后台）线程。可以通过查询 performance_schema.threads 可以查看当前 MySQL 线程分别对应的资源组：

mysql> select * from performance_schema.threads\G

对 Resource Groups 的操作主要涉及两个权限：

  1. 创建、删除、修改 RG，需要有 RESOURCE_GROUP_ADMIN 权限
    (https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-admin) ；

  2. 设置资源组（SET RESOURCE GROUP）需要有 RESOURCE_GROUP_USER 权限
    (https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-user) ；

环境要求与配置

这里仅涉及 Linux 操作系统的说明，官方对于各平台（MacOS/FreeBSD/Windows/Linux）均有详细的说明，可以参考这里：Resource Groups Restrictions
(https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html#resource-group-restrictions)。

Linux 系统上为了使用线程优先级（THREAD PRIORITY）功能，需要给予 MySQLD 二进制文件 CAP_SYS_NICE 能力。由于我们使用的是 systemd，配置也相对简单：

sudo systemctl edit mysqld

在自动打开的编辑器里增加以下内容：

[Service]
AmbientCapabilities=CAP_SYS_NICE

保存退出，并通过 systemctl restart mysql 重启 MySQL Server 即可。

请注意：未设置 CAP_SYS_NICE 时，修改资源组涉及 THREAD_PRIORITY 的操作也并不会报错，但会有 warnings，通过 SHOW WARNINGS 可以看到 THREAD_PRIORITY 默认被忽略了：

Attribute thread_priority is ignored (using default value).

使用

对 Resouce Groups 的增删改查等操作，在文档 8.12.5 Resource Groups(https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html) 有非常详细的描述。
本节不再赘述，主要是通过两个案例来检查 RG 在 CPU 绑定和线程优先级控制方面的能力。

  1. 为特定线程或当前 connection 绑定指定 CPU。下图我们创建了一个名为 rg 的 RG，并指定当前 connection/session 使用这个 RG，通过上述的 CPU 炸弹和 Linux 自带的 top 命令，可以看到 CPU 1 被占用。

  1. 创建一个低优选级 RG low，线程优先级为 15，创建一个高优先级 RG high，线程优先级为 5（请注意优先级数字越低，表示优先级越高），两个 RG 绑定了同一个 CPU：CPU0。我们通过上述的 CPU 炸弹来看一下分别绑定这两个 RG 时，线程优先级是否起到有效作用（可以看到高优先级的会话计算数量是低优先级会话的 8 倍多）：

注意事项

  1. 当一个 RG 被绑定后，如 SET RESOURCE GROUP rg，该 RG 默认不能被删除，除非当前连接断开或具体绑定的任务执行完成；

  2. 创建、删除、修改 RESOURCE GROUP 是否会在主从之间同步：不同步，也不生成 binlog 日志；

  3. 为了保障系统线程的优先级：类型为 SYS 的系统后台线程，thread priority 只能设置为 -20 ~0 之间，而普通 user 线程，则在 0~19 之间；

  4. 除了上述 SET RESOURCE GROUP 的方式绑定 RG，也可以通过 SQL HINT 的方式进行 RG 绑定，如：select /* + RESOURCE_GROUP(rg) */ * from performance_schema.threads;

  5. 通过 SET RESOURCE GROUP ${rg} FOR ${thread_id} 为特定线程绑定 RG 时，需要注意，${thread_id} 是 performance_schema.threads 里看到的 THREAD_ID 而非 SHOW PROCESSLIST 看到的 Id；

  6. 启用了线程池的 MySQL 目前暂时无法使用 RG；

RG 实现原理

RG 整体的实现可以参考 WL#9467
(https://dev.mysql.com/worklog/task/?id=9467)

根据 sql/resourcegroups/platofrm (https://github.com/mysql/mysql-server/tree/8.0/sql/resourcegroups/platform)下的文件来看，提供了对 Linux/FreeBSD/Apple/Win 的支持，我们这里主要关注 Linux 上的实现。

Linux 的实现直接使用了 sched_setaffinity 来完成 CPU 的绑定

这个如果用过 taskset (https://github.com/karelzak/util-linux/blob/master/schedutils/taskset.c)命令的同学可能比较好理解，举个例子，我们可以通过命令 taskset -pc 0,1 1888 为 PID 为 1888 的进程绑定使用 0 和 1 两个 CPU。

RG 这里的实现是相同的，代码主要在 sql/resourcegroups/platform/thread_attrs_api_linux.cc
(https://github.com/mysql/mysql-server/blob/ea7d2e2d16ac03afdd9cb72a972a95981107bf51/sql/resourcegroups/platform/thread_attrs_api_linux.cc#L72) ：

  cpu_set_t cpu_set;

  CPU_ZERO(&cpu_set);
  for (const auto &cpu_id : cpu_ids) CPU_SET(cpu_id, &cpu_set);
  int rc = ::sched_setaffinity(thread_id, sizeof(cpu_set), &cpu_set);
  if (rc != 0) {
    char errbuf[MYSQL_ERRMSG_SIZE];
    LogErr(ERROR_LEVEL, ER_RES_GRP_SET_THR_AFFINITY_FAILED, thread_id,
           my_errno(), my_strerror(errbuf, MYSQL_ERRMSG_SIZE, my_errno()));
    return true;
  }
  return false;

实现上来看没有太多的黑科技，把系统的接口封装成 SQL 语句提供给用户，底层的实现还是通过系统 API 给线程直接绑定 CPU。这也可以理解为什么启用线程池后目前还无法使用 RG，毕竟这里 CPU 绑定的最小粒度是线程。

已知的 RG 限制

  1. 目前 RG 仅支持对 CPU 的绑定和线程优先级，暂不支持其它资源的控制调度。其实从目前 Linux 的发展来看，cgroups 在进行 io 等调度方面还有比较多的瓶颈，短期可能也期望不了 RG 在这一块会有突破。但是，CPU 调度已经可以解决很多问题了，不是么。

  2. 在特定环境下，比如通过 cgroups 限制了 CPU 的容器环境，可能无法有效进行资源调度。针对这一点，下面做详细说明：

    举个例子，我们通过 LXC 启动了一个容器，并分配了 3、4、7、8 共 4 个 CPU。在容器内启动 MySQL Server。我们先来看一下，默认的两个 RG 分别是什么样的：

    mysql> select * from information_schema.resource_groups\G
*************************** 1. row ***************************
  RESOURCE_GROUP_NAME: USR_default
  RESOURCE_GROUP_TYPE: USER
RESOURCE_GROUP_ENABLED: 1
             VCPU_IDS: 0-3
      THREAD_PRIORITY: 0
*************************** 2. row ***************************
  RESOURCE_GROUP_NAME: SYS_default
  RESOURCE_GROUP_TYPE: SYSTEM
RESOURCE_GROUP_ENABLED: 1
             VCPU_IDS: 0-3
      THREAD_PRIORITY: 0
2 rows in set (0.01 sec)

mysql>

    可以看到 VCPU_IDS 都是 0-3 ，也就是 0、1、2、3 共 4 个 CPU，我们来尝试一下绑定第二个 CPU，也就是 CPU1:

    mysql> CREATE RESOURCE GROUP rg
   ->     TYPE = USER
   ->     VCPU = 1;
Query OK, 0 rows affected (0.00 sec)

mysql>

    RG 创建成功了。但是我们来绑定一下呢：

    mysql> SET RESOURCE GROUP rg;
ERROR 3661 (HY000): Unable to bind resource group rg with thread id (308485).(Failed to apply thread resource controls).

    可以看到绑定失败了。这是因为当 MySQL 尝试去绑定 CPU1 时，宿主系统并没有分配 CPU1 给 MySQL。那如果我们来尝试直接使用系统预分配的 CPU ID 来绑定呢，比如 CPU4，我们直接修改原 rg 为 CPU4，看看会是什么情况：

    mysql> ALTER RESOURCE GROUP rg VCPU=4;
ERROR 3652 (HY000): Invalid cpu id 4

    可以看到这个时候也是无法绑定的。到这里基本上可以确认 MySQL 8.0 RG 在容器环境基本上无法正常使用。那么为什么呢？

    我们在 sql/resourcegroups/resource_group_sql_cmd.cc 找到如下代码：
    (https://github.com/mysql/mysql-server/blob/ea7d2e2d16ac03afdd9cb72a972a95981107bf51/sql/resourcegroups/resource_group_sql_cmd.cc#L121)

    bool validate_vcpu_range_vector(
   std::vector<resourcegroups::Range> *vcpu_range_vector,
   const Mem_root_array<resourcegroups::Range> *cpu_list, uint32_t num_vcpus) {
 ...
   if (vcpu_range.m_start >= num_vcpus || vcpu_range.m_end >= num_vcpus) {
     my_error(ER_INVALID_VCPU_ID, MYF(0),
              vcpu_range.m_start >= num_vcpus ? vcpu_range.m_start
                                              : vcpu_range.m_end);
     return true;
   }
 ...
 return false;
}

    MySQL 在对资源组变更的时候会判断 CPU 是否合理，比如上述我们希望绑定 VCPU=4，但是 MySQL 只看到 4 个 CPU（最大 CPU 号为 3），导致无法绑定。VCPU=1 时虽然创建成功了，但在实际绑定的时候，由于宿主系统并未分配 CPU1 给这个容器，导致绑定的时候系统拒绝，出错了。

    这里我个人是认为 MySQL 在实现这一块逻辑的时候偷懒的了，更合理的做法应该是通过看到的具体的 CPU 来去判断，而不是通过看到的 CPU 数量直接限制，这一块的逻辑并不复杂，写了一个 demo 来在容器中获取实际宿主分配的 CPU：

    /*
* gcc -lpthread -o get_cpus get_cpus.c
*/
#include <stdio.h>
#define __USE_GNU
#include <sched.h>
#include <unistd.h>
#include <pthread.h>

void main() {
   /*
    * sys_vcpu_cnt: system cpu numbers
    * thread_vcpu_cnt: affinity cpu from the thread itself
    */
   int sys_vcpu_cnt, thread_vcpu_cnt;
   // GET VCPUS FROM sysconf
   #ifdef _SC_NPROCESSORS_ONLN
       sys_vcpu_cnt = sysconf(_SC_NPROCESSORS_ONLN);
   #elif defined(_SC_NPROCESSORS_CONF)
       sys_vcpu_cnt = sysconf(_SC_NPROCESSORS_CONF);
   #endif
   printf("SYSTEM VCPU COUNT: %d\n", sys_vcpu_cnt);

   // GET CPU FROM THREAD SELF
   cpu_set_t set;

   if (pthread_getaffinity_np(pthread_self(), sizeof(set), &set) == 0)
       thread_vcpu_cnt = CPU_COUNT(&set);
       printf("THREAD VCPU COUNT: %d\n", thread_vcpu_cnt);
       int j;
       // CAN BE TESTED BY: taskset -c 0,2 ./get_cpus
       for (j=0; j < sys_vcpu_cnt; j++)
           if (CPU_ISSET(j, &set))
               printf("CPU %d\n", j);
}

    我们来运行一下试试，./get_cpus：

    SYSTEM VCPU COUNT: 40
THREAD VCPU COUNT: 4
   CPU 3
   CPU 4
   CPU 7
   CPU 8

    可以看到，通过系统提供的接口拿到正确的 CPU ID，并不复杂。我们可以认为是开发者没有考虑到容器化的情况（说坏话就是偷懒）。

LXC/ 容器想用 RG，怎么办？

从上面的内容来看，MySQL 阻止分配不合理的 VCPU 主要是通过看到的 CPU 数量 num_vcpus 来判定的，那么有没有可能我们让 MySQL 看到所有的 CPU 呢，这样首先就可以突破 MySQL 在 SQL 层面的检查并正常创建 RG 了。唯一要注意的是，我们在操作时，要确保分配的  CPU ID 是与宿主分配的一致（否则实际绑定时还是会被系统拒绝）。

我们来看一下 MySQL RG 里 CPU 数量是怎么计算的，代码在 sql/resourcegroups/platform/thread_attrs_api_common.cc
(https://github.com/mysql/mysql-server/blob/ea7d2e2d16ac03afdd9cb72a972a95981107bf51/sql/resourcegroups/platform/thread_attrs_api_common.cc#L37)

具体追溯，最后的计算发生在 sql/resourcegroups/platform/thread_attrs_api_linux.cc
(https://github.com/mysql/mysql-server/blob/ea7d2e2d16ac03afdd9cb72a972a95981107bf51/sql/resourcegroups/platform/thread_attrs_api_linux.cc#L149) ：

#ifdef HAVE_PTHREAD_GETAFFINITY_NP
  cpu_set_t set;

  if (pthread_getaffinity_np(pthread_self(), sizeof(set), &set) == 0)
    num_vcpus = CPU_COUNT(&set);
#endif  // HAVE_PTHREAD_GETAFFINITY_NP

  return num_vcpus;
}

uint32_t num_vcpus_using_config() {
  cpu_id_t num_vcpus = 0;

#ifdef _SC_NPROCESSORS_ONLN
  num_vcpus = sysconf(_SC_NPROCESSORS_ONLN);
#elif defined(_SC_NPROCESSORS_CONF)
  num_vcpus = sysconf(_SC_NPROCESSORS_CONF);
#endif

  return num_vcpus;
}

由于有 pthread_getaffinity_np 的支持，根据上面的 get_cpus 样例，MySQL 最终引用的是该函数来计算 CPU，也就是 4 个。

思路到这里其实会比较明确了，如果我们希望在容器环境里正常使用该功能，最快的方式就是把 configure.cmake(https://github.com/mysql/mysql-server/blob/ea7d2e2d16ac03afdd9cb72a972a95981107bf51/configure.cmake#L297) 里这句注释掉并重新编译：

CHECK_FUNCTION_EXISTS (pthread_getaffinity_np HAVE_PTHREAD_GETAFFINITY_NP)

更新 MySQL 后，我们再来看一下现在的绑定情况：

mysql> CREATE RESOURCE GROUP rg
    -> TYPE = USER
    -> VCPU = 10;
Query OK, 0 rows affected (0.00 sec)

mysql> SET RESOURCE GROUP rg;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
mysql> ALTER RESOURCE GROUP rg
    -> VCPU = 3,4,7,8;
Query OK, 0 rows affected (0.01 sec)

mysql> SET RESOURCE GROUP rg;
Query OK, 0 rows affected (0.00 sec)

mysql>

可以看到，VCPU 我们现在可以在宿主范围内指定了，但实际使用的时候超出范围（比如这里 CPU10）还是会被拒绝并出错的，所以要确保分配的  CPU ID 是与宿主分配的一致。当我们指定的 CPU 与系统分配的一致时（如这里的 3、4、7、8），这次我们顺利的绑定 RG。

使用场景

  1. 实现熔断机制，比如为 SYS 资源组分配更高的优先级或绑定特定的 CPU，降低用户线程压力太大可能造成的 CRASH 风险；

  2. 对于可以预见的线程或会话，分配更高或更低的优先级。比如对于监控 session，可以分配较高优先级，当系统本身负载较高时，可以尽量确保监控、健康检查等行为有效。对于不紧急的批处理操作，可以绑定特定 CPU 并降低优先级，最大程度降低对业务响应的影响；

  3. 根据我们的测试，在特定场景下，为系统线程绑定专用资源，可能可以带来意想不到的性能正反馈：MySQL8.0中为 log_writer 和 log_flush 两个操作线程设置较高的 CPU 优先级后（确保资源不被大量用户线程挤兑），在部分场景对 QPS 会有明显提升。 

参考文档

  1. 8.12.5 Resource Groups
    https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html

  2. Resource Groups Restrictions
    https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html#resource-group-restrictions

  3. sched_setaffinity
    https://linux.die.net/man/2/sched_setaffinity

  4. taskset.c
    https://github.com/karelzak/util-linux/blob/master/schedutils/taskset.c

nieops
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
操作系统之进程管理：20、死锁的检测和解除
千寻瀑
10-07 376
20、死锁的检测和解除思维导图死锁检测死锁解除 思维导图 死锁检测 P1、P2:进程；R1、R2：某一类资源集合 绿边：已经被使用掉的资源个数；蓝边：进程请求的资源个数 由上图可知： P1使用了2个R1资源，P2使用了1个R1资源；R1剩余0个资源； 此时，P2请求一个R1资源，由于R1资源不足，P2阻塞； P2使用了一个R1资源、1个R2资源；R2资源剩余1个；R1请求1个R2资源；资源足够；P1运行； P1运行后，释放2个R1资源、1个R2资源；P2运行 安全序列：P1–P2 死锁解除
MySQL Resource Groups
老叶茶馆
06-12 869
作者：蒋乐兴 MySQL-DBA 目前在 github 上维护着两套 MySQL 开源工具 mysqltools & dbm(dbm-agent dbm-center)，对机...
mysql8 groups关键字
wejack的专栏
07-16 1548
mysql8里 groups是关键字了，表名是groups的，在Mysql8里查询会报错
MySQL 8 中新增的资源管理特性---发表到3306pai社区
姚远OracleACE的博客
05-21 351
资源管理 MySQL 8 开始支持使用资源组控制系统CPU资源的分配，将服务器内运行的线程分配给特定组，以便线程根据组可用的资源执行。组属性可以控制其资源，包括VCPU的个数和线程的优先级。DBA可以根据不同的工作负载修改这些属性。 默认情况下，有一个系统组和一个用户组，分别名为SYS_default和 USR_default。无法删除这些默认组，并且无法修改其属性。每个默认组都没有CPU关联，优先级为0。 资源组属性 每个组都有一个名字。资源组名称是表和列名称之类的标识符。组名称不区分大小写，最长可达64
mysql resource_MySQL8.0——Resource Group（资源组）
weixin_39988331的博客
01-20 293
资源组介绍简介MySQL是单进程多线程的程序，MySQL线程包括后台线程(Master Thread、IO Thread、Purge Thread等)，以及用户线程。在8.0之前，所有线程的优先级都是一样的，并且所有的线程的资源都是共享的。但是在MySQL8.0之后，由于Resource Group特性的引入，我们可以来通过资源组的方式修改线程的优先级以及所能使用的资源，可以指定不同的线程使用特定...
技术分享 | 可能是目前最全的 MySQL 8.0 新特性解读(上)
杨建荣的学习笔记
03-20 792
作者：马文斌MySQL爱好者,任职于蓝月亮(中国)有限公司。本文来源：原创投稿*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。一、功能增强1.1-所有系统表更换为InnoDB引擎系统表全部换成事务型的innodb表，默认的MySQL实例将不包含任何MyISAM表，除非手动创建MyISAM表。1.2-DDL原子化InnoDB表的DDL支持事务完整性，要么成功要么回滚，将...
MySQL 8.0 参考手册教程pdf
最新发布
09-19
MySQL 8.0 是当前广泛使用的开源关系型数据库管理系统，其参考手册教程为用户提供了一步一步的学习路径，帮助用户从零开始掌握MySQL的基本操作。在本教程中，我们将深入探讨几个关键知识点，包括如何使用mysql客户端...
Mysql 8.0资源安装包下载
10-16
在这个"Mysql 8.0资源安装包下载"中，我们主要关注的是MySQL的Java连接器，即`mysql-connector-java-8.0.20`。 MySQL Connector/J是MySQL官方提供的用于Java应用程序连接MySQL数据库的驱动程序。版本8.0.20代表这是...
MySQL8.0认证 ocp(175题)
08-30
MySQL 8.0 OCP（Oracle Certified Professional）认证是针对MySQL数据库管理员的一项专业认证，旨在验证个人在MySQL 8.0版本中管理、优化和维护数据库的能力。这个认证包括了广泛的理论知识和技术实践，涵盖了从基础...
MySQL 8.0 Reference Manual MySQL 8.0 Reference Manual
04-09
MySQL 8.0 参考手册是 MySQL 8.0 的官方文档，涵盖 MySQL 8.0 到 8.0.30 和 NDB Cluster 8.0 的所有版本。该手册详细记录了 MySQL 8.0 的所有特性、配置选项、语法、函数和优化技巧。 MySQL 8.0 的主要特性 ...
mysql8.0 附带一键安装脚本
12-15
MySQL 8.0 是 MySQL 数据库管理系统的最新版本，提供了许多增强的功能和性能优化，旨在为开发者和企业级用户提供更高效、安全的数据存储和管理体验。这个“mysql8.0 附带一键安装脚本”可能包含了一个简化 MySQL 8.0...
MySQL8.0——Resource Group（资源组）
Win_Man的专栏
07-11 1082
MySQL8.0——Resource Group（资源组） 资源组介绍 简介 MySQL是单进程多线程的程序，MySQL线程包括后台线程（Master Thread、IO Thread、Purge Thread等），以及用户线程。在8.0之前，所有线程的优先级都是一样的，并且所有的线程的资源都是共享的。但是在MySQL8.0之后，由于Resource Group特性的引入，我们可以来...
MySQL8.0: 通过Resource Group来控制线程计算资源
weixin_33849942的博客
05-18 266
ＭySQL8.0增加了一个新功能resource group,　可以对不同的用户进行资源控制，例如对用户线程和后台系统线程给予不同的CPU优先级。 用户可以通过SQL接口创建不同的分组，这些分组可以作为sql的hit，也可以动态的绑定过去。本文主要简单介绍下用法，至于底层如何实现的，其实比较简单：创建的分组被存储到系统表中；在linux系统底层通过CPU...
GitLab CI/CD .gitlab-ci.yml 关键词（十三）：资源组 resource_group，部署环境 environment
知无涯
09-13 3668
本篇文章向大家介绍二个关键词，与， 前者可以实现多条流水线只能有一个作业正在运行，后者可以用来管理部署环境，包括，创建，过期，清空。
26.3 MySQL 8.x中的资源组
weixin_41275260的博客
06-01 73
26.3　MySQL 8.x中的资源组 资源组是MySQL 8.x版本中引入的一个新特性，通过资源组能够修改线程的执行优先级，并指定不同的线程使用不同的资源，以减少线程执行复杂任务时对其他线程的影响。 26.3.1　开启CAP_SYS_NICE 在Linux操作系统上，MySQL需要开启CAP_SYS_NICE特性才能使用资源组。首先查看MySQL的运行进程信息。 ...
MySQL · 特性分析 · MySQL 8.0 资源组 (Resource Groups)
weixin_40581617的博客
05-23 541
MySQL 8.0已经正式发布。这个版本包含很多有意思的特性，例如，更快、性能更好的Schema和Information Schema、原子DDL、UNDO空间回收等，在很多的网站，博客等上面都有大量的推广介绍。本文将要介绍的一个很有用的特性，资源组，反而没有得到充分的宣传。如果没有特别的说明，本文的例子针对的是Linux系统。什么是资源组大家知道，MySQL实例里面包含系统的后台线程，例如Mas...
mysql group set,mysql8 参考手册--SET RESOURCE GROUP语句
weixin_39618597的博客
03-17 226
SET RESOURCE GROUP group_name[FOR thread_id [, thread_id] ...]SET RESOURCE GROUP用于资源组管理(请参见 第8.12.5节“资源组”)。该语句将线程分配给资源组。它需要 RESOURCE_GROUP_ADMIN或 RESOURCE_GROUP_USER特权。group_name标识要分配的资源组。任何thread_id ...
MySQL8.0新特性--Group by
weixin_33694172的博客
11-30 2722
Group by 语句用于结合聚合函数（如count，sum，avg，max，min），根据一个或多个列对结果集进行分组。（1）去掉重复值：根据group by后面的关键字只显示一行结果；（2）mysql5.7默认开启参数ONLY_FULL_GROUP_BY，表示完全group by，即select后面跟的列group by后面也必须有，但是group by后面跟的列，se...
MySQL 8.0新特性概览：全面解读官方文档
MySQL 8.0 是一个重要的数据库版本更新，包含了众多新特性和性能提升，旨在提供更好的开发人员和运维人员体验。以下是本文档的主要知识点概述： 1. **新特性概览**： - MySQL 8.0 引入了全面的更新，覆盖了数据库...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值