为什么不能只用 docker run -v /host/path:/var/lib/mysql
直接挂载宿主机目录看似简单，但容易引发权限、SELinux、文件系统兼容性三重问题。MySQL 容器内以
mysql用户（UID 999）运行，而宿主机目录若属 root 或其他 UID，会导致
mysqld启动失败并报错
Can't start server: Bind on unix socket: Permission denied。SELinux 启用时（如 CentOS/RHEL），默认阻止容器写入挂载路径，需额外加
:z或
:Z标签。另外，ext4 和 XFS 对 fsync 行为差异可能影响崩溃恢复可靠性。 始终用
chown -R 999:999 /host/mysql-data预置目录权限 在 SELinux 环境下，挂载时必须加
:z（多容器共享）或
:Z（独占）后缀，例如
-v /data/mysql:/var/lib/mysql:Z避免挂载到 NFS 或 CIFS 共享目录——MySQL 不支持网络文件系统作为数据目录
推荐用命名卷（named volume）而非绑定挂载
命名卷由 Docker 管理，自动处理权限、SELinux 上下文和文件系统优化，是官方文档明确推荐的方式。它天然隔离数据生命周期，与容器解耦，迁移、备份、复用更安全。
创建专用卷：docker volume create mysql-data启动时指定：
docker run -v mysql-data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123 mysql:8.0查看卷位置：
docker volume inspect mysql-data，实际路径类似
/var/lib/docker/volumes/mysql-data/_data备份时仍需进入容器执行
mysqldump，不能直接拷贝
_data目录——因 InnoDB 文件处于活跃状态，直接复制会导致不一致
my.cnf 配置必须显式设置 datadir
并校验生效
Docker MySQL 镜像默认
datadir是
/var/lib/mysql，但一旦你通过挂载或卷覆盖了该路径，必须确保配置文件中
datadir值与挂载目标完全一致，否则
mysqld会尝试在旧路径初始化或读取数据，导致启动卡死或报错
InnoDB: Unable to lock ./ibdata1 error。 自定义配置应挂载为
/etc/mysql/conf.d/my-custom.cnf（优先级高于默认配置） 文件内容必须包含：
[mysqld] datadir = /var/lib/mysql socket = /var/run/mysqld/mysqld.sock启动后验证：
docker exec -it mysql-container mysql -uroot -p -e "SHOW VARIABLES LIKE 'datadir';"，输出必须与挂载路径一致 不要修改镜像内置的
/etc/mysql/my.cnf，它会被
conf.d/下文件覆盖，且易被镜像更新覆盖
备份与恢复不能跳过容器内逻辑导出
即使用了命名卷或绑定挂载，直接宿主机拷贝
ibdata1、
ib_logfile*、表空间文件等属于危险操作。InnoDB 的 redo log、buffer pool、doublewrite buffer 等状态未落盘时，文件副本无法保证一致性。唯一可靠方式是在容器运行时调用
mysqldump或
mysqlpump，或使用
mysqlbackup（企业版）。 日常备份示例：
docker exec mysql-container sh -c 'exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD"' > backup.sql恢复前先确认目标库为空或已停服，再执行：
docker exec -i mysql-container sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"' < backup.sql大库场景建议启用
--single-transaction和
--routines，避免锁表并导出存储过程 不要依赖
docker commit保存数据状态——它只保存容器层，不包含卷或挂载内容 MySQL 持久化真正难的不是挂载命令怎么写，而是理解数据一致性边界在哪：文件系统层的“存在”不等于数据库层的“可用”。哪怕路径对了、权限有了、配置加载了，没做逻辑导出的备份，就只是幻觉。
