Docker数据卷完全指南：从底层原理到MySQL容器数据持久化实战-嵌云网-嵌入式AI开发资源站

Docker数据卷完全指南：从底层原理到MySQL容器数据持久化实战

外币兑换·2026-09-15·阅读 21 GEO检测（免费）

Docker数据卷容器持久化MySQL 8.0

|难度：普通|阅读约 41 分钟

如果你用 Docker 跑过数据库，大概率经历过这种场面：容器一删，几年的业务数据直接清零。我最早踩这个坑是在用 Docker 部署 MySQL 的时候，当时以为容器里的数据就像虚拟机的磁盘一样，删了还能找回，实际上根本不是这么回事。Docker 容器默认是无状态的，所有写入都会落在容器自身的可写层里，容器一旦被 docker rm，这层数据就跟着没了。

要解决这个问题，靠的就是 Docker 数据卷（volume）。数据卷可以把容器内的目录映射到宿主机或其他存储上，让数据独立于容器的生命周期。这篇文章我会从底层原理、三种挂载方式的差异、实际操作、备份恢复，到踩坑实录和 MySQL 8.0 的完整示例，把 volume 持久化这件事讲透。不管你是刚接触 Docker 的新手，还是已经被“删库跑路”吓到过的老手，都能从里面拿到能直接用的方案。

1. 为什么容器一删，数据就没了：先弄懂容器的存储模型

1.1 镜像层的只读特性与容器可写层的“一次性”

很多人第一次用 Docker 时都会有一个错觉：容器里的文件系统不是跟虚拟机一样是块磁盘吗？容器删了，磁盘文件应该还在宿主机上吧？事实完全不是这样。

Docker 镜像是一层一层只读文件系统叠加出来的。你 docker pull mysql:8.0 拿到的镜像，本质是很多层只读数据组合而成。每个镜像层都对应 Dockerfile 里的一条指令，比如 RUN apt-get install 产生的变更会形成新的一层。这些层在构建完成后就不可修改了。

当容器启动时，Docker 会在这些只读层之上再叠加一个“容器可写层”。进程对文件系统做的所有改动，比如写入 MySQL 的表数据、修改 Nginx 配置、追加日志，都是先写入这个可写层。这里用的是写时复制机制：如果你要修改镜像里的文件，Docker 会先把文件从只读层复制到可写层，再在可写层上进行修改，原本的只读层不会被触碰。

问题就出在这个容器可写层上。它跟容器的生命周期强绑定，docker rm 把容器删掉时，可写层会被整体丢弃。除非你在删除前用 docker commit 把容器提交成新镜像，把可写层“固化”到镜像里，否则所有运行期产生的数据都会直接消失。

多说一句，docker commit 这种操作只适合应急，决不能当持久化策略来用。因为每次提交都会把当前可写层变成新的镜像层，镜像体积会迅速膨胀，而且如果你后面又改了同一个文件，前面提交的内容会成为旧层里的“僵尸数据”。生产环境里如果依赖 commit 来保存数据，早晚要出事。

这个机制可以类比成：镜像是一张只读母盘，容器是你从母盘启动后拿到的“草稿纸”，写入的数据都先落在草稿纸上。草稿纸本身是一次性的，撕了，上面所有内容就没了。你要真想保住数据，只能想办法让数据写在母盘之外的地方，这就是持久化要解决的事。

1.2 持久化到底在“持”什么：把数据搬出容器的生命周期

Docker 给出的答案，就是把数据从容器可写层“搬”出去，放到一个独立于容器的存储单元里，这个存储单元就是数据卷。

数据卷本质上就是宿主机上的一个目录（也可能是一块网络存储、云盘等），容器启动时通过挂载的方式，把这个目录映射到容器内部的某个路径。比如 MySQL 容器默认把数据库文件写到 /var/lib/mysql，那么我从宿主机挂一个卷上去，容器里的 MySQL 往 /var/lib/mysql 写入的所有文件，实际都落在宿主机上的这个卷目录里。

