MySQL 8.0内存敏感，仅用Docker的--memory和--cpus无法约束其进程行为；必须配合显式配置innodb_buffer_pool_size（建议设为容器内存50%–70%）、禁用swap（--memory-swap=2g），并合理设置innodb_thread_concurrency，才能实现Docker层硬限与MySQL层软控协同生效。
为什么直接用 --memory 和 --cpus 不够？
MySQL 8.0 是内存敏感型服务，仅靠 Docker 的 --memory=2g 或 --cpus=1.5 只能限制容器整体资源上限，但无法约束 MySQL 进程自身行为。比如：InnoDB 缓冲池会主动申请大量内存，若未在配置中显式设限，它可能在容器内存快耗尽时才被 OOM Killer 杀掉，导致连接中断或数据写入异常。
真正起效的组合是：Docker 层硬限 + MySQL 配置层软控。
innodb_buffer_pool_size 必须显式设置
这是 MySQL 内存使用的大头，默认会尝试占满可用内存的 75%～80%，在 2G 容器里极易触发 OOM。不配它，--memory 就只是个“事后补救开关”。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 值应为容器内存上限的 50%～70%，例如
--memory=2g→innodb_buffer_pool_size=1G - 必须写进挂载的配置文件（如
/data/mysql/conf/my.cnf），不能只靠环境变量 - 若用
docker run -v /conf:/etc/mysql/conf.d挂载，确保该配置在[mysqld]段下，且文件权限为644、属主为 UID 999
CPU 限制要分两层看：--cpus vs innodb_thread_concurrency
--cpus=1.2 控制的是 Linux 调度器分配给整个容器的时间片；而 innodb_thread_concurrency 控制的是 InnoDB 内部并发线程数。后者影响查询排队和锁等待行为，尤其在高并发写入场景下更关键。
-
--cpus建议设为整数或半核（如1.0、2.0），避免小数引发调度抖动 -
innodb_thread_concurrency默认为 0（不限制），生产环境建议设为0或32（不超过 CPU 核心数 × 2） - 注意：MySQL 8.0 中该参数已弱化，更推荐靠
--cpus+ 监控Threads_running状态来调优
容易忽略的 swap 和 memory-swap 组合
Docker 默认允许容器使用 swap，但 MySQL 对延迟敏感，swap 会导致查询毛刺甚至超时。必须禁用：
- 加
--memory-swap=2g（与--memory相同）→ 禁用 swap - 若漏设
--memory-swap，Docker 会默认设为-1（无限 swap），此时--memory=2g实际无效 - 完整启动命令示例：
docker run -d \ --name mysql8 \ --memory=2g \ --memory-swap=2g \ --cpus=2 \ -e MYSQL_ROOT_PASSWORD=... \ -v /data/mysql/conf:/etc/mysql/conf.d \ -v /data/mysql/data:/var/lib/mysql \ mysql:8.0
真正难调的不是参数本身，而是 buffer pool 大小与容器内存限制之间的差值——这个空隙要留给 OS 缓存、连接线程栈、临时表等开销。留少了易 OOM，留多了浪费资源。建议上线前用 docker stats 观察 1 小时内 RSS 峰值，再反推调整。
