安全复制MySQL数据卷应先停容器，再用alpine镜像tar打包；mysqldump跳过权限表需忽略mysql.user等系统表或仅备份业务库；mysqlpump默认不导出mysql库及存储过程，支持并行提速。
docker run 时挂载的 mysql 数据卷怎么快速复制一份？
直接 cp -r 宿主机上的卷目录风险很高——MySQL 进程可能正写入文件，导致 ibdata1 或 binlog 损坏。真正安全的做法是让 MySQL 自己导出一致快照。
- 先停掉容器：
docker stop mysql-dev，避免写入冲突 - 用
docker run --rm -v mysql_data:/volume -v $(pwd):/backup alpine tar czf /backup/mysql_data_backup.tar.gz -C /volume .打包整个卷（alpine轻量且不含 MySQL 服务，不会干扰数据） - 恢复时解压到新卷目录，再用
docker volume create mysql_clone+tar xzf解到对应路径（注意宿主机上/var/lib/docker/volumes/mysql_clone/_data的属主得是999:999，即 MySQL 容器内 uid/gid）
mysqldump 备份后如何跳过权限表还原到新实例？
开发环境克隆常要保留原库结构但不带用户、存储过程等系统对象，否则 mysqldump --all-databases 会把 mysql 库也 dump 进来，还原时可能覆盖目标实例的 root 密码或触发权限冲突。
- 备份时加
--ignore-table=mysql.user --ignore-table=mysql.db --ignore-table=mysql.tables_priv等关键系统表 - 或者更稳妥：只 dump 业务库，用
mysql -e "SHOW DATABASES" | grep -Ev "^(Database|information_schema|performance_schema|sys|mysql)$"动态获取库名再循环mysqldump - 还原前确认目标实例已初始化完成（
mysqld --initialize后首次启动），否则mysql系统库缺失会导致ERROR 1049 (42000)
用 mysqlpump 替代 mysqldump 有什么实际区别？
mysqlpump 是 MySQL 5.7+ 提供的并行逻辑备份工具，对开发环境克隆更友好，但默认行为和 mysqldump 不同，容易误用。
- 它默认不导出
mysql库，也不导出存储过程、函数、事件——这点比mysqldump更“干净”，适合纯业务数据迁移 - 若需导出存储过程，必须显式加
--include-stored-programs；导出事件加--include-events - 并行导出（
--default-parallelism=4）在 SSD 上能提速 2–3 倍，但小库（ - 不支持
--single-transaction和--lock-tables共存，遇到长事务会卡住，不如mysqldump灵活
从备份恢复时 Unknown collation: 'utf8mb4_0900_ai_ci' 怎么办？
这是 MySQL 8.0 默认排序规则，低版本（如 5.7）不识别，克隆到旧环境时常见。不是编码问题，是服务端不支持该 collation 名称。
- 备份时用
mysqldump --compatible=mysql40强制降级兼容性（但会丢掉部分特性） - 更可控的方式：用
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' backup.sql批量替换（注意别误改字段值里的字符串） - 如果目标实例是 5.7，建议升级或统一用
utf8mb4_general_ci——虽然排序精度略低，但兼容性无死角
最麻烦的其实是权限与 socket 路径错位：克隆后的容器如果没重置 mysql.sock 路径或 skip-networking 开关不一致，连本地 mysql -u root 都会报 Can't connect to local MySQL server。这种细节不跑一遍根本发现不了。