这里的关键在于：数据卷的生命周期跟容器无关。容器可以停止、删除、重建，只要挂载的还是同一个卷，数据就原封不动在那里等着你。

我见过不少人把数据卷理解成“容器里的一个特殊文件夹”，这个理解方向其实不对。数据卷更像是容器外部的“寄存柜”：你可以把东西从背包（容器可写层）放进寄存柜，寄存柜不跟背包绑定，你把背包扔了，只要记得柜子编号，东西随时能取回来。卷的核心价值就是让应用数据与容器实例解耦，获得真正的持久化能力。

理解了这一层，“在 Docker 里做持久化”这件事的答案就很清晰了：你只需要在启动容器时，把需要持久化的目录挂载到数据卷上，剩下的就是卷的管理问题了。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 三种数据卷玩法：命名卷、绑定挂载与 tmpfs 怎么选

2.1 命名卷：官方推荐，最省心的持久化方案

Docker 的卷分为好几种，最常用的是命名卷。用 docker volume create mydata 创建后，Docker 会在它自己管理的目录下（Linux 通常是 /var/lib/docker/volumes/mydata/_data）为你分配一块空间，你只需要通过名字 mydata 来引用它，不用关心它在宿主机上的确切路径。

命名卷有几个明显的优势。第一，跨平台体验一致。同样一条 -v mydata:/var/lib/mysql，在 Linux、Windows 的 Docker Desktop、macOS 上都能正常工作，Docker 会自动把卷映射到对应平台的虚拟磁盘上，你不用改命令。第二，管理和迁移方便。备份一个命名卷，只需要基于卷名挂载一个临时容器打包就行，恢复时按名字重建卷再解包，整个流程非常统一。第三，权限问题相对可控，Docker 会按镜像声明的用户初始化卷目录，多数镜像开箱即用。

跟命名卷相对的还有匿名卷。如果你启动容器时只写了容器路径，比如 docker run -v /data nginx，Docker 会创建一个随机 ID 的匿名卷并挂载上去。匿名卷在实验环境里很方便，但生产环境不推荐，因为你根本不知道这个卷是哪个容器创建的，清理的时候 docker volume ls 一列全是长串乱码，找起来非常痛苦。而且如果你删除容器时用了 -v 参数，匿名卷会被自动清理，一不留神数据就没了。

我的建议是：生产环境一律使用命名卷，数据库、缓存、应用数据都用它保存。匿名卷只适合快速验证某个镜像的目录结构，用完及时清掉。

2.2 绑定挂载：开发调试利器，但要注意权限和路径

绑定挂载是把宿主机上一个你指定的目录，直接挂进容器里。用法很简单：-v /home/user/project:/app，意思是把宿主机的 /home/user/project 目录挂载到容器的 /app 目录。

绑定挂载最大的优点是“所见即所得”，非常适合开发调试。你直接改宿主机上的代码文件，容器里马上就能看到变更，不用重新构建镜像。配置文件的注入也常用这种方式，比如把整个 nginx/conf.d 目录挂进 Nginx 容器，改配置后 reload 就生效了。日志收集也适合绑定挂载，把 /var/log/nginx 挂到宿主机指定目录，日志文件直接用宿主机上的工具分析就行。

但它也有很明显的短板。首先是可移植性差，compose 文件里写死了宿主机路径，换一台机器就得改；其次，权限坑比命名卷多，宿主机目录的属主和权限直接影响容器内进程能否读写；最后是它和宿主机文件系统强耦合，多机上同步不太方便。

实际使用中，我把绑定挂载和命名卷的分工定得很明确：

对比项	命名卷	绑定挂载
数据位置	Dockers 管理目录，抽象度高	宿主机任意路径，直接可见
创建方式	`volume create` 或 compose 声明	启动容器时指定路径
跨平台	命令统一，可移植性好	Windows / Linux 路径写法不同
权限管理	Docker 自动初始化	依赖宿主机目录属性
适用场景	生产环境数据、数据库、应用文件	开发调试、配置注入、日志收集

