绝大多数情况下不需要自己写 Dockerfile，应直接使用官方 mysql 镜像；需确保挂载的 /var/lib/mysql 为空目录，字符集需启动前通过 command 或 conf.d/my.cnf 设定，避免误用 host 网络模式导致绑定失败。
MySQL 容器该不该自己写 Dockerfile？
绝大多数情况下，不需要——官方 mysql 镜像已预装、可配置、持续更新，自己从 debian 或 alpine 基础镜像装容易漏掉用户权限、初始化逻辑、健康检查等细节。
除非你有强定制需求（比如必须用特定编译参数的 MySQL 分支、或要混入非标准插件），否则直接基于 mysql:8.0 或 mysql:5.7 拉取更稳。
- 官方镜像默认以
mysql用户运行，避免 root 权限风险 -
/docker-entrypoint.sh自动处理/docker-entrypoint-initdb.d/下的 SQL/Shell 初始化脚本 - 环境变量如
MYSQL_ROOT_PASSWORD、MYSQL_DATABASE直接生效，无需手动写配置文件
挂载卷时 /var/lib/mysql 路径必须是空目录
这是最常踩的坑：宿主机挂载路径如果已有文件（尤其是非 MySQL 生成的文件），容器启动会失败并报错 mysqld: Can't read dir of '/etc/mysql/conf.d/' 或卡在 Initializing database。
根本原因是 MySQL 初始化流程依赖 /var/lib/mysql 目录为空——它要自己建 data dictionary、ibdata1、系统表等。一旦发现该目录非空且无合法 InnoDB 文件结构，就拒绝启动。
- 首次运行前，先清空宿主机目标路径：
rm -rf /path/to/mysql-data && mkdir -p /path/to/mysql-data - 不要把整个项目目录甚至
~挂进去；推荐用绝对路径，如/opt/mysql-data - 若需保留数据迁移，应使用
mysqldump导出再导入，而不是直接拷贝ib*/*.frm文件
字符集与 collation 必须在容器启动前定死
MySQL 容器启动后，character_set_server 和 collation_server 无法通过环境变量动态修改；后续改配置文件 + 重启，会导致初始化脚本失效或连接异常。
正确做法是在 docker run 或 docker-compose.yml 中用 command 覆盖默认启动命令，显式传参：
command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
或者用自定义 my.cnf 挂载（注意路径和权限）：
- 准备
my.cnf文件，内容含[mysqld]段落，设置character-set-server和collation-server - 挂载到容器内
/etc/mysql/conf.d/my.cnf（官方镜像会自动加载/etc/mysql/conf.d/下所有.cnf） - 确保宿主机上该文件属主不是 root（MySQL 进程以
mysql用户运行，读不到 root-only 文件）
docker-compose.yml 中 network_mode: "host" 会让 MySQL 绑定失败
如果你在 docker-compose.yml 里写了 network_mode: "host"，又没改 bind-address，MySQL 默认只监听 127.0.0.1，导致宿主机其他容器或本机连不上 localhost:3306。
这不是权限问题，是网络栈混淆：host 模式下容器共享宿主机网络命名空间，但 MySQL 仍按自己的配置 bind，而 127.0.0.1 在 host 模式中指向的是宿主机回环，不是容器内部视角。
- 要么删掉
network_mode: "host"，用默认 bridge 网络 +ports: ["3306:3306"] - 要么保留 host 模式，但加
command强制绑定0.0.0.0：--bind-address=0.0.0.0 - 别信“加了
privileged: true就能解决”——这跟网络绑定无关，纯属误导
/var/lib/mysql 不干净，或者配置参数没进对的启动流程。 
