上周有个朋友半夜找我，说他服务器重启后，跑在 Docker 里的 MySQL 数据全没了。我第一反应是问他当时怎么启动的容器，结果发现他直接用了docker run -d mysql:8.0这类最基础的写法，数据库文件全写在了容器可写层里。容器一删或宿主机一重启，状态说没就没。这不是个例，我在社区里见过太多人把容器当虚拟机用，结果数据丢了、性能拉了、磁盘满了，最后排查下来，问题几乎都出在存储这一层：Docker 存储驱动没选对、数据卷没挂好、持久化没落到卷上、IO 路径拉得太长。
这篇东西我不会给你念官方文档，而是把存储驱动和数据卷这两块掰开揉碎讲一遍：先讲清楚容器为什么“留不住数据”，再讲存储驱动对读写性能的影响，然后带你从一条docker run命令到 docker compose 完整落地数据卷，最后把 MySQL、Redis 这类常见应用的持久化与性能优化实操方案直接列出来。适合刚把 MySQL/Redis 装进容器的新手，也适合已经跑了一段时间、但时不时遇到“数据丢、写入慢、磁盘爆”的老手。
1. 先弄清痛点在哪儿：容器可写层为什么留不住数据
很多人在第一次接触 Docker 时，会下意识把容器当成一台轻量虚拟机：在虚拟机里装 MySQL，数据写在虚拟磁盘里，关机重启数据还在。但容器不是这样工作的。Docker 容器的文件系统由镜像层和可写层构成，理解这个基本盘，后面所有关于持久化和性能的事才讲得通。
1.1 镜像分层与写时复制的基本盘
一个 Docker 镜像是一堆只读层叠加出来的，每一层对应 Dockerfile 里的一条 COPY、RUN 等指令。比如你拉一个 mysql:8.0，它内部可能叠了几十层，每一层都记录着文件系统的一部分变更。容器运行时，Docker 在镜像层之上再挂一个可写层，所有对文件的修改都先落到这个可写层里。
这个机制叫“写时复制”（Copy-on-Write，COW）。读一个文件时，Docker 会从上往下逐层查找；改一个文件时，如果目标文件在下面的只读层，需要先把它复制到可写层再修改。问题就出在这：容器运行期间产生的所有数据，数据库的 binlog、redo log，Redis 的快照，业务日志，全都堆在这个薄薄的可写层里。容器一旦被docker rm删除，可写层连同里面所有数据一并销毁。这就是“容器留不住数据”的根本原因。
有人会问，那我容器不删，数据是不是就安全了？也不是。宿主机崩溃、磁盘故障、或者你执行了docker system prune之类的清理操作，可写层都很脆弱。更重要的是，可写层从来不应该是业务数据的归宿，它只是运行时临时状态的家。
1.2 数据落在可写层的三个典型后果
把数据库这类强持久化应用直接跑在可写层上，通常会遇到三个问题，我基本上在排障时都见过：
第一是数据丢失。容器重建、宿主机重启、误删容器，操作系统的状态全部归零。很多新手中的新手会在“容器删了数据还在吗”这个问题上栽跟头，答案很残酷：默认情况下，删容器等于删数据。
第二是性能不稳定。可写层的数据最终也要落到宿主机磁盘上，但因为有了写时复制这一层逻辑，频繁修改大文件时会有额外的复制开销。实测在容器可写层里跑 MySQL，和小数据量时看不出差距，数据一多、写入一频繁，fsync 延迟明显升高，整体写入吞吐掉一截。
第三是磁盘空间失控。可写层里积累的日志、临时文件、数据库碎片，在docker system df里看到的就是“可写层”那块占用，而且很难单独清理。你删了容器，这些空间不一定会立刻释放，残留的 build cache 和悬空层会越堆越多。
所以结论很简单：凡是要长期保留的数据，一律放到数据卷（volume）或绑定挂载（bind mount）里，而不是写进容器可写层。这个原则没有例外。
2. Docker 存储驱动选型：为什么多数场景默认 overlay2 就够了
存储驱动是 Docker 用来管理镜像层和容器可写层之间映射关系的底层引擎。不同驱动背后的文件系统机制不一样，直接影响读写性能。这也是标题里“存储驱动”这部分要解决的核心问题。
2.1 overlay2 的工作流程与性能关键点
现代 Linux 环境下，Docker 默认使用 overlay2，它基于内核的 OverlayFS 实现，把镜像层作为 lowerdir、容器可写层作为 upperdir，挂载出一个 merged 目录给容器看到完整文件系统。
这个设计让镜像层可以在多个容器之间共享，同样的基础镜像，十个容器共用一份只读层，内存和磁盘都省。写文件时，OverlayFS 做 copy-up：把底层文件复制到可写层再修改。对数据库这类有小量随机写、大量 fsync 的工作负载，copy-up 只在文件第一次被修改时发生，真正频繁的写入还是直接落在 upperdir 对应的宿主机目录里，所以 overlay2 的额外开销其实有限。
但如果底层文件系统不支持 d_type（目录项文件类型），overlay2 会退化成索引模式，读取目录和元数据时性能会明显打折。检查方法很简单：
docker info | grep -A5 "Storage Driver"如果看到Backing Filesystem: ext4或xfs，通常没问题；如果是网络文件系统或某些老式文件系统，就要留个心眼。我自己在 xfs 格式的老 CentOS 上遇到过 overlay2 跑得慢的情况，后来确认是 d_type 支持有问题，换成 ext4 后写入延迟立刻恢复正常。
2.2 不同存储驱动怎么选，一张表讲清楚
不是所有环境都适合 overlay2。早期 Docker 用过 aufs、devicemapper，后来在特定文件系统上还支持 zfs、btrfs 等。它们各有适用场景，但也各有代价。
| 存储驱动 | 底层依赖 | 优点 | 典型问题 | 适用场景 |
|---|---|---|---|---|
| overlay2 | ext4/xfs，支持 d_type | 默认驱动，社区验证充分，镜像共享好 | 依赖内核版本，老内核上性能打折 | 绝大多数生产环境 |
| aufs | 需要内核支持 aufs | 老牌驱动，早期历史长 | 未进入主线内核，新发行版基本没了 | 不推荐，过度方案 |
| devicemapper | 需要配置 thin pool | 曾经是 RHEL 默认 | 配置复杂，loop-lvm 模式性能极差 | 应避免，历史包袱 |
| btrfs/zfs | 对应文件系统 | 自带快照、压缩能力 | 和 Docker 层共用文件系统特性，资源占用偏高 | 特殊存储方案，比如需要文件级快照时 |
从我接触过的团队看，绝大多数项目都用不着换驱动，先把 overlay2 调好、把数据卷挂对，性能问题就解决一大半了。那些一上来就折腾 zfs、btrfs 的，反而常常在运维层面给自己挖坑。
2.3 判断当前环境存储类型的两个命令
你不需要背驱动特性，但至少要知道当前环境用的是啥、底层文件系统是啥，排障时心里有数。
docker info重点看 Storage Driver、Backing Filesystem、Docker Root Dir 这三行。我每次接手一台陌生的服务器，都会先跑这个命令，几秒钟就能判断后面调优方向。另外一个常见问题是，在 Docker Desktop 这种跑在虚拟机里的环境中，底层文件系统是虚拟机里的虚拟磁盘格式，宿主机和容器之间的文件路径可能不是你以为的那个。
3. 数据卷、绑定挂载和 tmpfs：三种持久化方式怎么选
数据要持久化，就绕不开挂载（mount）。Docker 里常见的有三条路：绑定挂载（bind mount）、数据卷（volume）、tmpfs 挂载。三者性格完全不同，选错了不是丢数据就是权限噩梦。
3.1 三种挂载方式的核心差异
| 对比维度 | bind mount | volume（数据卷） | tmpfs mount |
|---|---|---|---|
| 数据位置 | 宿主机任意目录 | Docker 管理的 /var/lib/docker/volumes/ 下 | 容器内存 |
| 由谁管理 | 宿主机管理员 | Docker daemon | Docker daemon |
| 宿主机共用 | 是，路径清晰 | 不推荐直接改目录内容 | 否 |
| 容器删除后数据 | 保留 | 默认保留（除非用 --rm 且无卷） | 消失 |
| 主要场景 | 开发热加载、日志收集 | 数据库数据、配置文件、跨容器共享 | 临时缓存、敏感凭据 |
bind mount 最直观，比如开发时把宿主机项目目录挂进容器，改代码即时生效，不用重新构建镜像。但它的权限边界模糊：宿主机目录的 uid/gid 直接暴露给容器，容器里进程如果以 root 跑，等于给了宿主机目录相当大的写入能力，这在生产环境里要想清楚。
volume 是官方推荐的首选。它由 Docker 统一管理，放在 Docker Root Dir 下的 volumes 子目录里，跨机器迁移、备份都很方便。更关键的是，官方镜像里用VOLUME指令声明的目录，默认就是给你挂数据卷准备的，比如 mysql 的/var/lib/mysql、redis 的/data。你只要挂上卷，容器删掉再重建，数据还在。
tmpfs 挂载则完全是内存盘，写入速度极快，但重启即失。适合放临时文件、session、敏感令牌这类“不落地”的数据。我一般给临时计算任务用，而不是存业务数据。
3.2 命名卷在宿主机上的真实目录结构
在 Linux 上创建一个命名卷后，它的数据会落在/var/lib/docker/volumes/卷名/_data。比如：
docker volume create mysql-data docker inspect mysql-data你会看到它的 Mountpoint 指向/var/lib/docker/volumes/mysql-data/_data。这地方需要注意：它本质是宿主机上的普通目录，但你不应该直接用宿主机路径去读写卷里的文件，尤其是数据库类卷。我见过有人把/var/lib/docker/volumes/mysql-data/_data里的数据拷出来恢复，操作没错，但一旦 Docker 使用的文件系统锁和缓存机制介入，直接改文件容易导致数据不一致。正确做法是用临时容器做备份和恢复，后面讲。
3.3 容器间共享与权限踩坑
有的场景需要多个容器访问同一份数据，比如 Nginx 和 PHP-FPM 共用静态文件目录，或者日志采集容器读业务容器的日志文件。bind mount 最简单，宿主机上一个目录挂给两个容器就行；volume 也能做到，把同一个命名卷挂给多个容器。
但权限问题是重灾区。bind mount 宿主机的目录如果归属 root，容器内进程以 www-data 用户运行时可能没有写权限。MySQL 镜像更麻烦：官方 mysql 镜像首次初始化数据目录时，必须保证目录归属 mysql 用户，如果 bind 挂载的宿主机目录归属不对，初始化直接失败。我常用的技巧是先创建一个空目录，然后临时用--user参数跑一个只做 chown 的容器修正归属，再正式启动数据库容器。
chown -R 999:999 /data/mysql操作前务必确认镜像里 mysql 用户的 uid/gid，MySQL 官方镜像通常是 999，不同版本可能不一样，以docker exec <容器名> id mysql的实际输出为准。
4. 数据卷实操：从一条命令到 compose 全面接管
理解了原理，接下来就是直接能抄的实操。我不会故作高深，下面这些都是我自己在项目里用过的写法。
4.1 创建卷与挂载的基础命令
先创建一个命名卷：
docker volume create mysql-data启动容器时挂载，两种写法等价，建议优先用--mount，可读性更好：
docker run -d \ --name mysql8 \ -v mysql-data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=yourpass \ mysql:8.0或者：
docker run -d \ --name mysql8 \ --mount type=volume,source=mysql-data,target=/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=yourpass \ mysql:8.0绑定挂载也经常用，比如把宿主机配置目录挂给容器：
docker run -d \ --name nginx \ -v /etc/nginx:/etc/nginx:ro \ -v /www/html:/usr/share/nginx/html \ nginx:1.25:ro表示只读，防止容器内进程误改宿主机配置。这条建议养成习惯，能用只读就用只读，少一类安全隐患。
4.2 docker compose 中声明数据卷的标准写法
现在跑应用我基本都用 compose 管。compose 里定义卷非常清晰，服务里用volumes列出挂载关系，文件底部用顶层volumes声明卷名：
services: mysql: image: mysql:8.0 container_name: mysql8 restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: appdb volumes: - mysql-data:/var/lib/mysql - ./mysql/conf.d:/etc/mysql/conf.d:ro ports: - "3306:3306" volumes: mysql-data:docker compose up -d后，compose 会自动创建名为项目名_mysql-data的卷。这里有个坑：如果你之前在单独docker run里手动创建过mysql-data，compose 因为命名空间规则不会自动复用，会另外建一个卷，导致“数据好像不见了”。解决办法是给卷指定名称：
volumes: mysql-data: name: mysql-data这样 compose 就会直接使用已存在的命名卷，数据不会丢。这是我在迁移老容器到 compose 时踩过的实坑。
常用项目里，Kodbox（网盘）、青龙（定时任务）、GitLab 这类应用都需要挂多个卷。以 Kodbox 为例，数据目录、配置目录、临时目录分别挂载：
services: kodbox: image: kodbox/kodbox:latest volumes: - kodbox-data:/var/www/html - kodbox-config:/etc/nginx/conf.d ports: - "8080:80" volumes: kodbox-data: kodbox-config:4.3 卷的备份、恢复与迁移
卷数据不能直接拷贝宿主机目录，至少不该作为首选。我当然知道很多人会直接 tar/var/lib/docker/volumes/mysql-data/_data，速度快，但我碰到过一次因为容器还在写数据、直接 tar 出来的备份不一致的情况，所以现在都用临时容器做一致性备份。
备份一个命名卷，最稳妥的写法：
docker run --rm \ -v mysql-data:/data \ -v /backup:/backup \ alpine tar czf /backup/mysql-data.tar.gz -C /data .恢复时也是一样的思路，先把 tar 解压回卷数据目录：
docker run --rm \ -v mysql-data:/data \ -v /backup:/backup \ alpine tar xzf /backup/mysql-data.tar.gz -C /data注意恢复前一定要先停掉正在用这个卷的容器，否则数据目录被占用、文件锁冲突，解压完你都不知道哪些文件是新的哪些是旧的。迁移到另一台机器时，把 tar 包拷过去再执行同样的恢复命令就行，卷的名字建议保持一致，避免配置改动。
5. 性能优化实战：让 MySQL 和 Redis 在容器里跑得又快又稳
说到性能优化，很多人第一反应是调容器 CPU/memory 限制，但我实测下来，存储层面的优化往往收益更大。数据路径一乱，配置再好也白搭。
5.1 耗时瓶颈通常不在存储驱动而在数据路径
一个常常被忽略的事实：绑定挂载和命名卷本质上都是直接访问宿主机目录，并不经过 overlay2 的可写层。也就是说，真正影响性能的，不是存储驱动本身，而是你把数据放在了哪条路径上。
容器内写文件有三个可能去处：一是 overlay2 可写层，写入可能触发 copy-up，大文件频繁修改时延迟明显；二是 volume，直接落到宿主机文件系统，性能和裸机目录非常接近；三是 tmpfs，写内存，最快。数据库这个级别的写入，永远应该走第二条路。
我做过一次不算严谨的对比：同样跑 MySQL 的 sysbench 写测试，小表数据量下容器可写层和 volume 的差距在 10% 以内，但数据量涨到 10GB、同步刷盘开启时，可写层的延迟明显增大，偶尔出现明显抖动。这其实是 copy-up 和碎片化在叠加。结论就是：数据库数据目录必须用 volume，别让写时复制耽误你。
5.2 MySQL 容器写盘性能优化实录
一个完整可靠的 MySQL 容器，至少要做到三件事：数据卷挂载、二进制日志限流、日志驱动收敛。
首先启动 MySQL 时挂载数据卷：
docker run -d \ --name mysql8 \ --mount type=volume,source=mysql-data,target=/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=yourpass \ mysql:8.0其次是 MySQL 自身的刷盘策略。默认配置下，innodb_flush_log_at_trx_commit=1每次事务提交都强制刷盘，安全但慢。如果你能接受极端情况丢 1 秒事务，改成2，性能提升非常明显。比如在配置文件中添加：
[mysqld] innodb_flush_log_at_trx_commit = 2 innodb_buffer_pool_size = 2G这两个参数在容器里同样生效，前提是你把配置文件挂进去了。例子：
docker run -d \ --name mysql8 \ --mount type=volume,source=mysql-data,target=/var/lib/mysql \ --mount type=bind,source=/etc/mysql/conf.d,target=/etc/mysql/conf.d,ro \ mysql:8.0然后是日志驱动。Docker 默认 json-file 日志驱动，如果没限制大小，MySQL 的错误日志、慢查询日志会滚成巨无霸，既拖累宿主机 IO，也占磁盘。启动容器时加日志参数：
docker run -d \ --name mysql8 \ --log-driver=local \ --log-opt max-size=10m \ --log-opt max-file=3 \ mysql:8.0local驱动本身是给 Docker 内部日志用的，格式紧凑，性能比 json-file 好，配合滚动策略，日志再也不会无限膨胀。生产环境里这是我最常用的组合。
5.3 Redis 持久化机制与卷配合
Redis 的持久化常见有 RDB、AOF 两种机制。RDB 是定时快照，恢复快但可能丢数据；AOF 记录每一条写命令，数据安全但文件大。现在主流是混合持久化：AOF 重写时生成 RDB 格式的基线，再叠加增量命令。无论哪种，数据文件都默认落在/data目录，官方镜像也把/data暴露成 VOLUME。所以你只需要挂一个卷：
docker run -d \ --name redis7 \ --mount type=volume,source=redis-data,target=/data \ redis:7-alpine --appendonly yes启动参数里--appendonly yes开启 AOF，appendfsync everysec每秒刷盘一次，这是性能和安全的常见平衡点。如果要更稳，可以设always，但写入延迟会明显上升，我一般只在库存、交易类场景里用。Redis 的 AOF rewrite 会频繁产生临时文件，一旦卷所在磁盘空间不足，rewrite 失败还可能触发 Redis 停止写入。所以挂卷之后要留出至少一倍数据集大小的余量，或者定时清理rdb/aof历史文件。
5.4 容器日志与宿主机层面的隐藏开销
容器运行时还有一类常被忽略的 IO 消耗：Docker 日志驱动。默认 json-file 驱动不仅膨胀快，写入也是串行的，日志量大的容器会拉高整体 CPU 和 IO 压力。我从去年开始把大多数容器的日志默认切到local驱动，或者至少限制 max-size 和 max-file，实测对高并发写入场景帮助明显。
宿主机层面，如果跑的是数据库容器，务必保证/var/lib/docker挂载在 SSD 上，而不是机械盘或网络盘。有人问我跑 20 个容器为什么磁盘 IO 那么高，我一看，Docker Root 落在了一个旧 NAS 上，那就算存储驱动调出花来，底层的随机写性能也救不回来。这一步比任何调参都实在。
6. 常见问题与排查技巧实录
最后这部分，我把日常被问得最多的问题集中列一下，很多都是热词里反复出现的“老朋友”：docker 权限错误、virtualisation support 检测不到、镜像下载慢、docker 网络不通、磁盘占满。
6.1 启动失败与权限报错
如果你在 Linux 上用非 root 用户执行 docker 命令，报permission denied while trying to connect to the Docker daemon socket，大概率是用户不在 docker 组。解决办法：
sudo usermod -aG docker $USER newgrp docker然后重新登录终端。重试前记得确认 docker 守护进程在运行：
systemctl status dockerWindows/macOS 上 Docker Desktop 启动时报virtualisation support wasn't detected这类错误，通常是虚拟化没开或 WSL2 没启用。先去 BIOS 把 Intel VT-x / AMD-V 打开，再检查“启用 Windows 虚拟机监控程序平台”和“适用于 Linux 的 Windows 子系统”这两个功能是否勾选。这个问题在 Windows 11 上尤其常见，装完 Docker Desktop 起不来，十有八九是虚拟化相关功能没开全。
6.2 镜像下载慢与网络不通的处理
镜像拉取慢是几乎所有新手都会碰到的事。我推荐的方法很朴素的：
- 优先使用可信的公共容器镜像服务，或配置 registry-mirror 镜像加速。
- 给镜像打上明确 tag，不要只用 latest，减少无谓的层下载。
- 内网环境就用 registry 私有仓库，把常用镜像 upload 到内网再分发。
Docker 网络不通的问题，典型现象是容器访问不了外网，或者容器之间互相 ping 不通。排查顺序是先看容器网络模式：
docker network ls docker inspect <容器名> | grep -A20 "Networks"默认 bridge 网络下，容器通过 NAT 访问外网；如果你手动--network host或自定义 network，要确认宿主机的防火墙规则和 IP 转发是否开启。容器间互通用自定义 bridge 网络，比如docker network create app-net，然后把相关容器都加入这个网络，用服务名或容器名互相访问，比我以前用--link灵活多了。
6.3 磁盘占满与孤儿卷清理
跑一段时间后磁盘被 Docker 掏空，绝对算是高频事故。先看占用：
docker system df这个命令会列出镜像、容器、本地卷、构建缓存各占多少。清理时按需操作：
# 清理悬空镜像、停止的容器、无用网络 docker system prune # 连构建缓存一起清 docker system prune -a # 清理无主数据卷 docker volume prune特别说一句，docker system prune默认不会删数据卷，因为卷里的可能是你的宝贝数据。但如果你明确知道哪些卷没用了，docker volume prune一次清掉最省事。身边很多人在“容器删了但空间没释放”问题上抓狂，多半是没意识到构建缓存和旧镜像还在占地方，先把docker system df这个体检技能用起来，问题就能看明白一大半。
6.4 数据卷删不掉与误删预防
试图删除一个还被容器使用的卷时，Docker 会直接拒绝并提示卷正在被使用。这其实是保护机制，但反过来也带来一个困扰：你不会总是记得哪个卷还被哪个容器占用。这时用：
docker ps -a --filter volume=卷名查出占用容器。如果容器已经不在，而卷还挂着文件，docker volume prune也只删无主卷，确认没错再手动删：
docker volume rm 卷名误删预防这块，我养成了一个习惯：所有带有明显业务属性的卷都用命名卷，并用项目名做前缀，例如app-mysql-data、app-redis-data。匿名卷很难追溯，一旦容器被删，匿名卷虽然还在宿主机上，但你很难知道它是谁的。给卷起好名字，也算是一种成本极低的运维规范。
另外一个建议是，生产环境执行任何 prune 之前，先做一次卷备份，哪怕只是几分钟前打好的 tar 包，也比事后找人恢复强。我见过太多半夜三点找人拉数据恢复的场面，几乎所有情况都源于“我以为没影响”和“我以为备份了”。
我自己在实际操作里的体会是，Docker 存储这块不需要什么花活：存储驱动默认 overlay2 别乱换，数据卷老老实实挂上，日志限流开好，备份演练做一次。这些做好之后，你才会真正觉得容器是可靠的运行环境，而不是一个随时会丢数据的高级玩具。如果你正打算把 MySQL、Redis 这类应用迁到 Docker，或者已经被丢数据、慢写入折磨过，不妨按这篇文章重新梳理一遍你的卷和存储路径，能少走太多弯路。
