mysql 8.0+ 的 resource group 仅能限制 cpu（vcpu 绑定与调度优先级），不能限制内存、查询超时、磁盘 i/o 或锁等待；内存需靠会话变量（如 sort_buffer_size）和应用层控制，超时需用 max_execution_time（仅 select）或 pt-kill 等外部工具。
MySQL 8.0+ 中用 RESOURCE GROUP 限制内存与CPU，但不控制查询超时
MySQL 原生不支持直接为某个用户账号设置「最大内存使用量」或「单条查询超时时间」。RESOURCE GROUP 可以绑定线程、限制 CPU 时间片和并发线程数，但它对内存（如 sort_buffer、join_buffer）无约束力，也不能中断超时查询。
常见误解是以为 SET GLOBAL max_heap_table_size 或 tmp_table_size 能按用户生效——其实它们是全局/会话级变量，无法按账号隔离。
-
RESOURCE GROUP需要先创建（如CREATE RESOURCE GROUP app_reader TYPE=USER VCPU=0-1;），再配合SET RESOURCE GROUP在会话中启用 - 仅适用于 MySQL 8.0.2+ 且需
RESOURCE_GROUP_ADMIN权限 - 它不干预内存分配行为，
sort_buffer_size这类参数仍由会话自行申请，可能突破物理内存限制
真正能限制单条查询资源的是 max_execution_time（仅限 SELECT）
MySQL 5.7.8+ 支持会话级或语句级的执行时间限制，但只对 SELECT 生效，对 INSERT/UPDATE/DELETE 和存储过程无效。
实操建议：
- 给业务账号创建专用会话初始化脚本：连接后立即执行
SET SESSION max_execution_time = 3000;（单位毫秒） - 在 SQL 语句前加 hint：
SELECT /*+ MAX_EXECUTION_TIME(5000) */ * FROM orders WHERE ...; - 注意：该参数不会终止已运行的查询，只在优化器估算阶段介入；若查询已进入执行阶段，超时不会触发中断
- 云数据库（如阿里云 RDS）通常禁用此功能，需确认
have_query_cache和optimizer_switch中max_execution_time是否启用
限制内存消耗必须靠应用层 + 服务端协同控制
MySQL 没有 per-user 内存配额机制。所谓“限制内存”，本质是防止大结果集、大排序、大临时表耗尽服务器内存。可行路径只有两条：
- 强制应用使用分页（
LIMIT offset, size）并校验size上限，禁止无 LIMIT 的全表 SELECT - 在 MySQL 配置中收紧会话级缓冲区：在
my.cnf中设sort_buffer_size = 256K、read_buffer_size = 128K、tmp_table_size = 32M、max_heap_table_size = 32M—— 这些值对所有会话生效，但可大幅降低单个慢查询的破坏力 - 用
pt-kill（Percona Toolkit）监控并干掉长时间运行或结果集过大的查询，例如：pt-kill --busy-time 60 --victim all --kill --match-command Query --match-state executing
为什么不能依赖 wait_timeout 或 interactive_timeout？
这两个参数控制的是空闲连接的断开时间，不是查询执行超时。一个 SELECT SLEEP(300) 即使设置了 wait_timeout=60 也会完整执行完 300 秒才结束，期间持续占用连接和内存。
真正需要防的是两类场景：
- 应用未正确关闭连接，导致大量 idle 线程堆积 → 用
wait_timeout合理设为 300–600 秒有效 - 某条查询卡死或扫描全表 → 必须靠
max_execution_time（SELECT）或外部工具（pt-kill/ 自研 watchdog）干预
最易被忽略的一点：任何基于会话变量的限制（如 max_execution_time）都依赖客户端连接时主动执行 SET，如果应用连接池复用连接且未重置会话状态，旧值可能残留，导致限制失效。
