容器资源限制需按实际负载而非宿主机比例配置：--cpus应设为高峰期Threads_running均值的1.2–1.5倍，-m需预留2G以上给OS及会话内存，innodb_buffer_pool_size宜设为容器内存限制的50%~70%并留足余量。
容器启动时怎么设--cpus和-m才不翻车
直接按宿主机总核数或内存总量的固定比例分配，大概率会让MySQL跑得又慢又不稳定。关键不是“分多少”，而是“够不够支撑当前负载下的并发线程+后台任务”。比如一个8核32G宿主机，给MySQL容器配--cpus=4、-m=16G看似合理，但如果业务峰值有300个活跃连接，每个连接执行复杂JOIN，CPU很快打满，而InnoDB刷脏页、Purge线程又抢不到时间片，就会卡住。
实操建议：
- 先用
mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_running';"观察高峰期并发线程数，再结合top -p $(pidof mysqld) -H看线程级CPU占用分布； -
--cpus建议设为高峰期平均Threads_running值的1.2–1.5倍（单线程基本不吃满一个核，但上下文切换开销大）； -
-m不能只看innodb_buffer_pool_size，还得预留至少2G给OS缓存、tmp_table、sort_buffer等会话级内存——例如innodb_buffer_pool_size=10G，容器内存至少配12G； - 避免用
--cpuset-cpus硬绑核心，除非你明确知道宿主机上没有其他IO密集型服务；否则反而限制了Linux CFS调度器的弹性。
innodb_buffer_pool_size在容器里为什么不能照搬物理机配置
因为容器的-m限制是cgroup memory.max，而innodb_buffer_pool_size是MySQL进程内部分配的虚拟内存。如果设得过大，超出cgroup限制，MySQL会在申请内存时被OOM Killer干掉；设得太小，Buffer Pool命中率暴跌，磁盘IO飙升——这两种情况在监控图上看起来都是“内存告警”，但根因完全相反。
实操建议：
- 启动容器前，用
docker run --rm -m 12G alpine:latest free -h验证cgroup是否生效； -
innodb_buffer_pool_size应设为容器内存限制的50%~70%，且必须小于memory.max（留出至少2G余量）； - MySQL 8.0+支持在线调整该参数，可先设保守值（如
6G），上线后根据Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads比值动态上调——目标是比值>99.5%； - 别忽略
innodb_buffer_pool_instances，它要和innodb_buffer_pool_size匹配：每实例建议1GB，否则锁竞争会抵消多实例收益。
为什么--cpus=2有时比--cpus=4响应更快
这不是玄学。当容器CPU限制过低（比如--cpus=2），Linux CFS会强制限频，MySQL线程被迫串行化执行，反而减少了锁争用和上下文切换；而--cpus=4放开后，大量短连接并发涌入，InnoDB内部的dict_sys->mutex、log_sys->mutex等热点锁开始排队，TPS不升反降，Threads_running长时间卡在高位。
典型信号：
-
SHOW ENGINE INNODB STATUS里SEMAPHORES段出现大量os_waits； -
perf top -p $(pidof mysqld)显示ut_delay或ib_mutex_enter占比超15%； - 慢查询日志里大量SQL耗时集中在“Opening tables”或“Waiting for table flush”。
这时与其加CPU，不如调低max_connections、关掉table_open_cache自动伸缩、或用连接池控制并发水位。
容器内存限制下最容易被忽略的三个内存黑洞
很多人盯着innodb_buffer_pool_size调优，却忘了MySQL还有三块内存不受它控制，但在容器里极易触发OOM：
-
tmp_table_size和max_heap_table_size：每个连接都可能独占一份，100个连接就可能吃掉2G+；建议设为64M并监控Created_tmp_disk_tables； -
sort_buffer_size：非全局参数，每个需要排序的查询都会分配，高并发下极易失控；生产环境建议固定为2M，靠索引优化排序而非堆内存； - Per-connection buffers（
read_buffer_size、join_buffer_size等）：默认值在容器里太激进，应统一压到256K级别，并用SHOW VARIABLES LIKE '%buffer%'确认实际加载值。
这些参数不会出现在SHOW GLOBAL STATUS的内存统计里，但它们真实地占着cgroup memory.max。最稳妥的做法，是在容器启动命令中加--oom-kill-disable=false，并用docker stats持续盯住MEM USAGE / LIMIT比值——一旦超过85%，立刻查/sys/fs/cgroup/memory/docker/<container-id>/memory.usage_in_bytes</container-id>定位具体哪块内存涨得最快。
