MySQL容器启动失败主因是权限与初始化时机不匹配：必须用--user 999:999显式指定用户，配合--init确保优雅关闭，且挂载目录需为空或含合法8.0数据。
直接上结论：用 docker run 一条命令就能完成，但挂载数据卷这一步如果只写 -v /host/path:/var/lib/mysql，大概率启动失败或后续写入报错——根本原因不是路径不对，而是权限和初始化时机没对上。
MySQL容器首次启动时，/var/lib/mysql目录必须为空或已含合法数据
这是最容易被忽略的启动前提。MySQL 8.0 镜像在启动时会检查 /var/lib/mysql 是否为干净目录：
- 若宿主机挂载路径为空，容器自动执行初始化（生成
mysql、sys等系统库） - 若宿主机路径里已有旧数据（比如从其他 MySQL 实例 cp 过来的），容器跳过初始化，直接加载；但要求该数据是合法的 MySQL 8.0 数据文件，且属主 UID/GID 匹配容器内运行用户（默认是 UID 999）
- 若宿主机路径存在但权限为
root:root，而容器以 UID 999 启动，就会因无法写入ibdata1等文件而卡死在启动阶段，日志里反复出现mysqld: Can't create/write to file
必须显式指定 --user 999:999，且不能靠 chown 临时修复
MySQL 8.0 官方镜像默认以 UID 999 用户运行 mysqld 进程，不是 root。如果你挂载的是宿主机目录（如 /mydata/mysql），必须提前确保该目录属主匹配：
- 错误做法：
sudo chown -R 999:999 /mydata/mysql后再启动——看似可行，但容器重启后可能因 Docker 卷挂载顺序问题导致权限重置 - 正确做法：启动时强制指定
--user 999:999，让容器内进程始终以该 UID 运行，并配合--init处理信号转发 - 别用
docker volume create创建命名卷再挂载——它默认属主是 root，仍需额外chown，不如直接用绑定挂载 + 显式--user
docker run 命令里 -v 和 --user 的顺序无关，但 --init 必须在参数靠前位置
--init 不是可有可无的装饰参数，它等效于注入 tini 作为 PID 1，解决僵尸进程回收和 SIGTERM 转发问题。如果漏掉，容器收到 docker stop 时 mysqld 可能无法优雅关闭，导致 ib_logfile0 损坏：
- 推荐写法：
docker run -d --name mysql8 --user 999:999 --init --restart=unless-stopped -v /mydata/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -p 3306:3306 mysql:8.0 - 禁止写法：
docker run ... mysql:8.0 --init——把--init放在镜像名后面，会被当成 mysqld 的启动参数，直接报错unknown option '--init' - 环境变量优先级：
MYSQL_DATABASE和MYSQL_USER只在初始化阶段生效；若挂载目录已有数据，这些变量会被完全忽略
Docker Compose 中挂载数据卷要小心 command 覆盖导致的降权失败
用 Compose 时，如果写了 command: mysqld --skip-grant-tables 这类自定义启动命令，又没同步加 --user 参数，mysqld 会以 root 启动，然后尝试降权到 999，但宿主机目录权限不匹配，最终失败：
- 安全写法：在
command最后显式追加--user=mysql（镜像内置 mysql 用户映射到 UID 999） - 更稳妥写法：不用
command覆盖，改用entrypoint或挂载/etc/mysql/conf.d/下的配置文件来调整行为 - 验证是否成功：容器启动后执行
docker exec mysql8 ls -ld /var/lib/mysql，输出应为drwxr-xr-x 5 mysql mysql，而不是root root
真正麻烦的从来不是命令敲不对，而是挂载后第一次 docker logs mysql8 看到一堆权限错误却不知道该改宿主机目录、改容器参数，还是改镜像启动逻辑——盯住 UID 999 和 --init 这两个点，基本就稳了。