如果你打算长期保存的数据，我建议咬牙用命名卷；如果只是临时调试、看日志、改配置，绑定挂载效率更高。

2.3 tmpfs 挂载：内存里的临时数据，用完即焚

第三种是 tmpfs 挂载，它连磁盘都不落，数据直接写在内存里。挂载命令长这样：

bash复制docker run -d --name cache \
  --mount type=tmpfs,target=/tmpfs \
  nginx:latest

tmpfs 的两个特性决定了它的适用范围：速度极快，但容器停止后数据立刻消失。所以它适合存放临时文件、缓存、敏感数据（比如密钥，避免写盘留下痕迹）这类“不需要持久化”的内容。测试环境里跑一次性任务，不想在宿主机上留任何垃圾文件，用 tmpfs 非常干净。

注意，tmpfs 不等于“重启后还在”。容器重启时 tmpfs 内容会清空，如果你把某个服务的状态文件放到这里，重启后服务就会回到初始状态，这一点一定要想清楚。

3. 手把手实操：创建命名卷并挂载到容器

3.1 volume 命令速查：创建、查看、清理一条龙

实际操作从命令开始。Docker 为卷提供了一组独立的管理命令，我在日常工作中基本只用到这几个：

bash复制# 创建命名卷
docker volume create mydata

# 查看所有卷
docker volume ls

# 查看某个卷的详细信息，比如宿主机实际存储路径
docker volume inspect mydata

# 删除指定的卷
docker volume rm mydata

# 清理所有没有被容器使用的卷
docker volume prune

很多人创建卷之后都会执行一把 docker volume inspect，它输出的内容非常有用。Name 是卷名，Driver 是卷驱动，默认是 local，最关键的是 Mountpoint：它会直接告诉你这个卷在宿主机上的真实路径，Linux 下通常长这样：

json复制[
    {
        "CreatedAt": "2025-01-01T00:00:00Z",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/mydata/_data",
        "Name": "mydata",
        "Options": {},
        "Scope": "local"
    }
]

有时候排查问题，你会直接 ls /var/lib/docker/volumes/mydata/_data 看卷里面到底有哪些文件。但注意，在 Docker Desktop 环境里，这个路径其实在虚拟硬盘里，你从宿主机不能直接进入那份目录，只能通过容器或 Docker 命令去操作。

删除卷的操作务必谨慎，docker volume rm 是物理删除，没有回收站。prune 更危险，它会把所有没被容器引用的卷一次性全删掉。我有一次清理环境时随手执行了 docker volume prune，结果把另一个项目里暂时关闭容器、但准备以后用的卷也删了，恢复过程折腾了一整天。现在我的习惯是：先 docker volume ls -q 把卷名列出来看一眼，确认哪些确实不要了，再手动逐个删。

3.2 两种挂载语法：-v 简写与 --mount 长格式

把卷挂到容器里，Docker 支持两种语法，老版本常用 -v，新版本推荐 --mount。我这里用 Nginx 静态页面来演示。

先看最常见的 -v 写法：

bash复制docker run -d --name web \
  -p 8080:80 \
  -v mydata:/usr/share/nginx/html:ro \
  nginx:latest

这段命令的意思是：把命名卷 mydata 挂载到容器的 /usr/share/nginx/html 目录，并且以只读方式挂载（:ro）。挂成只读后，容器进程没法往这里面写文件，适合静态页面、配置文件这类不允许容器随意篡改的场景。

再看 --mount 长格式：

bash复制docker run -d --name web \
  -p 8080:80 \
  --mount source=mydata,target=/usr/share/nginx/html,readonly \
  nginx:latest

逻辑完全一样，只是参数写得更清楚。source 是卷名，target 是容器内路径，readonly 是只读。

