为什么用 Docker 跑 MySQL 比直接装本地更省事
对开发和测试来说，Docker 版 MySQL 的核心优势不是“更先进”，而是“不污染宿主机、启动快、环境一致”。你不用再担心
mysql-server和系统自带的
mysql-client版本冲突，也不用反复执行
apt remove --purge mysql*清理残留。每次需要新实例，
docker run一条命令就拉起一个干净、隔离的 MySQL 进程，数据目录、端口、字符集全由你控制。
快速启动一个可用的 MySQL 容器（带持久化）
别一上来就写复杂
docker-compose.yml。先用最简命令验证是否跑得起来：
docker run -d \ --name mysql-dev \ -e MYSQL_ROOT_PASSWORD=123456 \ -v $(pwd)/mysql-data:/var/lib/mysql \ -p 3307:3306 \ -d mysql:8.0
关键点说明：
MYSQL_ROOT_PASSWORD是必须设置的环境变量，否则容器会启动失败并报错
ERROR 1045 (28000): Access denied for user 'root'@'localhost'
-v挂载宿主机目录到
/var/lib/mysql，否则容器重启后所有数据库全丢 把容器 3306 映射到宿主机 3307，避免和本地已有的 MySQL 冲突 镜像选
mysql:8.0而非
latest，因为后者可能突然切到 8.4 导致客户端连接报
Authentication plugin 'caching_sha2_password' cannot be loaded
连接不上？检查这三处常见断点
运行后连不上，大概率卡在这几个地方：
容器没真正启动成功：执行docker logs mysql-dev，看到
mysqld: ready for connections才算 OK；如果卡在
Initializing database超过 2 分钟，多半是挂载目录权限不对（宿主机目录需对 UID 999 可写） 客户端用错协议：MySQL 8.0 默认启用
caching_sha2_password插件，老版本
mysql命令行或某些 GUI 工具不支持，临时解决加
--default-authentication-plugin=mysql_native_password启动参数，或进容器执行
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '123456';网络不通：Mac/Windows 用户注意 Docker Desktop 的网络模型，
localhost在宿主机上连的是本机，不是容器；Linux 用户若用
host网络模式，端口映射失效，得用
docker inspect mysql-dev | grep IPAddress查 IP
想多个服务共用一套配置？别硬改镜像，用挂载覆盖
自定义
my.cnf不要
docker commit新镜像，既难维护又破坏不可变性。正确做法是准备一个最小配置文件：
[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci default_authentication_plugin=mysql_native_password
然后挂载进去：
docker run ... -v $(pwd)/my.cnf:/etc/mysql/conf.d/custom.cnf ...
注意：
/etc/mysql/conf.d/下所有
.cnf文件都会被 MySQL 自动加载，优先级高于默认配置；文件名必须以
.cnf结尾，
my.conf或
config都无效。
配置生效后，进容器执行
mysql -uroot -p123456 -e "SHOW VARIABLES LIKE 'character_set%';"确认值已更新。
真正麻烦的从来不是启动命令，而是搞清哪些配置项必须通过环境变量传（比如
MYSQL_ROOT_PASSWORD），哪些只能靠
.cnf文件生效（比如
max_connections），还有哪些改了要删掉旧 volume 才能重新初始化 —— 这些边界不摸清，换十次镜像都白搭。
