用 Docker 跑本地数据库：测试数据不脏主库

为什么要给测试数据单独开一个库

在开发机直连主库跑测试，最常见的事故是三种：测试数据混进生产表、误执行 UPDATE 把真实记录改掉、跑性能压测时把主库拖慢。哪怕只是本地开发库，被测试脚本反复改写后，也很难再判断某条数据到底是真实业务还是测试残留。用 Docker 起一个独立实例，最直接的好处是它能被「删掉重来」——容器销毁、数据卷清空，环境就像新装的一样。

第一步：一条命令把数据库跑起来

以 MySQL 为例，docker run 加上四个参数就够用：-d 后台运行、-p 映射端口（测试库别用默认 3306，改成 3307 避免和本机已装的实例抢占）、-e 设置 root 密码和初始库名、-v 挂一个数据目录。启动后用 docker logs 看初始化进度，出现 ready for connections 表示可用。第一次启动会跑初始化脚本，耗时比后续启动长，不要在这时候急着连库。

第二步：把建表和数据导入做成可重复的脚本

把建表 DDL 和测试数据放进 init 目录，MySQL 官方镜像会在首次启动时自动执行该目录下的 SQL 文件。这样每次重建容器，环境都是同一份可复现的初始状态，不依赖某台机器上残留的旧库。要注意的是初始化只在数据目录为空时执行一次；如果你改了 SQL 想重跑，必须先把挂载卷删掉，否则改了也不会生效——这是最常被忽略的坑。

第三步：用 compose 固化配置

参数一多，命令行就记不住了，写成 docker-compose.yml 更清爽：镜像版本固定到具体小版本（不要用 latest，避免哪天拉下来行为变了）、端口、环境变量、卷、健康检查都写进去。版本固定这一条尤其重要，本地跑得好好的，换台机器拉到新版镜像后默认排序规则变了，测试结果就对不上。启动用 docker compose up -d，销毁用 docker compose down -v，加 -v 才会连数据卷一起删。

第四步：常见坑与收尾习惯

三个坑值得提前知道：一是端口冲突，本机已经装了数据库时改映射端口；二是权限，容器内的 root 与宿主用户不是一回事，挂载目录权限不对会启动失败；三是时区，容器默认 UTC，涉及时间字段的测试要显式设置时区，否则查出来的时间差 8 小时。收尾习惯只有一句：测试跑完就 docker compose down -v，别让测试库常驻占内存，下次要跑再 up 一次，几十秒的事。