不是必须，但不加大概率失败；因非交互式终端下 mysqldump 无法读取密码或受 secure_file_priv 限制而报错或卡住。
docker exec 备份 MySQL 数据库必须加 -t 和 -i 吗？
不是必须，但不加大概率失败。MySQL 客户端在非交互式终端下会拒绝执行 mysqldump（尤其启用了 secure_file_priv 或需要密码时），报错类似 mysqldump: Got error: 1045: Access denied for user 或直接卡住无输出。
真实场景中，容器内 MySQL 通常禁用密码明文传参（--password=xxx 不安全且被忽略），依赖交互式 stdin 输入密码——而默认的 docker exec 是非 TTY 模式，stdin 被关闭。
- 加
-t -i强制分配伪终端 + 保持 stdin 打开，让mysqldump能读取密码输入（如果没配-p参数或环境变量） - 更推荐方式：用
-e MYSQL_PWD=xxx环境变量 +--no-tty避免终端依赖，同时禁用交互提示 - 若已用
mysql_config_editor配置了登录路径，则无需密码参数，-t -i可省略
备份命令里 mysqldump 的 --host 应该填 localhost 还是容器名？
填 localhost。在容器内部执行 docker exec 时，localhost 指向当前容器自身，不是宿主机，也不是其他容器——这是关键误区。
你执行的是「进容器、在容器里跑 mysqldump」，所以 mysqldump 必须连本容器的 MySQL 实例（监听 127.0.0.1:3306 或 localhost:3306）。填容器名（如 mysql-db）反而会走 Docker 网络 DNS 解析，连到另一个容器，甚至因网络隔离连不上。
- 确认 MySQL 在容器内监听
127.0.0.1:3306（而非仅0.0.0.0:3306）：查netstat -tlnp | grep :3306 - 如果 MySQL 配置了
bind-address = 127.0.0.1，那--host=localhost是唯一可靠选项 -
--host=127.0.0.1和--host=localhost行为不同：前者走 TCP，后者可能走 socket（取决于 MySQL 配置），建议统一用localhost保持一致
如何把备份文件直接写到宿主机，避免容器内残留？
不能靠 docker exec 把文件留在容器里再拷出来——既多一步，又可能因容器重启丢数据。最稳的方式是用管道把 mysqldump 输出直接重定向到宿主机文件。
原理：宿主机 shell 解析重定向（>），在宿主机创建文件；容器内进程 stdout 流经管道，不落地容器磁盘。
- 正确写法：
docker exec mysql-container sh -c 'exec mysqldump -u root -p\$MYSQL_ROOT_PASSWORD --all-databases' > backup.sql
- 注意单引号包裹整个命令，防止宿主机提前解析
$MYSQL_ROOT_PASSWORD；用\$让变量在容器内展开 - 如果密码含特殊字符（如
@、/），改用-e MYSQL_PWD=xxx更安全，避免 shell 解析干扰 - 别用
docker cp事后复制：容器若正在写入或崩溃，文件可能不完整
备份大库时为什么卡住或中断？
常见原因是 docker exec 默认没有设置超时，而 mysqldump 长时间运行时，Docker daemon 可能因 TCP Keepalive 或客户端断连主动切断连接，导致备份截断。
这不是 MySQL 问题，是容器执行层的网络稳定性限制。尤其在云服务器、跨机房或高延迟环境下更明显。
- 加
--timeout=3600（单位秒）给docker exec（Docker 20.10+ 支持），避免守护进程过早终止 - 对超大库（>10GB），改用
mysqldump --single-transaction --skip-lock-tables减少锁等待，但需确保引擎是 InnoDB - 不要在
docker exec中加&后台运行：stdout 会被丢弃，备份文件为空 - 真正稳妥的大库方案是挂载宿主机目录（
-v /backup:/backup），让mysqldump直接写入宿主机路径，绕过管道和 exec 生命周期
