docker环境下mysql备份恢复最轻量可控的方式是docker exec + mysqldump逻辑备份，需确保--single-transaction、utf8mb4编码及库存在，禁用明文密码和容器内binlog主备。
直接用 mysqldump 备份、mysql 命令恢复，是 Docker 环境下最轻量、最可控的方式；物理拷贝 data 目录在容器中反而容易出错，不推荐日常使用。
docker exec + mysqldump 是最稳妥的备份方式
容器内没有 cron 或后台守护进程，所以不能依赖“自动触发”，必须显式执行命令。关键点在于：用户权限、密码传递、字符集、事务一致性。
-
mysqldump必须在容器内部运行，不能在宿主机直连容器端口后调用（否则无法保证--single-transaction对 InnoDB 的生效） - 避免在命令行里明文写密码：用
-p让其交互输入，或提前配置~/.my.cnf（需挂载进容器） - InnoDB 表务必加
--single-transaction，否则可能导出不一致快照；MyISAM 则必须配合--lock-all-tables - 导出时建议显式指定
--default-character-set=utf8mb4，防止乱码，尤其含 emoji 或中文字段时
示例命令：
docker exec -i mysql-container sh -c 'exec mysqldump -u root -p --single-transaction --routines --triggers --default-character-set=utf8mb4 mydb' > /backup/mydb_$(date +%Y%m%d).sql
恢复前必须确保目标库存在且编码匹配
MySQL 容器启动后默认不创建业务库，mysql 命令导入时若库不存在会报错：ERROR 1049 (42000): Unknown database 'mydb'。这不是权限问题，是结构缺失。
- 先用
docker exec进入容器，手动执行CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 再导入：
docker exec -i mysql-container sh -c 'exec mysql -u root -p mydb' - 如果备份文件里已有
CREATE DATABASE语句，也要确认其CHARACTER SET和目标库一致，否则表字段可能变成latin1_swedish_ci
docker cp 不是唯一路径，但要注意文件权限和大小限制
从容器复制备份文件到宿主机，docker cp 最常用，但它有隐性约束：
- 容器内路径必须是绝对路径，且文件需已生成（
mysqldump要写入/tmp或挂载卷，不能写/proc或/sys下） - 大文件（如 >2GB）在某些 Docker 版本中可能因内存缓冲区不足导致
cp中断，此时建议改用挂载卷（-v /host/backup:/backup）让mysqldump直接写宿主机 -
docker cp不保留 SELinux 上下文，若宿主机启用了强制访问控制（如 RHEL/CentOS），恢复时可能被拦截
别把二进制日志（binlog）当备份主力
有人试图在容器里启用 binlog 并定期 docker cp 出 mysql-bin.000001，这看似能做增量恢复，但实际风险很高：
- 容器重启或重建后，
server-id可能重置，导致 binlog 事件重复或跳过 - binlog 文件名滚动依赖
mysqladmin flush-logs，而该命令在无 shell 的精简镜像（如mysql:alpine）中常不可用 - 恢复时需用
mysqlbinlog解析并重放，但容器内往往没装这个工具，又得额外构建镜像 - 真正可靠的增量方案应基于外部存储+时间戳标记，而非依赖容器内状态
binlog 更适合作为全量备份后的辅助手段，而不是独立备份机制——它的脆弱性远高于一个可验证的 .sql 文件。
