为什么用 Docker 跑 MySQL 比直接装包更稳？
因为环境不一致是数据库上线最常踩的坑——开发机上
mysql:8.0.33能连，生产服务器上却报
Unknown error 1045，八成是 libaio 版本、glibc 兼容性或 my.cnf 默认参数不一致导致的。Docker 把 MySQL 二进制、依赖库、配置模板全打包进镜像，同一镜像在 Ubuntu、CentOS、甚至 macOS（WSL2）上启动，行为完全一致。
这不是“看起来一样”，而是内核级隔离：容器用
namespaces隔开进程、网络、挂载点，用
cgroups限 CPU 和内存，MySQL 不会抢 Web 服务的资源，也不会被宿主机上其他 mysqld 实例干扰端口（比如两个实例都绑
3306，只要映射宿主端口不同就互不冲突）。
必须加的三个启动参数，少一个都可能翻车
很多人只写
docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=xxx mysql:8.0，看似跑起来了，但一重启数据就丢、日志查不到、权限改不了——问题出在没管好数据、日志和初始化逻辑。
-v /data/mysql:/var/lib/mysql：必须挂载数据目录，否则容器删掉，
/var/lib/mysql里所有表结构和数据全丢；别用
docker volume create后再映射到随机路径，生产环境要绝对控制物理位置
-v /etc/my.cnf:/etc/mysql/my.cnf:ro：自定义配置必须只读挂载，否则容器启动时会覆盖你写的
innodb_buffer_pool_size或
max_connections
--restart unless-stopped：防止宿主机 reboot 后 MySQL 容器没起来，应用连不上就告警；别用
always，它会在故障反复拉起失败容器，掩盖真实问题
ARM 芯片（M1/M2/M3 Mac）、Ubuntu 24.04 等新环境常见报错
执行
docker run mysql:8.0卡在
Pulling from library/mysql或直接报
no matching manifest for linux/arm64/v8，说明你拉的镜像是 x86 构建的，ARM 机器无法原生运行。
解决方法很简单，加平台声明：
docker run --platform linux/amd64 -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=xxx mysql:8.0
Ubuntu 24.04 上还可能遇到
systemd-resolved导致容器内 DNS 解析失败，表现为
host not found。临时方案是启动时加
--dns 8.8.8.8；根治法是修改
/etc/docker/daemon.json加
"dns": ["8.8.8.8"]后
sudo systemctl restart docker。
数据卷权限、字符集、时区这些细节，线上不能靠猜
MySQL 容器启动后进不去，日志里有
mysqld: Can't read dir of '/etc/mysql/conf.d/'，大概率是挂载的
my.cnf权限不对（宿主机文件 uid/gid 不匹配容器内 mysql 用户）；或者容器里默认时区是 UTC，但你的业务 SQL 用
NOW()插入时间，结果比北京时间慢 8 小时。 修复权限：
sudo chown -R 999:999 /data/mysql（MySQL 官方镜像中 mysql 用户 uid/gid 固定为 999） 统一字符集：启动时加
-e MYSQL_INITDB_ARGS="--default-authentication-plugin=mysql_native_password --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci"，避免客户端连上后
SHOW VARIABLES LIKE 'char%'一堆 latin1 指定时区：
-e TZ=Asia/Shanghai，并确保挂载的
my.cnf里有
default-time-zone = '+08:00'
真正麻烦的从来不是“能不能跑”，而是“跑得对不对”——比如 binlog 格式没设成
ROW，后续做主从或 CDC 就直接卡死；又比如没关
skip-host-cache，高并发下 DNS 查询拖慢连接建立。这些都不是 Docker 的锅，但只有在容器化部署时，才逼你一次性把所有隐性依赖显性化。
