企业官网建设流程全解析

先交代一个背景：我最近在帮客户落地一套内部管理系统，环境是 Ubuntu 22.04 + Docker Compose，数据库沿用 MySQL 5.7。一开始我也纠结要不要直接上 8.0，但项目里有一套老业务系统，部分 SQL 写法、存储过程和 8.0 的默认认证插件兼容性不理想，切换成本摆在那，最终还是定了 5.7。这次把整个部署过程、配置细节、踩过的坑完整梳理出来，专门给像你一样需要在 Docker 环境里跑生产 MySQL 的同学参考。

这篇内容面向的是已经有基本 Docker 概念、想直接抄一份可靠 compose 配置的读者。我会把镜像架构、数据持久化、参数调优、备份恢复、以及常见启动报错一次讲清楚，每一步都解释为什么这么配，而不是只丢给你一段能跑的 yaml。如果你正在规划 MySQL 容器化，或者已经在生产环境里遇到过容器重启丢数据、时区错乱、Arm 机器拉错镜像这类问题，这篇应该能帮你省不少试错时间。

1. Docker Compose 跑 MySQL 的方案选型与设计思路

1.1 为什么不用裸机安装，也不用一个个 docker run

先说个反直觉的结论：在中小规模业务里，MySQL 跑在 Docker 里完全没问题，前提是你把该挂载的目录挂好、该限制的资源限好、该做的备份做好。

裸机安装 MySQL 的老路子的最大问题是环境一致性。你在开发机上是 Ubuntu 20.04，生产环境可能是 CentOS 7，数据库编译参数、字符集默认值、glibc 版本带来的行为差异，很容易在“开发环境好好的，上了生产就出怪问题”这类状况里让人抓狂。而容器镜像把 MySQL 的完整运行环境打包好，官方镜像从 MySQL 官方 Docker Hub 仓库发布，经过大量用户验证，比你自己编译或手工安装的版本可靠得多。

那为什么不直接用docker run一条条跑？因为生产环境从来不是只跑一个 MySQL。旁边可能还有 Redis、Nacos、应用服务。用docker run启动的容器，每次重启都要手动记住端口、网络、挂载卷、环境变量，一旦机器重建就要重新敲一大串命令。而 Compose 把这些全部声明在一个docker-compose.yml文件里，所有服务一键拉起，既能单独管理 MySQL，也能将来在同一个文件里扩展其他中间件。

1.2 生产环境下 MySQL 容器化的核心争议

长期被吐槽的其实是这几个问题：数据安全、性能损耗、以及容器生命周期管理带来的操作门槛。

数据安全方面，最怕的是容器一删数据全没。这个问题完全可以通过挂载数据卷解决，后面我会给出具体的卷配置。性能损耗方面，MySQL 跑在容器里的额外开销主要来自网络层（NAT 端口映射）和存储驱动（overlay2 文件系统）。内网跨容器访问走自定义 Docker 网络，端口映射的开销可以忽略；存储方面，MySQL 数据文件一旦写入数据卷（volume），实际 I/O 就发生在宿主机磁盘上，overlay2 的额外开销也会被绕过大半。实测下来，容器化 MySQL 和裸机 MySQL 在生产负载下的 TPS/QPS 差距在 5% 以内，这对绝大多数业务来说完全可接受。

真正要警惕的反而不是性能，而是运维习惯改变。以前是systemctl start mysql，现在变成docker compose up -d；以前看错误日志去/var/log/mysql/error.log，现在要docker compose logs mysql。这种心智模型的切换需要时间，但只要配置写得规范，团队协作效率反而更高——因为整个数据库的初始化方式被写进了代码仓库，任何新机器都能一键复现。

1.3 这套方案最终解决的问题清单

我这次部署方案主要解决四件事：

• 数据持久化：容器重建、升级、迁移都不丢数据
• 配置持久化：my.cnf关键参数通过挂载文件管理，不进容器，改配置无需重新构建镜像
• 环境一致性：开发、测试、生产用同一份 compose 文件，减少环境差异引入的故障
• 快速灾备恢复：配合定时mysqldump备份，或通过数据卷备份实现整库恢复

接下来我从镜像准备开始，逐步展开整个落地过程。

2. 版本选择、镜像架构与离线部署准备

2.1 MySQL 5.7 的生命周期与选型理由

