退出码是第一线索:ExitCode 1表示MySQL主动退出(配置错误、空挂载、权限问题等),137且OOMKilled为true表明内存不足被杀,0或空则说明mysqld未执行;应优先用docker inspect查状态,再以--console前台启动捕获实时错误,验证/var/lib/mysql是否真有数据。

容器启动后立刻退出,docker logs 为空或只有半行初始化日志——这不是日志没生成,而是 MySQL 进程在写满缓冲区前就崩了,根本来不及刷盘。
先看退出码和OOM状态,别急着翻日志
退出码是第一线索,直接决定排查方向:
-
ExitCode为1:MySQL 主动退出,常见于配置错误、密码太弱(validate_password拒绝)、挂载目录为空或权限不对(如宿主机目录属主是root,但容器内mysql用户 UID=999 无权写) -
ExitCode为137且"OOMKilled": true:内存不足被内核杀掉,尤其常见于容器只配了--memory=512m却跑 MySQL 8.0(默认 buffer pool 就要 1G) -
ExitCode为0或空:说明 mysqld 根本没执行起来,大概率是command覆盖出错或 entrypoint 脚本提前 return
查法:docker inspect some-mysql | grep -A 5 'Status\|OOMKilled'
绕过 docker logs,用 --console 强制前台输出错误
MySQL 8.0 容器默认把错误日志塞进后台,docker logs 很难捕获秒退时的 stderr。最有效的调试方式是跳过 init 脚本,手动以前台模式启动:
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理(CRM)系统设计、评审、优化或生成数据库模式时,应使用此项技能。
- 临时测试:
docker run -it --rm -e MYSQL_ROOT_PASSWORD=test mysql:8.0 --console --log-error-verbosity=3 - 用 docker-compose 时,在
command里显式写死:command: ["mysqld", "--console", "--log-error-verbosity=3"] - 这样所有错误会直出到终端,比如
unknown variable 'skip-host-cache'或Password validation failed都能一眼看到
检查挂载点是否真有数据,空目录是静默退出头号原因
你写了 -v ./mysql-data:/var/lib/mysql,但 ./mysql-data 是个空文件夹?MySQL 8.0 启动时发现 /var/lib/mysql 下没有 ibdata1、mysql/、sys/ 等基础文件,就会拒绝初始化并静默退出,退出码 1,日志里一个字都不留。
- 验证方法:
docker exec -it some-mysql ls -A /var/lib/mysql—— 如果返回空,就是它了 - 修复方法:删掉空目录,让容器首次启动自动初始化;或用
mysqld --initialize-insecure手动初始化后再挂载 - 注意命名卷陷阱:
docker run -v /var/lib/mysql mysql:8.0默认创建匿名卷,每次都是新卷,旧数据永远找不回来
确认 log_error 是否真正生效且可写
即使你配了 log_error = /var/log/mysql/error.log,如果路径不存在、父目录没建、或者 MySQL 用户没权限,日志照样不会落盘,还会导致启动失败。
- 必须手动创建并授权:
mkdir -p /host/path/mysql-logs && chown 999:999 /host/path/mysql-logs(UID 999 是官方镜像 mysql 用户) - 进容器验证:
docker exec -it some-mysql mysql --verbose --help | grep "log_error",看实际读到的路径是不是你设的那个 - 再查组件是否启用:
SELECT @@GLOBAL.log_error_services;必须包含log_sink_internal,否则日志只打到系统 journal,不写文件
真正卡住人的,往往不是某一个配置项写错了,而是多个低级问题叠在一起:挂载目录为空 + log_error 路径不可写 + validate_password 插件开着 + 容器内存限制太小。单点排查容易漏,得按退出码→前台输出→挂载内容→日志路径这个链条往下压,缺一不可。

















