MySQL 8.0资源组仅作用于SELECT查询路径，DDL语句（如ALTER TABLE、CREATE INDEX）绕过其调度逻辑，故完全不受VCPU和THREAD_PRIORITY限制；真正有效的替代方案是cgroups、ionice+taskset或pt-osc等外部管控手段。
ALTER TABLE、DROP INDEX、CREATE INDEX 这类 DDL 语句在 MySQL 8.0 中完全不受资源组控制，无论你怎么配置 CREATE RESOURCE GROUP 或执行 SET RESOURCE GROUP FOR thread_id，都不会限制其 CPU 消耗。
为什么 DDL 不走资源组调度？
MySQL 8.0 的资源组机制只介入优化器选中的 SELECT 查询路径，而 DDL 属于元数据变更与存储引擎层操作（如 InnoDB 的 online DDL 流程），绕过了资源组的线程调度逻辑。官方文档未明说，但实测和源码行为一致：所有 ALTER、CREATE TABLE、DROP DATABASE 等语句均无视 VCPU 和 THREAD_PRIORITY 设置。
查到 DDL 线程后执行 SET RESOURCE GROUP 会生效吗？
不会。即使你从 performance_schema.threads 找到正在执行 ALTER TABLE 的 THREAD_ID，并成功执行：
SET RESOURCE GROUP low_prio FOR 12345;
该 DDL 仍会在所有可用 CPU 上自由调度，top 或 htop 中仍可能占满单核甚至多核。原因有三：
- DDL 不触发资源组绑定检查，线程调度不走
resource_group::bind_to_vcpu()路径 -
THREAD_PRIORITY对 DDL 线程无实际影响（除非 mysqld 有CAP_SYS_NICE且 DDL 内部显式调用setpriority()，但目前没有） - 资源组仅对“前台查询线程”（
TYPE = 'FOREGROUND'且PROCESSLIST_INFO为SELECT类）生效，DDL 多数时候归类为BACKGROUND或特殊状态
真正能压制 DDL CPU 的替代方案
既然资源组无效，就得换思路。以下方法经生产验证可行：
- 用 Linux
cgroups v1或cgroups v2限制整个mysqld进程的 CPU 配额，例如划出最多 2 个核给 DDL 批处理任务（需配合systemd或手动挂载） - 在应用层控制：把 DDL 放进低优先级队列，用
ionice -c 3+taskset -c 2-3启动单独的mysql客户端进程执行 - 改用
pt-online-schema-change并设置--max-load和--critical-load，它本身会主动让步 CPU，比原生命令更可控 - 升级到 MySQL 8.0.34+ 后可尝试
INFORMATION_SCHEMA.INNODB_METRICS监控 DDL 进度，结合外部脚本做超时KILL QUERY，但这不是限 CPU，而是防长阻塞
最容易被忽略的细节
很多人花几小时调试 VCPU = 0-1、THREAD_PRIORITY = 19，却没意识到：DDL 根本不读这些值。最省事的验证方式是跑一条 SELECT SLEEP(30) 和一条 ALTER TABLE t ENGINE=InnoDB，分别绑同一个资源组，再用 ps -o pid,psr,nice -p $(pgrep mysqld) 查线程实际运行核与 nice 值——前者会变，后者不变。