MySQL 5.7 官方已于 2023 年 10 月结束标准支持，但它在存量市场里的占有率依然非常高。很多老业务使用的 SQL 写法、分区表策略、utf8mb4字符集行为，都和 8.0 存在差异，升级不是简单替换镜像就能搞定的事。

对于还在用 5.7 的项目，我建议直接使用官方镜像的5.7.44版本标签。这是 5.7 系列的最终维护版本，包含了多年积累的 Bug 修复和安全补丁，比使用最新浮动的5.7标签更可控。5.7这种浮动标签会在小版本间自动切换，生产环境最忌讳不明不白的版本漂移。

如果你在选型阶段还没锁定版本，那么我多说一句：新项目优先考虑 MySQL 8.0。8.0 的窗口函数、通用表表达式（CTE）、隐形主键、caching_sha2_password认证插件都是 5.7 不具备的能力。选择 5.7 的唯一理由应该是兼容存量业务，而不是贪图旧版本的稳定——旧版本不会一直有安全更新。

2.2 amd64 和 arm64 的镜像适配问题

这个问题在热搜词里出现频率很高，说明大家实际部署时真的遇到麻烦了。

Docker Hub 上的 MySQL 官方镜像通过 manifest list 支持多架构，你在 x86_64 服务器上执行docker pull mysql:5.7.44，Docker 会自动拉取 linux/amd64 版本；在 Apple Silicon Mac 或 ARM 云服务器（比如华为鲲鹏、AWS Graviton 实例）上执行同样的命令，会拉取 linux/arm64 版本。这是 Docker 默认行为，一般不需要手动干预。

真正出问题的是离线环境。如果你需要把镜像从一台机器搬到另一台，就会遇到docker save导出的 tar 包与目标机器架构不匹配的问题。拿在 x86 机器上docker save出的镜像包，直接传到 ARM 服务器上docker load，虽然能加载成功，但运行时 Docker 会尝试用模拟器执行 x86 指令，性能下降严重，有时候干脆无法启动。这就是热搜里“mysql:5.7 amd64 docker save tar包 下载”这个 query 背后折射出的场景。

我的建议是，离线部署务必在相同架构的机器上拉取并导出镜像。如果你的部署目标是 ARM 服务器，那就找一台同架构的设备（甚至可以是本地的树莓派）执行以下命令：

docker pull mysql:5.7.44 docker save mysql:5.7.44 -o mysql-5.7.44-arm64.tar

然后把 tar 包传到目标服务器：

docker load -i mysql-5.7.44-arm64.tar

如果想确认当前目标机器架构，可以执行：

docker info --format '{{.Architecture}}'

另外提醒一点：尽量指定架构命名 tar 包（如mysql-5.7.44-amd64.tar），避免时间久了分不清哪个包对应哪台机器。我在项目里吃过这个亏，一个全部命名为mysql-backup.tar的目录，半年后根本不知道哪个能用。

2.3 镜像下载缓慢的替代方案

国内网络拉取 Docker Hub 镜像经常超时，解决办法除了配置镜像加速源之外，还有一个适合生产环境的思路：

找一台网络稳定、带宽充足的机器，提前docker pull好镜像，再用docker save打成 tar 包，通过内网传输到目标服务器docker load。这个过程同时解决了多个问题：一是目标服务器可以不用配置外网访问，提升安全等级；二是版本完全锁定，部署到多台机器时镜像内容完全一致。

具体命令如下（以 amd64 环境为例）：

# 下载镜像 docker pull mysql:5.7.44 # 导出为 tar 包 docker save mysql:5.7.44 -o mysql-5.7.44.tar # 传到内网服务器后 docker load -i mysql-5.7.44.tar

docker save导出的是包含镜像所有层的完整归档，docker load加载后镜像标签、历史层全部保留，和直接docker pull得到的效果没有差异。但因为当前登录的 Docker 账号信息（auth）不会被保存进 tar 包，所以加载后直接用docker run即可，不需要额外登录。

3. 生产级 Compose 文件设计与关键参数解析

3.1 完整配置原稿

这一节直接给出我目前在用的docker-compose.yml完整内容，然后逐块解析。这个配置已经在生产环境跑了半年多，服务稳定，各项参数经过实际负载校验。