二者有个关键差异：-v 指定的卷如果不存在，Docker 会自动替你创建一个命名卷；--mount 则要求卷必须已经存在，否则直接报错。这看起来是个小区别，但在自动化部署里影响很大。-v 的优点是好写、适合交互式命令；--mount 更严格，适合写进脚本和 compose 文件里，能避免因为手滑打错卷名而悄悄创建了一个新卷，导致数据“找不到”的问题。

还有一个容易踩的坑：-v 后面如果只写一个容器内路径，比如 -v /usr/share/nginx/html，Docker 会创建一个匿名卷挂上去，而不是什么都不做。很多人在启动容器时发现 docker volume ls 里多了一堆随机名卷，就是这行命令引起的。想要“不挂任何卷”，就别加任何一个 -v 参数。

3.3 用 docker-compose 管理持久化卷：一次配置，处处复用

单容器用 docker run 没问题，但真实项目里服务都是一组一堆的，这时候用 docker-compose 来声明和管理卷才是正确姿势。它最大的好处是“卷即配置”，整个项目需要哪些卷、分别挂到哪个路径，全部写在 YAML 文件里，新环境一键拉起，不用记一堆命令。

下面是一个 Nginx + MySQL 的最小配置，它演示了命名卷在 compose 里的标准写法：

yaml复制services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - web_html:/usr/share/nginx/html

  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root123
      MYSQL_DATABASE: app
    volumes:
      - db_data:/var/lib/mysql

volumes:
  web_html:
  db_data:

services 里每个服务的 volumes 列表写挂载关系，文件末尾的顶层 volumes: 用来声明项目里用到的卷。我只写了卷名，没有写任何宿主机路径，Docker 会按项目名自动创建命名卷。这种方式比 docker run -v 更清爽，因为卷的生命周期完全由 compose 项目管理。

如果要用绑定挂载，compose 的长语法写起来也更清晰：

yaml复制volumes:
  - type: bind
    source: ./nginx/conf.d
    target: /etc/nginx/conf.d

这里 source 支持相对路径，比如 ./nginx/conf.d，会自动解析成宿主机当前目录下的 nginx/conf.d，比写死绝对路径灵活多了。

启动和清理也有讲究：

bash复制# 启动项目，自动创建未存在的卷
docker compose up -d

# 查看当前项目的卷列表
docker compose ps

# 停止并删除容器，但保留卷
docker compose down

# 删除容器，并连带删除声明过的卷（慎用！）
docker compose down -v

docker compose down -v 这条命令，是我要反复提醒的高风险操作。它会把项目里定义的所有卷连同数据一起删掉。我从网上看到不少人 down -v 之后才发现数据库数据全没了，追悔莫及。如果你的卷里存了重要数据，或者想保留现场便于排查，就别加 -v，宁可后面手动删卷。

4. 数据卷的备份、恢复与跨机迁移

4.1 一条命令打包卷内容

Docker 没有提供类似 docker volume export 这种直接导出命令，备份的标准姿势是“通过临时容器打包”。思路很简单：把要备份的卷挂载到一个临时容器里，在容器内用 tar 打包到宿主机指定目录。

bash复制docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/db_data_$(date +%F_%H%M%S).tar.gz -C /data .

拆开看一下，--rm 表示容器执行完命令后就自动删除，不残留痕迹；第一个 -v db_data:/data 把要备份的命名卷挂到容器内的 /data；第二个 -v $(pwd):/backup 把当前目录挂到 /backup，这样 tar 打包的输出文件就能落在宿主机当前目录下。alpine 是一个很小的 Linux 镜像，自带 tar。

注意 -C /data . 的写法，它先把工作目录切到 /data，再打包当前目录。这么做是为了保证 tar 包解压后文件直接落在目标目录里，不带多余的一层路径。

