Docker 一键启动 MySQL 8.0 测试实例需指定 root 密码、数据卷挂载、非冲突端口映射及自动重启策略；多人共用时应强制库名前缀（如 dev_）并配合权限控制实现逻辑隔离；初始化 SQL 可通过 docker exec 执行。
用 Docker 一键拉起 MySQL 8.0 测试实例
不需要装包、不污染宿主机、5 秒内跑起来——这是测试环境最实际的需求。docker run 是最快路径，但参数错一个就连不上或数据不持久。
- 必须加
-e MYSQL_ROOT_PASSWORD=123456，否则容器启动后无法登录 - 要用
-v ./mysql-data:/var/lib/mysql挂载数据目录，否则容器重启数据全丢 - 端口映射写成
-p 3307:3306（而非 3306:3306），避免和本地已有的 MySQL 冲突 - 加上
--restart=unless-stopped，防止机器重启后服务掉线
完整命令示例：
docker run -d --name mysql-test -e MYSQL_ROOT_PASSWORD=123456 -v $(pwd)/mysql-data:/var/lib/mysql -p 3307:3306 --restart=unless-stopped mysql:8.0建库时强制加前缀实现逻辑隔离
多人共用一个测试 MySQL 实例时，“删库跑路”风险来自误操作——DROP DATABASE test 可能干掉别人正在跑的 test 库。物理隔离成本高，逻辑前缀是更轻量的解法。
- 所有测试库名统一用
dev_或test_开头，例如dev_user_service、test_order_api - 应用配置里数据库名也写死带前缀，避免代码里拼接出错
- 配合 MySQL 权限控制：给每个开发者分配账号，并限制只对
dev_%库有CREATE/SELECT/DROP权限（用GRANT …… ON `dev_%`.* TO 'user'）
初始化 SQL 执行失败常见原因及绕过方式
用 docker exec -i mysql-test mysql -uroot -p123456 导入初始化脚本时，经常卡住或报错，根本不是语法问题，而是权限和字符集惹的祸。
-
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements：MySQL 8 默认启用密码强度策略，初始化前先执行SET GLOBAL validate_password.policy=LOW; -
ERROR 1067 (42000): Invalid default value for 'created_at'：SQL 模式含NO_ZERO_DATE，在docker run启动时加参数--sql-mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"替换默认模式 - 中文乱码？在
init.sql开头加SET NAMES utf8mb4;，并确保建库语句里写了CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci
测试结束后快速清理不留残影
测试完不清理，下次启动可能因表名冲突、自增 ID 冲突、触发器残留导致奇怪行为。别只删库，要清得干净。
- 删库命令别手敲：用
mysql -uroot -p123456 -e "SHOW DATABASES LIKE'test_%';" | grep -v Database | xargs -I{} mysql -uroot -p123456 -e "DROP DATABASE {};" - 删容器前先停服务：
docker stop mysql-test && docker rm mysql-test，直接rm -f可能导致/var/lib/mysql目录被锁住，下次启动报错InnoDB: Operating system error number 13 - 挂载的
mysql-data目录建议每次测试前rm -rf掉——看似暴力，实则比修复半残数据文件省两个小时
真正麻烦的不是搭环境，而是“以为搭好了”，结果发现时区没设、binlog 开着占满磁盘、或者某个连接池死连着旧库不肯断。每次 docker run 后花 30 秒跑一遍 mysql -uroot -p123456 -e "SELECT @@time_zone, @@sql_mode, @@innodb_file_per_table;" 看一眼，比事后 debug 强十倍。
