MySQL 8.0容器秒退主因是初始化失败或权限问题，必须显式设置MYSQL_ROOT_PASSWORD等密码变量，且挂载目录需属主999:999并具备读写执行权限，否则初始化脚本退出。
MySQL 8.0容器启动后秒退，90%以上是初始化失败或权限卡住，不是镜像坏了，也不用重装Docker。
docker logs 显示 “Database is uninitialized and password option is not specified”
这是最常见、最容易忽略的硬性要求：MySQL 8.0官方镜像在首次启动时必须显式提供 root 密码，否则初始化脚本直接退出，容器随之终止。
-
MYSQL_ROOT_PASSWORD是强制项；MYSQL_ALLOW_EMPTY_PASSWORD=1或MYSQL_RANDOM_ROOT_PASSWORD=1可替代，但不能全不设 - 检查命令中是否漏掉
-e，比如写成docker run -e MYSQL_ROOT_PASSWORD=123 mysql:8.0而不是docker run -eMYSQL_ROOT_PASSWORD=123（中间少空格，环境变量不生效） - 如果用
docker-compose.yml，确认environment:下缩进正确，且值没被 YAML 注释符#意外截断
挂载了 /var/lib/mysql 但容器仍退出
宿主机目录权限不对，MySQL 容器内以用户 mysql（uid=999, gid=999）运行，它必须对挂载目录有完整读写执行权限。
- 执行
ls -ld /path/to/mysql/data，确认输出中包含drwxr-xr-x 999 999或至少属主属组是999 - 修复命令：
sudo chown -R 999:999 /path/to/mysql/data（注意是-R，递归改权） - 若宿主机是 SELinux 启用状态（如 CentOS/RHEL），还需加
:z标签：-v /path/to/data:/var/lib/mysql:z - 切勿挂载空目录到
/etc/mysql/my.cnf—— 如果宿主机路径是目录而非文件，会触发not a directory错误并退出
日志里出现 mysqld: can't create /write to file '/var/lib/mysql/is_writable'
这说明 MySQL 进程连最基础的写测试都失败了，问题已脱离配置层，直指文件系统。
- 检查挂载路径是否存在：
ls /path/to/mysql/data，不存在就先mkdir -p - 确认挂载路径不是 NFS/CIFS 等不支持 Unix 权限的远程文件系统（MySQL 8.0 不支持）
- 如果用的是 Docker Desktop for Mac/Windows，检查是否启用了“Use the WSL 2 based engine”，旧版 Hyper-V 后端对文件锁支持差，易导致初始化中断
- 极少数情况是磁盘满或 inodes 耗尽：
df -h和df -i都要看
容器启动后短暂运行又退出，日志含 database page corruption 或 plugin table cannot be opened
说明挂载的数据目录里已有旧数据，但和当前 MySQL 8.0 版本不兼容，InnoDB 拒绝加载。
- 不要强行复用 MySQL 5.7 或早期 8.0 的数据目录 —— 数据字典格式、加密机制都变了
- 安全做法：备份原目录（
mv /path/to/data /path/to/data.bak），再用空目录重试 - 若确定要迁移，必须通过
mysqldump导出再导入，不可直接拷贝ibdata1或ib_logfile* - 使用
docker volume替代绑定挂载，可避免路径权限混乱，也更符合容器设计原则
真正卡住人的地方往往不在报错文字本身，而在日志里那行被快速刷过的 [ERROR] 前几秒——所以别跳过 docker logs --tail 100 -f <container>，盯住第一屏输出。一旦看到初始化开始（initializing database files），基本就过了最危险的阶段。