这里有一个数据一致性风险：如果 MySQL、Redis 等服务正在向卷里写数据，你直接打包卷文件，得到的备份可能是不一致的。数据库类服务最好先用它自身的导出工具，比如 MySQL 用 mysqldump 导出逻辑备份，Redis 用 BGSAVE 后再备份 RDB 文件，然后再配合卷文件备份做双保险。我在生产环境里的做法是：每天凌晨用 mysqldump 导出一份 SQL，每周再用上面的命令打包一份完整的卷文件，两份备份放到不同的存储位置，防的就是“关键时刻备份本身坏了”。

4.2 备份文件的恢复与新机迁移

恢复的过程就是备份的逆操作。把备份 tar 包放回宿主机，再起一个临时容器，把它解压到卷目录里即可：

bash复制docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine \
  tar xzf /backup/db_data_20250101_120000.tar.gz -C /data

在恢复前要做两件事：第一，确认目标卷是否存在，如果不存在要先 docker volume create db_data；第二，如果目标卷里已经有数据，建议先把旧卷加个后缀保留，比如 docker volume create db_data_bak，然后再把备份恢复到 db_data_bak，确认数据没问题后再切换，避免覆盖操作没法回滚。

跨机器迁移数据卷，思路跟本机备份恢复完全一致，只是多了一步文件传输。整个流程是：

在源机器上按 4.1 的方法，把卷打包成 tar 文件；
把 tar 文件传到目标机器，可以用 scp、rsync 或对象存储，随你习惯；
在目标机器上创建同名卷；
在目标机器上执行恢复命令，把 tar 包解压到新卷里。

我不建议直接去拷 /var/lib/docker/volumes/xxxx/_data 目录。这个目录路径跟 Docker 版本、操作系统、存储驱动都有关系，直接拷贝容易踩到文件权限、SELinux 上下文等一堆问题。用“临时容器 + tar”的方式，本质上是让容器内的工具来处理文件属性和路径映射，踩坑概率小得多。

4.3 卷权限调整：Permission Denied 与 user 参数

权限问题是数据卷使用中最让我头疼的一类故障，尤其是绑定挂载。原因很好理解：宿主机目录的属主和权限，是直接继承到容器挂载点上的。如果容器内的进程以 UID 999 运行，而宿主机目录属主是 root，那进程一写文件就报 Permission denied。

以 MySQL 官方镜像为例，镜像里的 mysql 用户 UID 是 999。如果你用绑定挂载把宿主机的 /data/mysql 挂到 /var/lib/mysql，而 /data/mysql 属主是 root，那么 MySQL 初始化时就会失败。解决办法很简单，把目录属主改成 999：

bash复制chown -R 999:999 /data/mysql

如果你的容器镜像是自定义的，方法也一样，先查清楚进程的用户 UID，再 chown -R 对应的目录。查 UID 可以进容器执行 id 命令，或者在 Dockerfile 里构建时把 RUN useradd 的 UID 固定下来，避免每次构建 UID 漂移。

还有一个跟权限捆绑的坑是 SELinux。在 RHEL/CentOS 这类默认开启 SELinux 的系统里，盲目给容器挂载宿主机目录会遇到 Permission denied。这时的解法是给挂载参数加上 :Z 或 :z 后缀：

bash复制docker run -v /data/mysql:/var/lib/mysql:z ...

:z 表示共享标签，适合多个容器同时挂载同一目录；:Z 表示私有标签，只允许当前容器使用。加了标签后 SELinux 就会放开对该目录的访问限制。

5. 常见故障排查实录：这些坑我全踩过

5.1 挂载后目录变空，数据“消失”了

这是新手最容易遇到、也最吓人的问题之一：你用 -v mydata:/usr/share/nginx/html 挂载了一个空卷，然后发现 Nginx 首页 403 了，原本镜像里自带的 index.html 不见了。

原因不是数据被删了，而是被“屏蔽”了。挂载的本质是让宿主机上卷的目录取代容器里的目录位置。当空卷挂到 /usr/share/nginx/html 上时，容器里的这个路径立刻变成了空目录，镜像层里原有的文件就被“盖住”了，看起来像是消失了。其实镜像层里的文件还在，只是挂载点把它挡住了。

