MySQL容器无硬内存上限，必须用cgroup v2（如systemd MemoryMax或Docker --memory）设硬限；innodb_buffer_pool_size仅为软限，实际RSS还叠加per-connection缓冲、page cache等，需预留余量并严格配对tmp_table_size与max_heap_table_size。
MySQL容器本身不支持硬性内存/CPU上限，必须靠外部机制限制——直接配my.cnf里的参数只能软控，压不住RSS暴涨和OOM Killer。
为什么innodb_buffer_pool_size不能当内存上限用
它只是InnoDB缓存的“建议值”，实际进程RSS还会叠加连接线程、临时表、page cache、binlog buffer等。比如设了innodb_buffer_pool_size = 2G，但100个连接 × sort_buffer_size = 2M 就额外吃掉200MB，再加OS page cache，RSS轻松突破3G。常见现象是Killed process <pid> (mysqld)</pid>出现在/var/log/messages里，根本没报MySQL错误。
-
tmp_table_size和max_heap_table_size必须严格相等，否则内存临时表会无声退化成磁盘表，反而增加CPU和IO负担 -
sort_buffer_size、read_buffer_size这类per-connection参数，宁可保持默认（256K/128K），别盲目调大 - 容器里跑MySQL，
innodb_buffer_pool_size建议设为容器内存限制的60%~70%，留出余量给OS和线程开销
Docker命令行限制内存和CPU的实操要点
用docker run启动时加参数是最直接的方式，但要注意单位和底层行为差异：
- 内存：用
--memory=4g（不是--memory=4G，Docker只认小写单位），同时加--memory-swap=4g禁用swap，避免OOM前先卡死 - CPU：用
--cpus=2.5比--cpu-shares=1024更可靠——后者只是权重，在空闲时不限制，生产环境容易失守 - 别混用
--cpuset-cpus和--cpus，前者绑定物理核，后者是逻辑配额，冲突会导致启动失败 - 验证是否生效：
docker stats <container_id>看MEM USAGE / LIMIT，docker exec -it <name> top -b -n1 | head -5看CPU%是否被压住
1Panel或systemd里配MemoryMax才是裸机稳妥方案
手动改cgroup目录易出错，且进程重启后失效。systemd的MemoryMax自动绑定进程生命周期，1Panel底层也是调Docker API走这套逻辑：
- 裸机MySQL服务：在
/etc/systemd/system/mysqld.service.d/override.conf里写MemoryMax=4G，MemorySwapMax=0，然后systemctl daemon-reload && systemctl restart mysqld - 1Panel界面操作：进容器设置页 → 资源限制 → 填“内存限制”数值 + 选单位（MB/GB），它会转成
MemoryLimit字段发给Docker daemon - 关键区别：
MemoryMax（v2 cgroup）是硬限，MemoryLimit（旧名）在v2下已失效，但1Panel仍兼容该字段名 - 确认cgroup v2启用：
mount | grep cgroup输出里必须有type cgroup2，内核
宝塔面板装MySQL时绕过最低资源检查
宝塔强制要求MySQL 8.0至少3.7GB内存+2核CPU，低配机器想跑只能改校验逻辑：
- 编辑
/www/server/panel/class/panelPlugin.py，注释掉137行（CPU检查）和138行（内存检查）的if not self.check_...整行 - 或者改
/www/server/panel/data/plugin.json，把对应MySQL版本的mem_limit和cpu_limit值调低，比如8.0版改成"mem_limit": 1024 - 改完必须重启面板：
bt restart，否则新配置不加载 - 注意：绕过检查后，务必手动调低
innodb_buffer_pool_size（例如设为512M），否则启动就OOM
真正难的不是设参数，而是厘清哪一层在起作用：容器runtime（Docker）、init系统（systemd）、还是MySQL自身配置。三者叠加时，优先级是cgroup > systemd > my.cnf。一旦发现内存没被压住，第一反应不该是调my.cnf，而是查cat /sys/fs/cgroup/memory/mysql/memory.max或systemctl show mysqld | grep MemoryMax——很多问题其实卡在这一层没生效。
