MySQL 容器该不该自己写 Dockerfile？
先说一个核心结论：绝大多数情况下，你完全不需要自己动手写 Dockerfile。直接使用官方的 mysql 镜像，是更稳妥、更高效的选择。
官方镜像已经为你预装了所需的一切，并且持续更新维护。如果自己从 debian 或 alpine 这类基础镜像开始构建，很容易遗漏关键细节——比如用户权限的精细设置、数据库的初始化逻辑，甚至是健康检查脚本。这些看似不起眼的环节，往往是后期稳定运行的基石。
当然，规则总有例外。如果你的项目有非常强的定制需求，比如必须使用特定编译参数的 MySQL 分支，或者需要集成某些非标准的插件，那么自己编写 Dockerfile 是合理的。否则，直接基于 mysql:8.0 或 mysql:5.7 这样的官方标签拉取镜像，能帮你避开绝大多数“坑”。
- 安全为先：官方镜像默认以
mysql用户身份运行服务，有效避免了使用 root 权限带来的潜在风险。 - 开箱即用：镜像内置的
/docker-entrypoint.sh脚本，会自动处理/docker-entrypoint-initdb.d/目录下的所有 SQL 或 Shell 初始化脚本，简化了数据库的初始配置流程。 - 配置简化：通过环境变量（如
MYSQL_ROOT_PASSWORD、MYSQL_DATABASE）就能直接完成核心配置，无需再手动编写繁琐的配置文件。
绝大多数情况下不需要自己写 Dockerfile，应直接使用官方 mysql 镜像；需确保挂载的 /var/lib/mysql 为空目录，字符集需启动前通过 command 或 conf.d/my.cnf 设定，避免误用 host 网络模式导致绑定失败。
挂载卷时 /var/lib/mysql 路径必须是空目录
这可能是部署 MySQL 容器时最常踩的“坑”了。如果宿主机上准备用于挂载的目录（比如 /path/to/mysql-data）不是空的，里面已经存在文件——尤其是那些并非由 MySQL 生成的文件——那么容器启动几乎注定会失败。
常见的报错信息可能是 mysqld: Can't read dir of '/etc/mysql/conf.d/'，或者容器日志一直卡在 Initializing database 阶段没有下文。
问题的根源在于 MySQL 的初始化流程。它严格依赖 /var/lib/mysql 目录在启动时处于“空”的状态，因为它需要在这个目录里创建自己的数据字典、系统表空间文件（如 ibdata1）等一系列核心数据结构。一旦检测到该目录非空，且内部文件结构不符合 InnoDB 的预期，MySQL 出于安全考虑会直接拒绝启动。
- 首次运行前务必清空：在启动容器前，请确保宿主机上的目标路径是全新的空目录。可以执行
rm -rf /path/to/mysql-data && mkdir -p /path/to/mysql-data来确保这一点。 - 路径选择要明确：避免将整个项目目录甚至用户家目录挂载进去。推荐使用独立的绝对路径，例如
/opt/mysql-data，这样意图清晰，也便于管理。 - 数据迁移的正确姿势：如果需要迁移旧数据，正确的方法是使用
mysqldump工具进行逻辑导出和导入，而不是简单粗暴地直接拷贝物理数据文件（如ib*或*.frm文件）。
字符集与 collation 必须在容器启动前定死
字符集（character_set_server）和排序规则（collation_server）是数据库的“基础编码”，必须在容器第一次启动时就确定下来。一个常见的误解是认为可以通过环境变量在运行时动态修改，实际上这是行不通的。如果启动后再去修改配置文件并重启容器，很可能会导致初始化脚本失效，或者引发意想不到的连接和编码问题。
那么，正确的设定方法有哪些呢？
方法一，在启动命令中直接指定。无论是使用 docker run 命令行，还是在 docker-compose.yml 文件中，都可以通过 command 参数覆盖默认的启动命令，显式传入字符集设置：
command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
方法二，通过挂载自定义配置文件实现。这需要多一步准备：
- 先在宿主机上准备一个
my.cnf文件，在[mysqld]段落中明确设置character-set-server和collation-server。 - 然后将这个文件挂载到容器内的
/etc/mysql/conf.d/my.cnf路径。官方镜像设计得很贴心，它会自动加载/etc/mysql/conf.d/目录下的所有.cnf配置文件。 - 注意文件权限：务必确保宿主机上这个
my.cnf文件的属主和权限，能够让容器内的mysql用户读取。如果文件是 root-only 的，容器进程会因为权限不足而读取失败。
docker-compose.yml 中 network_mode: "host" 会让 MySQL 绑定失败
如果你在 docker-compose.yml 中为 MySQL 服务配置了 network_mode: "host"（即主机网络模式），同时又没有额外调整 MySQL 的绑定地址，那么很可能会遇到一个诡异的问题：从宿主机或者其他容器内部，都无法连接到 MySQL 服务。
这通常不是权限问题。其根源在于网络栈的混淆：在 host 模式下，容器虽然共享了宿主机的网络命名空间，但 MySQL 服务默认的 bind-address 仍然是 127.0.0.1。此时，这个 127.0.0.1 指向的是宿主机的回环接口，而从容器内部（或通过宿主机）发起的连接，其网络上下文可能并不匹配，从而导致连接失败。
- 解决方案一（推荐）：直接移除
network_mode: "host"配置，改用 Docker 默认的 bridge 网络，并通过ports: ["3306:3306"]将端口映射出来。这是最清晰、问题最少的方式。 - 解决方案二：如果确实需要使用 host 模式，则必须在启动命令中强制指定绑定地址为
0.0.0.0，即添加command: --bind-address=0.0.0.0参数，让 MySQL 监听所有网络接口。 - 一个常见的误区：有人认为加上
privileged: true（赋予容器特权）就能解决这个问题，这完全是误导。网络绑定问题和特权模式无关，这样做只会徒增安全风险。
总的来说，MySQL 容器对于挂载目录的状态、配置参数的生效时机以及网络环境有着明确的“强依赖”。部署过程看似直白，但任何一个环节的疏忽——比如 /var/lib/mysql 目录不干净，或者配置参数没有在正确的启动阶段传入——都可能导致容器启动失败，日志里只留下一句 “Starting mysqld daemon” 便再无动静。理解并尊重这些依赖关系，是顺利部署的关键。