解决方法要看你的意图。如果挂载的目录需要有初始数据，常见的办法是分两步走：先用临时容器把镜像里的默认文件复制到卷里，再正式启动服务。

bash复制# 先用临时容器把镜像默认文件复制到卷里
docker run --rm -v mydata:/data alpine cp -r /usr/share/nginx/html/. /data/
# 再启动业务容器
docker run -d --name web -v mydata:/usr/share/nginx/html nginx:latest

这个过程很多人会漏掉，所以我现在遇到“挂载后功能不对”的问题，第一反应就是检查卷里有没有初始数据，别再猜什么镜像坏了之类的。

5.2 容器启动就失败：路径冲突与卷占用

容器启动失败的原因很多，跟卷相关的主要有两类。

第一类是路径冲突。挂载目标目录如果正好是镜像中一个关键目录，容器内进程写不进去，启动自然就挂了。比如某服务启动时要往挂载目录里写配置，但你把它挂成了只读（:ro），那进程会报 read-only file system 退出。排查这种问题，核心步骤就是看日志：

bash复制docker logs <容器名>

能看到具体是哪个文件写失败、是权限问题还是只读问题，对症下药。

第二类是旧的卷里有“残留状态”。比如 MySQL 容器上次非正常停止，卷里的 ib_logfile、ibdata1 等文件可能已经处于不一致状态。重新挂载同一个卷启动时，InnoDB 初始化报错。应对方法是先备份卷，再把卷里跟日志相关的文件移走，让它重建日志。这类问题没有万能公式，但好在错误日志会给出明确的方向。

我还想提醒一个慢性的坑：卷被多个容器共享时，文件锁和并发写会导致两边数据互相覆盖。Docker 本身不限制多个容器挂同一个卷，数据库这类服务如果被两个实例同时打开，数据损坏的概率极高。所以数据库卷通常只允许一个实例挂载，扩容要依赖数据库自身的主从复制，而不是同时挂同一个卷。

5.3 Docker Desktop 环境下的挂载路径与性能

在 Windows 或 macOS 上用 Docker Desktop，卷的实际行为跟纯 Linux 环境有差别，这个不搞清楚，排查问题会绕很多弯路。

Docker Desktop 默认是用虚拟机（早期是 Hyper-V，现在多半是 WSL2）跑 Linux 容器，所谓“宿主机路径”，其实是虚拟机或 WSL2 发行版里的路径，不是 Windows 的 C:\Users\...。你用 docker volume inspect 看到的 Mountpoint，是虚拟磁盘里的路径，Windows 资源管理器里直接访问不到。想确认卷内容，最稳妥的方式还是起一个 alpine 容器进去看：

bash复制docker run --rm -v mydata:/data alpine ls -la /data

绑定挂载时路径写法也要注意。Windows 下一般可以这样：

bash复制docker run -v D:/data:/app ...

或者写成：

bash复制docker run -v //d/data:/app ...

不同版本对 Windows 路径的解析规则略有差异，遇到启动报错先怀疑路径格式。而且从 Windows 文件系统挂载目录到容器里访问，跨文件系统层的性能损耗非常大，大量小文件读写时格外明显。所以我在 Docker Desktop 里跑数据库，一律用命名卷，不会为了方便直接绑 Windows 目录，否则 MySQL 在这种挂载方式下性能会低到让人怀疑人生。

另外很多人装完 Docker Desktop 后遇到启动失败，提示跟虚拟化支持有关，这通常不是卷的问题，而是 BIOS 里的虚拟化开关没打开。这类问题比较常见，排查顺序一般是：检查 BIOS 虚拟化是否开启、确认 WSL2 是否安装、最后看 Docker Desktop 的日志。

6. 完整实战：用数据卷跑 MySQL 8.0，删容器数据不丢

6.1 准备工作

