mysql 8.0+资源组仅绑定线程到cpu核心及调整优先级，完全不支持账号级限制；真正管控高风险账号须结合权限控制（如revoke drop）与资源限制（如max_user_connections、max_queries_per_hour），并辅以cgroup v2系统级内存硬限。
MySQL 8.0+ 资源组（Resource Groups）不支持限制账号行为
MySQL 的 RESOURCE GROUP 功能仅用于绑定线程（thread）到特定 CPU 核心或优先级，**完全不感知用户、账号、SQL 类型或权限层级**。它无法按 'user'@'host' 限制资源，也不能拦截或限流某用户的查询、更新或连接。试图用 CREATE RESOURCE GROUP rg1 TYPE=USER VCPU=0-1; 去“管控高风险账号”，属于典型的功能误用——该语句只影响后续显式 SET RESOURCE GROUP rg1 的线程，而应用代码几乎从不主动设这个。
真正能限制高风险账号的只有两类机制
MySQL 对账号级资源控制，只靠两套原生能力：权限（privileges）和资源限制（resource limits），二者必须配合使用：
-
GRANT/REVOKE控制“能做什么”：比如收回DROP、ALTER、SUPER、PROCESS等高危权限，让账号根本发不出危险语句 -
CREATE USER或ALTER USER ... WITH设置资源配额：重点是MAX_USER_CONNECTIONS（防连接泄露）、MAX_QUERIES_PER_HOUR（防扫描类慢查）、MAX_UPDATES_PER_HOUR（防误批量改） - 注意：
MAX_CONNECTIONS_PER_HOUR是每小时新建连接数，对长连接无效；MAX_USER_CONNECTIONS才是并发连接硬上限，生产环境必须设非零值
为什么不能依赖 sql_safe_updates 或审计插件替代权限控制
sql_safe_updates = 1 只拦无 WHERE 的 UPDATE/DELETE，但对 DROP TABLE、TRUNCATE、ALTER TABLE ... DROP COLUMN 完全无效；审计插件（如 audit_log）只能记录事后操作，不能阻止执行。真正的防线必须前置：
- 高风险账号（如运维临时账号）应单独建，
GRANT时显式排除FILE、SUPER、SHUTDOWN - 业务账号一律禁用
DROP权限：REVOKE DROP ON *.* FROM 'app_user'@'%'; - 用
SHOW GRANTS FOR 'app_user'@'%';验证结果，避免被角色继承或旧权限残留干扰
系统层兜底：cgroup v2 是防内存溢出的唯一硬手段
MySQL 没有 max_memory_per_user，所有会话缓冲区（sort_buffer_size、join_buffer_size）由连接独占且可动态 SET，InnoDB 缓冲池更是全局共享。单靠 MySQL 配置无法隔离内存风险：
- 必须在 Linux 层用
systemd为mysqld进程设MemoryMax，例如：sudo systemctl set-property mysqld.service MemoryMax=4G - 验证是否生效：
cat /sys/fs/cgroup/system.slice/mysqld.service/memory.max应返回具体字节数，而非max - 若用 Docker，需在
docker run中加--memory=4g --memory-swap=4g，且宿主机启用 cgroup v2
账号侧的 MAX_USER_CONNECTIONS 和系统侧的 MemoryMax 必须同时配置，缺一不可——前者防连接雪崩，后者防内存耗尽宕机。任何只做一半的方案，在真实高负载下都会失效。
