MySQL 8.0进程需显式绑定cgroups v1/v2才生效，因其自身不感知cgroups；必须通过mkdir/cgroup.procs或systemd.slice将mysqld PID加入控制组，并配置cpu.max和memory.max等参数实现CPU与内存硬限制。
MySQL 8.0 进程必须绑定到 cgroups v1 或 v2 才生效
MySQL 自身不感知 cgroups，它只是个普通 Linux 进程。想限制它的 CPU 和内存，必须在 mysqld 启动后、或启动前，将其 PID 显式加入某个 cgroup 控制组。cgroups v1（/sys/fs/cgroup/ 下各子系统）和 v2（统一挂载点 /sys/fs/cgroup/）都支持，但配置方式不同；私有云环境建议优先用 v2，因 systemd 默认启用且更健壮。
关键前提是：宿主机内核需启用对应子系统（cpu、memory），且未被 Docker 等容器运行时独占。检查命令：ls /sys/fs/cgroup/cpu 和 ls /sys/fs/cgroup/memory —— 若目录为空或报错“Permission denied”，说明子系统未挂载或权限不足。
- v1 需分别挂载
cpu和memory子系统（如mount -t cgroup -o cpu none /sys/fs/cgroup/cpu） - v2 默认单挂载点，启用只需确认
unified挂载存在：mount | grep cgroup2 - 若使用 systemd 启动 mysqld（如
systemctl start mysqld），应改用.slice单元管理，避免手动操作 cgroup 路径易出错
用 cgroups v2 限制 MySQL 的 CPU 使用率（硬配额）
cgroups v2 的 CPU 限制靠 cpu.max 实现，格式为 "max us period us"，例如 "300000 1000000" 表示每 1 秒最多用 0.3 秒 CPU 时间（即 30%）。这比 v1 的 cpu.cfs_quota_us 更简洁，且无隐式周期继承问题。
操作步骤（以限制为 4 核等效算力为例）：
- 创建控制组：
mkdir -p /sys/fs/cgroup/mysql-prod - 设 CPU 配额：
echo "4000000 1000000" > /sys/fs/cgroup/mysql-prod/cpu.max（400% = 4 核） - 将 mysqld 主进程加入：
echo $(pgrep -f "mysqld --user=mysql") > /sys/fs/cgroup/mysql-prod/cgroup.procs - 验证：
cat /sys/fs/cgroup/mysql-prod/cpu.stat查看usage_usec是否稳定在设定范围内
注意：cpu.max 是硬限制，超限后线程会被节流（throttled），不会被 kill；但若设置过低（如 "50000 1000000"），可能导致连接响应延迟突增，尤其在高并发短查询场景。
用 cgroups v2 限制 MySQL 内存上限并防 OOM
MySQL 的内存使用分两块：mysqld 进程自身堆内存（如 innodb_buffer_pool_size）、以及内核页缓存（page cache）——后者不受 memory.max 约束。因此，memory.max 只能管住前者 + 线程栈 + 其他 malloc 分配，不能替代 MySQL 内部参数调优。
- 设内存上限（如 4GB）：
echo 4294967296 > /sys/fs/cgroup/mysql-prod/memory.max - 禁用 swap 影响（推荐）：
echo 0 > /sys/fs/cgroup/mysql-prod/memory.swap.max - 开启 OOM 控制：
echo "1" > /sys/fs/cgroup/mysql-prod/memory.oom.group（使整个 cgroup 视为一个 OOM 单元） - 观察是否触发：
dmesg -T | grep -i "Out of memory"或查memory.events中oom_kill计数
常见坑：memory.max 设得太小（如低于 innodb_buffer_pool_size + key_buffer_size + max_connections * thread_stack 总和），mysqld 启动就会失败或频繁 OOM；必须预留至少 512MB 给系统缓冲和临时表。
systemd slice 方式更适配私有云长期运维
手动写 cgroup.procs 在 mysqld 重启后失效，而私有云要求服务自愈。用 systemd 创建持久化 .slice 是更可靠的选择，它会在每次 mysqld 启动时自动应用资源策略，且与 journal 日志、依赖管理集成。
示例（/etc/systemd/system/mysql-prod.slice）：
[Unit] Description=MySQL Production Slice Before=slices.target <p>[Slice] CPUQuota=300% MemoryMax=4G</p>
然后修改 mysqld 服务单元（/etc/systemd/system/mysqld.service.d/override.conf）：
[Service] Slice=mysql-prod.slice
重载并启用：systemctl daemon-reload && systemctl restart mysqld。此后所有由该 service 启动的 mysqld 进程及其子进程（如备份脚本调用的 mysql 客户端）都会受控。
真正容易被忽略的是：slice 对子进程的资源继承是默认开启的，但若备份工具（如 xtrabackup）以 root 权限独立启动，它会脱离 mysqld 的 slice；此时需单独为其配置另一个 slice，或改用 systemd-run --scope 包裹执行。
