docker-compose部署MySQL时Volume数据重复存储的配置疑问

你观察到的“两处存储相同MySQL数据”不属于异常，并非Docker自动生成了两份独立副本，这是Docker本地卷绑定宿主机路径后的正常路径映射表现。

• 两个路径下的文件指向同一份物理存储，不存在独立的数据拷贝：Docker为命名卷预留的默认挂载点/var/lib/docker/volumes/myapp_mysql-data/_data，在配置o: bind的驱动参数后，会被直接绑定到指定的宿主机真实路径/local/path上。两个路径本质是同一个存储位置的不同访问入口，修改任意路径下的文件，另一个路径的内容会实时同步，磁盘空间仅占用一份。你当前使用的简化bind参数写法是Docker早期版本的兼容配置，虽然可以实现路径绑定，但缺少type参数的显式声明，在部分新版本Docker中可能出现挂载行为不符合预期的问题。
• 可通过简单测试验证：在/local/path目录下创建临时测试文件，立刻去/var/lib/docker/volumes/myapp_mysql-data/_data路径下查看，会看到该文件实时存在，即可排除双副本误判。
• 容易引发“双副本”错觉的真实异常场景：如果命名卷是在未配置bind参数时提前创建、已经向默认Docker卷路径写入了初始化数据，后续修改compose配置加上bind驱动参数后，Docker不会自动迁移已有数据，这时候会出现默认路径留存旧数据、新绑定的自定义路径为空的真实双份独立存储问题，这类场景才需要排查调整。

行业内主流实现逻辑分两类，可根据团队使用习惯选择：

1. 直接使用Bind Mount（最常用、逻辑最直观） #

完全绕过命名卷抽象层，直接在服务的volumes配置中指定宿主机路径与容器内路径的映射关系，不需要在顶层定义独立的命名卷。
调整后的compose核心配置如下：

version: '3.7'

services:
  mysql:
    image: mysql:5.7
    container_name: "mysql"
    ports:
      - "127.0.0.1:3306:3306"
    volumes:
      # 直接映射宿主机自定义路径到容器内MySQL数据目录
      - /local/path:/var/lib/mysql

该方式的优势：

• 存储路径完全透明，不会在Docker默认卷目录下生成对应的虚拟路径，排查磁盘占用时逻辑清晰，不存在两层路径映射的错觉
• 配置简单，不需要额外配置卷驱动参数
• 配置注意事项：映射前需要确保宿主机/local/path目录的权限满足MySQL容器的运行要求（MySQL容器内运行用户UID为999），避免启动时报权限错误。

2. 使用命名卷+Bind驱动（适合需要统一卷管理的场景） #

如果团队习惯通过Docker命名卷统一管理所有持久化存储，可以使用规范的本地卷bind配置替代当前的简化参数写法，配置逻辑为：

version: '3.7'

services:
  mysql:
    image: mysql:5.7
    container_name: "mysql"
    ports:
      - "127.0.0.1:3306:3306"
    volumes:
      - mysql-data:/var/lib/mysql

volumes:
  mysql-data:
    driver: local
    driver_opts:
      type: "none"
      o: "bind"
      device: "/local/path"

这种方式依然会在docker volume inspect的返回结果中看到默认挂载点路径，但实际物理存储完全落在指定的宿主机路径下，不存在独立的双份数据。

内容的提问来源于stack exchange，提问作者Alexandr Sugak