前面讲的都是理论和方法，最后我用一个最经典的生产案例——MySQL 8.0 数据卷持久化——完整演示一遍从启动到验证的过程。现在就开始。

先拉镜像并创建卷：

bash复制docker pull mysql:8.0
docker volume create mysql_data
docker volume inspect mysql_data

这里有一个隐藏细节值得解释：MySQL 官方镜像的 Dockerfile 里声明了 VOLUME /var/lib/mysql。这个声明的意思是，即使用户没有主动挂载卷，Docker 也会自动为这个路径创建一个匿名卷。所以很多人说“我明明没配卷，删了容器数据也在”，其实是匿名卷在起作用。但匿名卷管理起来很麻烦，所以我们要显式创建自己的命名卷 mysql_data，并挂载到 /var/lib/mysql，覆盖掉镜像默认的匿名卷行为。

6.2 启动 MySQL 并写入测试数据

用刚创建的命名卷启动一个 MySQL 容器：

bash复制docker run -d \
  --name mysql-test \
  -e MYSQL_ROOT_PASSWORD=root123 \
  -e MYSQL_DATABASE=testdb \
  -p 3306:3306 \
  -v mysql_data:/var/lib/mysql \
  mysql:8.0

启动后先看日志，确认初始化完成。第一次启动要做初始化，可能需要十几秒到几十秒：

bash复制docker logs -f mysql-test

看到类似 ready for connections 的日志，就说明启动完成了。接着进入容器写一点测试数据：

bash复制docker exec -it mysql-test mysql -uroot -proot123

在 MySQL 里执行：

sql复制CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(100) NOT NULL
);

INSERT INTO users (name) VALUES ('docker'), ('volume');

退出后，用 docker volume inspect mysql_data 查看卷信息，可以观察到卷目录里已经多出了 MySQL 的数据文件。如果你在 Linux 环境，直接看 /var/lib/docker/volumes/mysql_data/_data 目录，会看到 ibdata1、ib_logfile0、testdb 等文件，这些就是 MySQL 真正落盘的数据。

6.3 删除容器重建，验证数据完整性

接下来就是重头戏：把容器删了，再重新启动一个容器，看数据还在不在。

bash复制docker stop mysql-test
docker rm mysql-test

注意，这里用的是 docker rm 而不是 docker rm -v。-v 参数会在删除容器的同时，把关联的匿名卷也删掉，但我们这里是命名卷，默认不会删。不过养成习惯，删容器时不带 -v 永远更安全。

然后重新启动一个全新容器，挂载同一个卷：

bash复制docker run -d \
  --name mysql-test-new \
  -e MYSQL_ROOT_PASSWORD=root123 \
  -p 3306:3306 \
  -v mysql_data:/var/lib/mysql \
  mysql:8.0

启动完成后，进入新容器查询刚才的数据：

bash复制docker exec -it mysql-test-new mysql -uroot -proot123 -e "SELECT * FROM testdb.users;"

如果一切正常，你会看到 docker 和 volume 两行数据原封不动躺在数据库里。这就完成了最核心的验证：容器身份变了，但卷没有变，数据跟着卷走。

最后清理现场。当你确认数据不再需要时，再删除卷。删除卷必须显式执行：

bash复制docker stop mysql-test-new
docker rm mysql-test-new
docker volume rm mysql_data

这个操作删除后数据无法恢复，务必确认卷里没有需要保留的数据再下手。如果只是暂时不用，保留卷和停止的容器也没关系，下次直接用同一卷启动就能接上。

我在实际使用中，除了数据库，备份文件、上传目录、Nginx 静态资源这些“删了会肉疼”的数据，全部用命名卷保存；开发时改代码、看日志这种高频操作，才用绑定挂载。数据卷的底层原理并不复杂，很多问题都是因为没有搞懂卷和容器生命周期的关系。你只要记住一句话：容器可以随意删，但卷是你真正的数据家底，挂错卷、删错卷才是事故的根源。