根本原因是数据目录未初始化或挂载方式错误：空目录或非mysql格式数据导致初始化跳过，引发权限、文件结构及系统表缺失。
MySQL容器启动失败：mysqld 退出，日志显示 Can't open the mysql.plugin table
根本原因是数据目录未初始化或挂载方式错误。Docker镜像默认在首次启动时自动初始化 /var/lib/mysql，但一旦你用 -v 挂载了一个**空目录**或**已有非MySQL格式数据的目录**，初始化流程就会跳过，导致权限、文件结构、系统表缺失。
实操建议：
- 首次启动前，确保挂载的目标宿主机目录为空（或完全删除后重建），不要复用旧的 MySQL 数据目录（尤其是从物理机直接拷贝过来的）
- 显式指定
MYSQL_ROOT_PASSWORD环境变量，否则初始化会失败并静默退出 - 加
--initdb --skip-networking参数调试时可临时启用初始化日志输出，但生产环境不推荐长期使用 - 若已挂载非空目录且想重试初始化，先
docker stop容器，清空宿主机挂载点，再删掉容器重新docker run
挂载卷路径写成 /var/lib/mysql 但容器内没生效
常见于 Windows 或 macOS 使用 Docker Desktop 的用户：宿主机路径被映射到 Linux VM 内部，而用户误把 Windows 路径（如 C:\data\mysql）直接传给 -v，Docker 实际挂载的是 VM 里的某个默认共享路径，而非你预期的位置。
实操建议：
- Linux 宿主机：直接用绝对路径，如
-v /opt/mysql-data:/var/lib/mysql - macOS / Windows：在 Docker Desktop 设置中确认「Resources → File Sharing」已添加你的目标目录（例如
/Users/you/mysql-data），然后在命令中使用该路径 - 启动后进容器执行
ls -l /var/lib/mysql，确认文件属主是mysql:mysql（UID 999），不是root—— 否则mysqld拒绝启动 - 若属主不对，宿主机上运行
sudo chown -R 999:999 /path/to/mysql-data（注意：不是mysql:mysql，是 UID/GID 数字）
MYSQL_ROOT_PASSWORD 生效了，但 MYSQL_DATABASE 和 MYSQL_USER 没创建库和账号
这是官方 mysql:8.0+ 镜像的行为变更：只有在数据目录**完全为空**（即首次初始化）时，MYSQL_DATABASE 和 MYSQL_USER 才会触发建库和建用户逻辑；如果挂载卷里已有 ibdata1 或 mysql 子目录，这些变量会被忽略。
实操建议：
- 验证是否首次初始化：检查宿主机挂载目录是否为空，或删掉里面所有文件再试
- 非首次启动时，账号和库需手动创建 —— 进容器执行
mysql -uroot -p$MYSQL_ROOT_PASSWORD -e "CREATE DATABASE myapp; CREATE USER 'myuser'@'%' IDENTIFIED BY 'mypass'; GRANT ALL ON myapp.* TO 'myuser'@'%';" - 避免依赖环境变量自动建库，生产环境建议用
docker-entrypoint-initdb.d挂载 SQL 初始化脚本，更可控
容器重启后连接被拒绝，netstat -tlnp | grep :3306 显示无监听
大概率是 mysqld 进程崩溃后容器自动退出，但 docker ps 看不到，因为默认 restart 策略是 no。MySQL 容器对配置错误极其敏感，比如 my.cnf 里写了不支持的参数、内存限制过低、或挂载的配置文件权限不对（必须是 644，且不能是 root-only 可读）。
实操建议：
- 启动时加
--restart=unless-stopped，方便观察反复崩溃 - 用
docker logs -f <container></container>查看实时错误，重点关注以[ERROR]开头的行 - 若挂载了自定义
my.cnf，确认它放在容器内/etc/mysql/conf.d/下（不是/etc/mysql/my.cnf主文件），且结尾有.cnf后缀 - 限制内存时，
mysql:8.0+至少需要 512MB，--memory=256m极易触发 OOM killer 杀死mysqld
容器跑 MySQL 不难，难在挂载卷的“空”与“非空”边界、环境变量的触发时机、以及跨平台路径映射这三处细节。稍不留意，就卡在“连不上”却查不到日志、“库没建”却以为配置错了、“重启失效”却忘了看进程是否真活着。