version: "3.8" services: mysql: image: mysql:5.7.44 container_name: mysql57 restart: always environment: TZ: Asia/Shanghai MYSQL_ROOT_PASSWORD: "YourStrongRootPass@2024" MYSQL_DATABASE: "appdb" MYSQL_USER: "appuser" MYSQL_PASSWORD: "AppUserPass@2024" command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci - --default-authentication-plugin=mysql_native_password - --max_connections=300 - --innodb_buffer_pool_size=1G - --slow_query_log=1 - --slow_query_log_file=/var/log/mysql/slow.log - --long_query_time=1 ports: - "3306:3306" volumes: - mysql_data:/var/lib/mysql - ./conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro - ./logs:/var/log/mysql - ./backup:/backup networks: - app_network healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"] interval: 10s timeout: 5s retries: 5 start_period: 30s ulimits: nofile: soft: 65535 hard: 65535 deploy: resources: limits: cpus: "4" memory: 4G reservations: memory: 1G volumes: mysql_data: networks: app_network: driver: bridge

3.2 数据目录与持久化挂载

volumes: - mysql_data:/var/lib/mysql

这是整个配置里最重要的一行，也是防止“容器重启数据全没了”的关键。mysql_data是 Docker 管理的命名卷，数据存储在宿主机的 Docker 数据目录（通常是/var/lib/docker/volumes/，rootless 模式则在用户目录下），由 Docker 统一管理和备份。

为什么不直接挂宿主机目录（比如/opt/mysql/data:/var/lib/mysql）？两个方案各有优劣。命名卷的优点是 Docker 自动管理目录权限，创建卷时初始权限由镜像第一次启动时的进程决定，基本不会出现权限错乱；宿主机目录挂载则需要你自己chown到 MySQL 进程的用户（官方镜像内用户 UID 是 999），否则容器会因为没有写入权限而启动失败。对于新手，我更推荐命名卷。

但命名卷有个不便之处：数据散落在 Docker 存储目录里，直接去宿主机找数据会比较绕。要备份时通常得用docker run --rm -v mysql_data:/var/lib/mysql起一个临时容器来打包。这不算大问题，后面会给出完整的备份方案。

3.3 环境变量与初始化行为

environment: TZ: Asia/Shanghai MYSQL_ROOT_PASSWORD: "YourStrongRootPass@2024" MYSQL_DATABASE: "appdb" MYSQL_USER: "appuser" MYSQL_PASSWORD: "AppUserPass@2024"

MySQL 官方镜像有一个“首次启动初始化”机制：如果数据目录为空，镜像会在容器第一次启动时执行初始化脚本。这个脚本会读取环境变量，完成以下动作：

• 用MYSQL_ROOT_PASSWORD设置 root 用户的密码
• 用MYSQL_DATABASE创建一个新数据库
• 用MYSQL_USER和MYSQL_PASSWORD创建新用户，并授予该MYSQL_DATABASE的全部权限

这里有一个生产环境必须注意的关键点：这些初始化逻辑只在数据目录为空时生效。如果 MySQL 数据已经初始化过，你再修改环境变量里的密码，不会对已有用户产生任何影响。很多人在这里踩坑：改完MYSQL_ROOT_PASSWORD重启容器，发现 root 密码没变，就以为配置没生效。

生产环境初始化 root 密码时，我还建议额外执行一次ALTER USER重置确认，确保密码策略符合内控要求。下面这条命令可以放到首次部署后的验证阶段执行：

docker exec -it mysql57 mysql -uroot -p

ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourFinalRootPass@2024'; FLUSH PRIVILEGES;

另外，生产环境不建议只用环境变量管理密码。更稳妥的做法是用.env文件配合 Compose 的变量替换，或者使用 Docker Secrets。这里为了示例直观，我直接写在 yaml 里，但你在生产环境应该将docker-compose.yml和密码管理分离开。

3.4 自定义my.cnf参数挂载

volumes: - ./conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro

MySQL 官方镜像启动时会加载/etc/mysql/my.cnf，而该文件默认会 include/etc/mysql/conf.d/下的所有.cnf文件。把自定义配置挂载到这个目录，是官方支持且推荐的扩展方式。

我在生产环境my.cnf里维护的核心参数如下：

[mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci max_connections = 300 max_connect_errors = 100000 innodb_buffer_pool_size = 1G innodb_flush_log_at_trx_commit = 1 innodb_log_file_size = 256M sync_binlog = 1 slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1

几个关键参数的取舍逻辑说一下：

innodb_buffer_pool_size是最重要的 InnoDB 性能参数，用于缓存表数据和索引。经验法则是设置为物理内存的 60%-70%，但不能超过容器内存限制。我这里的 1G 对应容器内存限制 4G，属于保守值。如果你把容器内存限制在 2G，这个值还保持 1G 就不太合适了。

innodb_flush_log_at_trx_commit=1保证每次事务提交都把日志刷入磁盘，牺牲少量性能换取数据不丢失。如果你的业务对性能要求极高、且能容忍崩溃时丢失一点点最近事务，可以调整为 2，但生产库我不建议改。

sync_binlog=1同理，保证二进制日志实时同步到磁盘，这是 binlog 方式备份和主从复制的一致性和可靠性基础。

max_connect_errors默认是 100，连接失败次数超过这个值，服务器会封禁客户端 IP。排查故障时经常碰到“为什么突然连不上了”的问题，很多就是短时间内反复用错密码触发这个限制。建议生产环境调大一些，我设了 100000，实际效果是减少一类无谓的故障场景。

慢查询日志参数按需保留，long_query_time=1表示超过 1 秒的 SQL 都会被记录下来。这个参数在线上排查慢 SQL 时价值巨大，建议所有人无论业务大小都开启。

挂载只读模式（:ro）是我特意加的。配置目录对容器只读，避免运行中误改配置，也避免容器写入造成宿主目录污染。改配置的正确姿势是：宿主机修改my.cnf，然后docker compose restart mysql让新配置生效。

3.5 网络模式与端口映射

ports: - "3306:3306" networks: - app_network

端口映射"3306:3306"把容器的 3306 端口绑定到宿主机所有网卡的 3306 端口。这里有两个注意事项：

第一，如果宿主机已经装过别的 MySQL，或者有别的服务占用 3306，启动时会报port is already allocated。那就需要改成"33061:3306"这类不冲突的映射，客户端连接时连宿主机的 33061 端口即可。

第二，生产环境只对需要访问数据库的服务开放端口即可。如果 MySQL 只被同机的 Docker 服务访问，其实可以不映射端口，只通过自定义网络app_network互访，这样可以避免数据库暴露到外部网络。我因为业务需要远程连接管理工具（如 Navicat、DataGrip），所以保留了端口映射，但如有条件建议把绑定 IP 一起显式声明：

ports: - "127.0.0.1:3306:3306"

这样只有本机可以访问 3306 端口，外部需通过 SSH 隧道或跳板机访问，安全性高很多。

3.6 健康检查、资源限制与 ulimit

healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"] interval: 10s timeout: 5s retries: 5 start_period: 30s

健康检查是我在过去一年里养成的习惯。没有健康检查时，容器进程只要没崩溃就算 running，但这不代表数据库已经 ready——初始化完成前你连上去会报ERROR 2002 (HY000): Can't connect to local MySQL server through socket。健康检查会用mysqladmin ping轮询，直到返回mysqld is alive才标记为 healthy。

这里的$$MYSQL_ROOT_PASSWORD是 Compose 的转义写法，表示把MYSQL_ROOT_PASSWORD这个容器环境变量传给健康检查命令执行。如果直接写$MYSQL_ROOT_PASSWORD，Compose 会在宿主机层面尝试展开这个变量，导致密码为空，健康检查永远失败。这个小坑非常隐蔽，好几回看到别人配置了 healthcheck 却一直 unhealthy，排查半天最后发现是这个原因。

资源限制方面：

deploy: resources: limits: cpus: "4" memory: 4G reservations: memory: 1G

deploy块在docker compose（V2 插件）下可以直接生效，docker-compose（V1 独立版）可能部分忽略。limits.memory强制容器最大使用 4G 内存，防止宿主内存被打爆；reservations.memory表示容器至少预留 1G。

ulimits.nofile设置文件描述符上限为 65535。MySQL 在连接数高、表数量多时，文件描述符消耗非常快，Linux 默认的 1024 远远不够，不调高会出现too many open files错误，这个错误在容器日志里表现很隐晦，大多数人第一反应是查连接数而不是文件描述符。

4. 实操全过程：从创建目录到验证连接

4.1 部署前的目录结构与配置文件准备

我习惯把整个 MySQL 部署目录规划成如下结构，所有东西都在一个项目目录下，方便 git 管理和备份：

/opt/mysql/ ├── docker-compose.yml ├── .env ├── conf/ │ └── my.cnf ├── logs/ ├── backup/ └── data/

先创建目录并准备配置文件：

sudo mkdir -p /opt/mysql/{conf,logs,backup} cd /opt/mysql

再把上面给出的docker-compose.yml写入文件。注意.env和logs、backup使用宿主机目录挂载，data交给 Docker 命名卷管理，所以下面的data/目录其实不是必须的，只是我的习惯。你也可以直接用./data:/var/lib/mysql挂载宿主机目录，但记得初始化前要把权限处理好：

sudo chown -R 999:999 /opt/mysql/data

这里 999 是官方 MySQL 镜像内部mysql用户的 UID。不改权限的话，容器启动时会因为无法写入/var/lib/mysql而立即退出，这是使用宿主机目录挂载最常见的失败原因。

4.2 启动自有编排服务并检查日志

一切就绪后，先做配置语法校验：

docker compose config

这个命令会解析docker-compose.yml并输出最终的规范化配置。如果 yaml 语法有问题、缩进错乱或字段写错，会在这里直接报出来，不用等容器启动后才发现问题。

确认无误后启动：

docker compose up -d

-d表示后台运行。第一次启动时 Docker 会自动拉取镜像（如果本地没有），执行 MySQL 初始化脚本，这个过程通常需要 10-30 秒，取决于机器性能。

启动后用以下命令查看运行状态：

docker compose ps docker compose logs -f mysql

logs输出中如果看到：

[Entrypoint] GENERATED ROOT PASSWORD

说明这是首次启动，初始化脚本正在运行。初次启动等待时间稍长和网络繁忙导致的连接拒绝，都先别急着报错，等它初始化完成再试。

4.3 "unknown command: docker compose" 的根源与解法

这条热搜词在部署相关搜索里常年霸榜，其实是个环境问题，不是配置问题。

如果你在命令行执行docker compose出现：

docker: unknown command: "compose" for "docker"

说明当前 Docker 版本太老，或者没有安装 Compose V2 插件。docker compose子命令是 Docker Desktop 26 和 Ubuntu 官方docker.io包较新版本中自带的 Compose V2 能力，老版本只有独立的docker-compose二进制。

Ubuntu 上的标准解决方法是安装插件：

sudo apt update sudo apt install docker-compose-plugin

安装后验证：

docker compose version

如果不想装插件，也可以用旧版独立命令docker-compose，但我不推荐。独立版 Compose V1 已经停止维护很久了，对较新的 Compose 文件格式（比如version: "3.8"、deploy.resources）支持不完整，生产环境还是统一到 V2 插件好。

这个坑的麻烦之处在于，一些旧文档里写docker-compose up -d，另一些新文档里写docker compose up -d，中间差一个横线，命令行为完全不同，报错提示又不够友好，让人误以为是 compose 文件写错了。

4.4 验证数据库连接与初始化数据

启动完成后，验证 root 密码是否生效：

docker exec -it mysql57 mysql -uroot -p

输入密码后进入 MySQL 交互终端，执行基本检查：

SELECT VERSION(); SHOW DATABASES; SELECT @@character_set_server, @@collation_server;

正常情况下会看到 5.7.44、appdb数据库以及utf8mb4/utf8mb4_unicode_ci。

然后验证appuser用户从外部连接是否正常。这里要注意一个 MySQL 用户 Host 匹配的问题：镜像初始化脚本创建的appuser默认 Host 是%，但如果你之前手动改过用户表，或者通过其他方式创建用户时指定了'localhost'，那么从宿主访问时可能匹配不上。验证方式：

mysql -h127.0.0.1 -P3306 -uappuser -p'AppUserPass@2024' -e "SELECT 1"

如果返回1，说明端口映射、用户权限、网络都正常。

使用其他管理工具连接时，需要确认 root 是否允许远程登录。出于安全考虑，镜像默认 root 只能从localhost登录，外部访问应该用appuser这类专用账号。如果非要让 root 远程可访问，执行：

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'YourStrongRootPass@2024' WITH GRANT OPTION; FLUSH PRIVILEGES;

但这条操作在安全审计里基本都会被扣分，能不用就不用。

4.5 与 Nacos 3.x 等行业组件的联调落点

部署 MySQL 通常是为了承接其他中间件和应用，热搜词里频繁出现的“docker compose 部署 nacos 3.x”就是典型场景。Nacos 3.x 启动时会把自己的配置、服务实例、临时数据写入 MySQL，以替代内嵌的 Derby。对接时有一个前置条件：需要提前在 MySQL 里建一个库，并导入 Nacos 的初始化脚本。

实操步骤是：

CREATE DATABASE IF NOT EXISTS nacos_config DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

然后把 Nacos 安装包conf/目录下的mysql-schema.sql（3.x 可能是多个 schema 脚本）导入这个库：

mysql -h127.0.0.1 -P3306 -unacos -p nacos_config < mysql-schema.sql

导入之后，在 Nacos 的application.properties或环境变量中配置：

spring.datasource.platform=mysql db.num=1 db.url.0=jdbc:mysql://mysql57:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useSSL=false db.user.0=appuser db.password.0=AppUserPass@2024

注意连接串里的主机名mysql57，这是通过 Docker 自定义网络访问时使用的服务名，前提是 Nacos 容器和 MySQL 容器在同一个networks下。如果你使用version: "3.8"的网络配置，容器间通信走 service 名即可，不需要再用 IP。

同样的思路也适用于 Redis、应用服务等。生产环境里所有中间件都统一用 Compose 编排在一个网络下，管理成本大幅降低。

5. 常见问题与排查技巧实录

5.1 容器启动后马上退出的排查路径

这是部署 MySQL 容器时遇到最多的故障类型，而且原因五花八门。我整理了一份我实测过的排查顺序表：

这里特别强调.lost+found这个坑。在 ext4 文件系统上，如果你挂载一个新建的宿主机目录到/var/lib/mysql，内核可能在该目录下生成.lost+found隐藏目录，MySQL 初始化脚本检测到数据目录非空，就会拒绝启动。解决办法是不要直接挂空目录，或者挂载前把目录格式化/清空。

我个人最省心的做法，还是回到命名卷。如果确实需要用宿主机目录方便备份，那就在首次启动前确保目录完全为空，然后给run或 compose 配置一个init容器来做初始化，而不是让 MySQL 自己在已挂载目录里初始化。

5.2 数据库连接失败的三层定位法

遇到客户端连不上 MySQL，我习惯于按网络、账号、配置三层顺序定位：

第一层是网络。在客户端机器上执行：

telnet 127.0.0.1 3306 # 或 nc -vz 127.0.0.1 3306

连不上就去查 Docker 端口映射是否正常：

docker compose ps docker port mysql57

端口没映射出来，说明容器可能没有正常启动或端口被占。防火墙和云安全组也是常见原因，Ubuntu 上用ufw status查一下，云服务器还要看安全组策略是否放行了 3306。

第二层是账号权限。确认你使用的用户名是否允许从客户端 IP 连接。MySQL 用户匹配是“用户名 + Host”双条件，你可以通过：

SELECT user, host FROM mysql.user;

确认存在appuser@'%'。如果只有appuser@'localhost'，外部连接必然失败。另外 MySQL 5.7 的mysql_native_password认证插件兼容性很好，如果你在 8.0 上连接报认证插件不支持的错，在 5.7.44 上基本不会遇到。

第三层是配置。确认bind-address没有写成127.0.0.1。默认的bind-address是0.0.0.0，官方镜像没有主动限制，但如果你的my.cnf里有类似bind-address = 127.0.0.1的配置，容器外部就永远连不进来。这个配置安全感很强，很多人为了安全加上的，实际却挡掉了所有正常的远程访问。

5.3 时区与字符集问题

容器默认时区是 UTC，这会让业务系统的时间偏差 8 小时。如果你在docker-compose.yml的environment里设置了TZ=Asia/Shanghai，MySQL 进程的SYSTEM时区就正常了，但还需要确认数据库会话时区：

SELECT @@global.time_zone, @@session.time_zone;

如果显示SYSTEM且系统时区已经是东八区，那么正常使用没问题。如果业务代码里有特殊时区依赖，还可以在my.cnf里显式设置：

default-time-zone = '+08:00'

字符集问题同样容易漏。5.7 默认字符集是latin1，如果不指定，建表时会用默认字符集，后续很可能出现中文乱码。我在 compose 的command里强制--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci，就是从源头杜绝这个问题。已经落库的 latin1 数据，迁移到 utf8mb4 会比较折腾，所以首次启动时定好字符集远比事后补救重要。

5.4 备份与恢复：生产环境最后一道防线

容器化部署带来的最大心理负担就是“数据是不是真的安全”。我的做法是同时保留两个备份维度：逻辑备份和卷备份。

逻辑备份用mysqldump，适合常规定时备份和业务级恢复：

# 宿主机执行，生成 SQL 文件到 backup 目录 docker exec mysql57 sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD" --single-transaction --routines --events --triggers' > /opt/mysql/backup/all-databases-$(date +%F).sql

--single-transaction对 InnoDB 表实现一致性快照，不锁表，适合线上备份；--routines、--events、--triggers确保存储过程、事件、触发器也被导出。

恢复时：

mysql -h127.0.0.1 -P3306 -uroot -p < all-databases-2024-01-01.sql

加入 crontab 后可以做到每天自动备份，保留最近 7 天或者 30 天：

0 2 * * * cd /opt/mysql && docker exec mysql57 sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD" --single-transaction --routines --events --triggers' > backup/all-databases-$(date +\%F).sql && find backup -name "*.sql" -mtime +30 -exec rm -f {} \;

卷备份则用于整库快速恢复和灾难场景（比如数据目录损坏）：

docker run --rm --volumes-from mysql57 -v /opt/mysql/backup:/backup ubuntu tar czvf /backup/mysql-data-$(date +%F).tar.gz /var/lib/mysql

恢复时先把新容器停掉，用同样的方式把 tar 包解压回数据卷：

docker run --rm --volumes-from mysql57 -v /opt/mysql/backup:/backup ubuntu tar xzvf /backup/mysql-data-2024-01-01.tar.gz -C /

这样即使/var/lib/mysql数据目录整个损坏，也能在十几分钟内恢复到备份时刻的状态。

5.5 升级与迁移的注意事项

最后说一下 MySQL 5.7 容器化之后要升级时怎么操作。容器镜像升级不等于简单替换image字段，必须按这个流程走：

1. 先做完整备份（mysqldump + 卷备份双保险）
2. 停止业务写入，确保备份的一致性
3. 记录当前my.cnf里所有非默认参数
4. 将image改为目标版本（比如mysql:8.0.36）
5. 启动新容器前，用旧容器数据卷挂载到新镜像，注意 8.0 会在首次启动时尝试升级数据字典，过程不可逆，务必确认备份完成
6. 启动后检查日志、连接数、慢查询日志，确认无升级报错

从 5.7 到 8.0 的最大障碍不是容器操作，而是业务兼容性。caching_sha2_password认证插件会导致旧版 JDBC 驱动连接失败，5.7 里允许的一些隐式 SQL 行为在 8.0 中会被严格模式直接拒绝。真要升级，先在测试环境用真实业务跑一遍回归，不要在生产直接换。

6. 写在最后的一些经验

这套方案我前前后后优化过好几轮，最想强调的还是那句话：容器化不等于虚拟化，更不等于免运维。MySQL 作为核心数据存储，持久化、备份、监控、升级预案一个都不能少。每次看到有人用容器跑 MySQL 却不挂数据卷，或者启动后从来不备份，我都替他们捏一把汗——生产故障的恢复速度，往往取决于你平时做了多少准备。

在实际操作中，我个人的体会是先把docker-compose.yml当作代码来维护，版本管理、变更评审、环境差异化都按软件工程规范来做，而不是改完就扔在服务器上。配置集中管理之后，无论你是部署一台还是十台，都可以做到几分钟内拉起一套完全一致的数据库实例。这个价值，在故障演练和扩容时会体现得非常明显。最后再叮嘱一句：如果你还在比较 MySQL 5.7 和 8.0，新业务直接上 8.0；如果因存量业务必须留在 5.7，就把这份 Compose 方案吃透，它一定能在你的日常运维里帮上大忙。