phpEnv 启动的 MySQL 8.0 默认不生效 RESOURCE GROUP，因其底层未启用 resource_group=ON 启动参数，且官方 Windows 社区版二进制默认编译禁用该功能，CREATE RESOURCE GROUP 会直接报错。
phpEnv 本身不支持配置 MySQL 8.0 的 RESOURCE GROUP（资源组）——它只是个 Windows 下的 PHP + MySQL 一键环境包，底层 MySQL 启动后默认禁用资源组功能，且 phpEnv 界面和配置文件里没有任何 Resource Group 相关开关。
为什么 phpEnv 启动的 MySQL 8.0 默认不生效 RESOURCE GROUP
MySQL 8.0 的资源组功能依赖两个硬性前提：
- 启动时必须加
--resource-group参数（或在my.ini中设置resource_group=ON），否则CREATE RESOURCE GROUP会直接报错ERROR 1235 (42000): This version of MySQL doesn't yet support 'CREATE RESOURCE GROUP' - Windows 下 MySQL 官方二进制包默认编译时未启用资源组（尤其非企业版），phpEnv 打包的 MySQL 通常沿用此限制
- 即使手动开启，资源组只对显式执行
SET RESOURCE GROUP = ...的会话生效；phpEnv 自带的 phpMyAdmin 或命令行连接都不会自动绑定
手动启用 RESOURCE GROUP 的实操步骤（仅限技术验证，生产慎用）
如果你确认 phpEnv 内嵌的 MySQL 是 8.0.19+ 且为社区版（可查 SELECT VERSION() 和 SELECT * FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'RESOURCE_GROUP'），按以下顺序操作：
- 关闭 phpEnv 中的 MySQL 服务（不是“停止”，是彻底退出进程）
- 编辑 phpEnv 安装目录下的
mysql\my.ini，在[mysqld]段末尾添加：resource_group=ON
- 重启 MySQL 服务（通过 phpEnv 控制面板或命令行
net start mysql） - 登录 MySQL 执行：
CREATE RESOURCE GROUP bg_low TYPE = USER VCPU = 0 THREAD_PRIORITY = 10;
若报错，说明当前 MySQL 二进制不支持——此时只能换官方 MySQL 8.0.23+ ZIP 包手动部署 - 给某用户会话绑定：
SET RESOURCE GROUP bg_low;
注意：这句必须由应用自己在连接后立即执行，phpEnv 的 Web 界面无法代劳
替代方案：用 MAX_*_PER_HOUR 在 phpEnv 里做实际可用的限流
对绝大多数 phpEnv 用户（本地开发、小站点、测试环境），真正能立刻起效的控制手段只有频次类限制，因为它们不依赖 MySQL 启动参数，且兼容所有 8.0+ 版本：
立即学习“PHP免费学习笔记（深入）”；
- 新建用户时直接限制：
CREATE USER 'dev_user'@'localhost' IDENTIFIED BY 'pwd' WITH MAX_QUERIES_PER_HOUR 60 MAX_UPDATES_PER_HOUR 20;
- 已有用户补限：
ALTER USER 'api_user'@'localhost' WITH MAX_CONNECTIONS_PER_HOUR 5;
- 这些值写入
mysql.user表的max_questions/max_updates字段，重启 MySQL 不丢失 - PHP 应用连接后若触发超限，会收到明确错误：
ERROR 1226 (42000): User 'dev_user'@'localhost' has exceeded the 'max_questions' resource
资源组本质是 Linux 级 CPU 亲和性调度，在 Windows 上效果本就打折；而 phpEnv 的定位是快速搭建，不是生产级资源隔离。真要压住某个查询的 CPU 占用，与其折腾不可靠的资源组，不如从 SQL 本身优化（比如加 LIMIT、避免 SELECT *、建好索引）或用 max_execution_time 配合 KILL QUERY 主动熔断——后者在 phpEnv 环境里反而更可控。
