Docker容器内连接数据库删除数据全流程指南与避坑实践-平芜编程栈

搞过 Docker 部署的朋友应该都有这种经历：项目跑在容器里好好的，突然业务方提了个需求——"帮我把这张表清空一下"、"这个模块的数据要重置"。你第一反应可能是：直接进容器删？然后发现容器删了、镜像重建了，数据还在。等折腾一圈才明白过来，Docker 里的数据根本不跟着容器走，数据要么在容器可写层里，要么挂在数据卷上，删容器不等于删数据。

这个场景，说大不大，但确实坑过不少人。尤其是刚把项目从物理机迁到 Docker 的团队，稍微不注意就把数据删丢了，或者删了之后发现根本没删干净。这篇文章就专门聊聊这件事：Docker 部署的项目里，要怎么进容器连接数据库，正确地删除数据。包括前置判断、完整操作流程、典型坑位，以及生产环境下的稳妥做法。如果你正在用 Docker 跑 MySQL、Redis、PostgreSQL 这类服务，或者你只知道"数据在容器里"但从来没进去删过，这篇对你应该挺有用。

1. 为什么部署在容器里的数据，不能靠删容器解决

先说个容易混淆的概念。很多人刚上手 Docker 时，会把"容器"当成一台完整的小服务器，觉得数据都存在容器里的某个目录中，容器删了数据自然没了。这个理解只对了一半，而且恰恰是容易出事的那一半。

1.1 容器是无状态的工作台，数据是有状态的货物

Docker 容器本身是由镜像启动出来的运行实例。镜像有只读层，容器启动后在上面加一层可写层，你在容器里写文件、装软件、改配置，都发生在这一层。但这一层是跟着容器生命周期走的——容器被删了，可写层也就没了。

问题就在这：很多数据库镜像在构建时，会把数据目录声明为数据卷（VOLUME），或者你在 docker run 时手动挂载了宿主机目录进去。比如 MySQL 官方镜像，数据默认写在 /var/lib/mysql，如果你用 -v /my/data:/var/lib/mysql 把这个目录映射到宿主机，那么实际的数据文件都在宿主机上，容器只是"借用"这个目录。

这时候你如果 docker rm -f 把容器删了，数据卷并不会被自动删除（除非你特意加 -v 参数一起删）。数据还在宿主机目录里躺着，你重新起一个容器把目录挂回去，数据原封不动又出现了。

我习惯打一个比方：容器是集装箱车，数据是仓库里的货。车可以换，货物一直放在仓库里。你要处理数据，得去仓库里搬货，而不是把车烧了。

1.2 什么场景才需要进容器删数据库

所以"进容器连接数据库删除"这个操作，真正适用的场景是：数据库服务跑在容器里，数据卷正常挂载，你需要清空或删除某些数据，但不想动容器本身，也不想停机重建。

我平时遇到比较多的情况是这几种：

开发环境或测试环境的脏数据清理。联调测出一堆垃圾数据，需要把某个表重置，或者把整个库清了重新初始化。
业务数据误写入，需要定向删除。比如同步脚本跑了重复数据，需要按条件删掉。
表结构变更前需要清理历史数据，或者清空缓存表、日志表。
临时需要重置 Redis 缓存、清空某个 key。

这里要提醒一句：如果你是想彻底卸载某个服务、连数据文件一起清掉，那属于"删容器+删数据卷"的范畴，跟本文说的不是一回事。进容器删数据库，前提是容器还要继续跑，数据卷还要继续用。

另外，"进容器"这个动作，也分两种：一种是交互式地进入容器 shell，再在 shell 里敲数据库命令；另一种是不进 shell，直接用 docker exec 从宿主机把命令传进容器执行。两种都是"进容器"，实际用起来各有讲究，我后面会分开说。

2. 删数据前必做的三件事：备份、定位、选姿势

数据删除是不可逆操作，哪怕你只是清一张临时表，也建议先花两分钟把备份做了。这不是形式主义，是我自己吃过亏之后的教训。早期我删测试库很随意，后来有一次误删了生产库的一张配置表，虽然数据不多，但恢复起来折腾了整个下午。从那以后，删任何数据之前都先备份，哪怕只是导出一个很小的 SQL 文件。

2.1 先备份，再动手，这条红线别挑战

Docker 容器里做备份，比物理机上稍微绕一点，但思路一致。以 MySQL 为例，最常用的方法是直接用 docker exec 调容器里的 mysqldump，然后把输出重定向到宿主机：

docker exec mysql容器名 mysqldump -uroot -p密码 数据库名 > /宿主机目录/backup.sql

注意，重定向的 > 写在宿主机 shell 里，不是写在容器里。不加的话，备份文件会落在容器可写层，容器一删就没了，等于没备份。

如果你用的是 docker-compose 部署，先确认服务名，再执行同样的命令。compose 起的容器名通常带有项目前缀，比如 project_db_1，用 docker ps 看一眼最稳妥。

Redis 的备份不太一样，更推荐用持久化文件配合备份。你可以先 BGSAVE 触发一次快照，然后从宿主机复制 dump.rdb 文件出来：

docker exec redis容器名 redis-cli BGSAVE cp /宿主机/redis数据目录/dump.rdb /备份目录/

Redis 如果只是清缓存，备份的必要性看情况。但如果是删正式业务 key，备份一样要做。

PostgreSQL 的话，用 pg_dump 的原理类似：

docker exec postgres容器名 pg_dump -U 用户名 数据库名 > backup.sql

2.2 搞清楚要删的范围：整库、整表还是部分记录

备份做完，下一步是确认删除范围。很多人上来就 DELETE FROM 一张表，删到一半发现外键关联了一堆子表数据，或者删错了范围，这就不太好看。

我给自己定的流程是：

先确认是删整库（DROP DATABASE）、删整表（DROP TABLE / TRUNCATE TABLE），还是只删部分记录（DELETE FROM ... WHERE ...）。
确认关联关系。如果表之间有外键约束，要么先删子表，要么在会话里临时关闭外键检查。
确认主键自增状态。TRUNCATE 会重置自增 ID，DELETE 不会。有些业务对 ID 连续性有要求，选错会影响后面的数据。

这几种操作的差异比较明显：

操作	是否可回滚	是否重置自增	性能	适用场景
DELETE FROM 表 WHERE 条件	事务内可回滚	否	慢，逐行删	删除部分记录
TRUNCATE TABLE 表	不可回滚	是	快，直接释放页	清空整表且不保留 ID 顺序
DROP TABLE 表	不可回滚	是	快	删除整个表
DROP DATABASE 库	不可回滚	是	快	删除整个库

DELETE 适合精确删除，TRUNCATE 适合清空表并重置自增。生产环境我基本不用 DROP，除非确定这个表/库永远不用了。

2.3 三种删除姿势的适用场景

同样是删数据，实际落地有三种姿势，看情况选：

第一种是纯交互式。docker exec -it 进容器 shell，然后执行 mysql 或 redis-cli，在交互终端里一条条敲命令。优点是一步步来不容易出错，能看到每一步的结果；缺点是效率低，而且会话历史会留在容器里。

第二种是命令直传。用 docker exec 直接执行带 -e 参数的命令，或者用管道把 SQL 喂进去：

docker exec -i mysql容器名 mysql -uroot -p密码 -e "DELETE FROM users WHERE status=0;"

这种不进入交互 shell，适合一条命令搞定的事，也方便写进脚本。注意这里用了 -i 而不是 -it，因为不需要伪终端，只需要标准输入保持打开。

第三种是脚本批量执行。把多条 SQL 写到一个 .sql 文件里，通过重定向喂给容器里的 mysql：

docker exec -i mysql容器名 mysql -uroot -p密码 数据库名 < /tmp/clean.sql

这个适合大批量、多步骤的清理任务，而且脚本内容写在宿主机里，方便留存和 review。我就习惯把常用的清理脚本单独放一个目录，每次执行前看一眼，确认无误再运行。

三种姿势没有绝对的优劣，关键看场景。交互式适合不熟悉库结构的临时操作，命令直传适合明确的单条操作，脚本批量适合重复执行或复杂清理。

3. 实操全流程：docker exec 进容器连接数据库

这节我把完整流程拆开讲，以 MySQL 和 Redis 为例，因为这两类在业务里最常见。你可以照着这个流程操作，也可以根据自己用的数据库类型做替换。

3.1 第一步：用 docker ps 锁定目标容器

操作之前先确认容器在跑。直接执行：

docker ps

输出里会列出容器 ID、镜像、启动时间、端口映射、名字。如果项目容器比较多，可以用 grep 过滤：

docker ps | grep mysql

或者直接用容器 ID 前缀代替名字。只要前缀能唯一区分就行，比如容器 ID 是 a1b2c3d4e5f6...，直接 docker exec -it a1b2 bash 也行。不过我建议尽量用容器名，因为你通过 ID 操作的时候，一旦 ID 复制错了或者看走眼，指不定就操作到别的容器上了。容器名一般是有语义的，比如 mysql8、redis-dev 这种，能减少误操作。

如果是 docker-compose 部署的，容器名通常是"项目名_服务名_序号"。你可以用 docker-compose ps 在项目目录里查看，也可以直接 docker ps 看。

这里有个容易踩的坑：容器重启后名字可能变化。如果你用 --rm 启动容器，容器停止后会被自动删除，重新启动会分配新的容器 ID 和名字。生产环境一般不用 --rm，但开发环境很多人会加。所以操作前一定 docker ps 确认，不要凭记忆抄名字。

3.2 第二步：docker exec 的两种典型用法

定位到容器后，进入容器 shell 的标准命令是：

docker exec -it 容器名 bash

这个 -it 是 -i 和 -t 的组合。简单理解，-i 保证标准输入是开着的，-t 分配一个伪终端。合在一起，你才能像坐在真实终端前一样交互操作。

如果你的容器镜像是精简版，里面没有 bash，那就用 sh：

docker exec -it 容器名 sh

有些镜像更精简，连 sh 都只是 BusyBox 提供的，但基本的命令还能用。如果连 sh 都没有，说明这个镜像对你来说不适合用来调试。

进去了之后，你会看到提示符变成 root@容器ID:/# 这种样式。这说明你已经身在容器内部。

如果不进 shell，直接在宿主机上执行容器内的命令，则是：

docker exec 容器名 命令

比如：

docker exec mysql8 mysql -uroot -p

这样会在容器里启动 mysql 客户端，但因为它是在宿主机终端直接执行的，交互界面的体验取决于你有没有加 -it。想要交互式输密码，还是要加 -it：

docker exec -it mysql8 mysql -uroot -p

3.3 第三步：MySQL 容器内执行删除的完整命令

假设你已经确定要清空一张表，表名是 temp_log，库名是 app_db。全流程可以这么走：

进入容器：

docker exec -it mysql8 bash

在容器内连接 MySQL：

mysql -uroot -p

输入密码后，进入 mysql 客户端。接下来选择数据库：

USE app_db;

删除前先确认数据量：

SELECT COUNT(*) FROM temp_log;

如果确认要清空，执行：

TRUNCATE TABLE temp_log;

或者删除部分数据：

DELETE FROM temp_log WHERE created_at < '2024-01-01';

退出客户端：

EXIT;

退出容器 shell：

exit

这一套流程没有问题，但效率偏低。如果你要操作的库表很明确，我更推荐用命令直传的方式，不用进容器 shell 再进 mysql 客户端，一步到位：

docker exec -i mysql8 mysql -uroot -p密码 app_db -e "DELETE FROM temp_log WHERE created_at < '2024-01-01';"

这里有几个注意点：

-e 参数后面跟着 SQL 语句，整个 SQL 要用双引号包起来，避免 shell 把特殊字符吞掉。
如果你把密码直接写在命令行里，进程列表里会暴露密码。开发环境可以这么干图省事，生产环境不建议。
如果需要输入密码但不写在命令行里，去掉密码参数让它交互式提示，但这样脚本就不好自动跑了。可以在容器内配置 ~/.my.cnf，或者用 MYSQL_PWD 环境变量，但都有各自的坑，后面会提。

还有一种方式是把 SQL 写到宿主机文件里，再喂给容器：

docker exec -i mysql8 mysql -uroot -p密码 app_db < /tmp/cleanup.sql

这个方式我在清理多张表时经常用，因为可以直接 vim 编辑 SQL 文件，反复检查后再执行。比在交互终端里一条条敲要可控。

3.4 第四步：Redis 容器内执行删除的完整命令

Redis 相对简单。假设容器名是 redis6，清空所有数据：

docker exec -it redis6 redis-cli FLUSHALL

FLUSHALL 会清空所有库的 key，FLUSHDB 只清当前库。如果只想删某个 key：

docker exec -it redis6 redis-cli DEL user:1001

如果 key 名有特殊字符，或者你想批量删除符合某个前缀的 key，可以配合 scan 来做。比如删除所有 user: 前缀的 key：

docker exec redis6 redis-cli --scan --pattern 'user:*' | xargs docker exec -i redis6 redis-cli DEL

这里注意一点，绝对不要在生产环境用 KEYS * 去匹配 key 再删除。KEYS 命令是阻塞式的，数据量大时会把 Redis 卡住。用 SCAN 是游标式迭代，虽然慢一点，但不阻塞。

Redis 删除完以后，可以验证一下：

docker exec redis6 redis-cli DBSIZE

如果返回的数字接近 0，说明清理生效了。

如果你的 Redis 是用 docker-compose 起的，服务名可以直接作为容器内 hostname。在宿主机上连接 Redis，不需要进容器，直接：

docker exec 容器名 redis-cli -h 127.0.0.1 -p 6379

也可以，但没必要。直接在容器内用 redis-cli 连本机回环地址就行。

3.5 容器里没有数据库客户端怎么处理

这一步是个高频问题。有些镜像是精简版，比如直接用 alpine 镜像装的 MySQL 客户端，或者用 distroless 镜像跑的数据库服务，容器里根本找不到 mysql 命令或者 redis-cli。

碰到这种情况，先别慌，有几种替代方案。

第一种，检查数据库路径是不是被挂载到宿主机了。如果是 MySQL，数据目录普遍在 /var/lib/mysql，如果挂载了，你可以在宿主机上安装 mysql-client，直接连接宿主机的映射端口。比如 docker run 时映射了 3306 端口，宿主机直接：

mysql -h 127.0.0.1 -P 3306 -uroot -p

这样根本不用进容器，连接的就是容器里的 MySQL 服务。

第二种，临时进去看看有没有包管理器。如果是 alpine 容器，可以：

apk add mysql-client

如果是 Debian/Ubuntu 系容器：

apt-get update && apt-get install -y mysql-client

但这种方法我一般只在调试时用，不建议作为常规方案。因为容器本来就应该是不可变的，临时装的东西不会保留在镜像里，容器重建就没了，而且每次装包还浪费时间。

第三种，直接从宿主机上找一个客户端工具。比如你装了 Navicat、DataGrip 或者 DBeaver，直接通过端口映射连接数据库，执行业务清理，比命令行的容错率高很多。这个我放到后面生产环境建议里再细说。

4. 容器内删数据避坑清单：我踩过的那些坑

这一节写的都是实际操作中遇到过的具体问题，每个都对应真实场景。你如果照着执行，大概率能避开大多数坑。

4.1 容器内没有数据库客户端怎么办

上面已经提过一嘴。这里再补充一个具体场景：MySQL 官方镜像是带 mysql 客户端的，但如果你用的是 Percona 镜像，或者某些精简定制镜像，可能就只有 mysqld 服务，没有客户端。

我碰到过一个案例，用的镜像是某个团队的定制版，里面只有 mysqld，连基本的 mysql 命令都没有。当时急着删数据，最后是通过 docker exec 进入容器，找到数据目录确认服务在跑，然后回到宿主机用 mysql-client 连容器 IP:3306 解决的。

所以做技术方案时，一定不要假设镜像里有客户端。最好在写部署脚本时就确认好，或者在镜像里预装好客户端。如果这些都没有，那就选择宿主机远程连接的路子。

4.2 大小写敏感和外键约束的连锁反应

Docker 容器里的 MySQL 默认跑在 Linux 环境，而 Linux 上 MySQL 的表名是大小写敏感的。也就是说，你在 Windows 上的 MySQL 里写 DELETE FROM Users 能跑，在容器里很可能报错说表不存在，除非你把表名定义和 SQL 里的大小写完全一致。

这个问题的根源是 lower_case_table_names 参数。Linux 上默认值是 0，表示区分大小写。Windows 和 macOS 上默认值是 1，表示不区分。所以同一套代码，在本地开发没问题，部署到 Linux 容器里就可能报错。

解决办法有两个：一是建表时统一用小写表名，SQL 里也跟着用小写；二是把 lower_case_table_names 设为 1，但这个参数在 MySQL 8.0 里必须在初始化时设置，不能直接改运行中的实例，改起来比较麻烦。所以建立表规范时就要想清楚。

外键约束是另一个常见的"删不掉"原因。你在父表 DELETE 一条记录，但子表里有引用它的数据，直接报错 ERROR 1217 (23000)。这时候不能硬删，要么先删子表数据，再删父表数据，要么在会话里临时关闭外键检查：

SET FOREIGN_KEY_CHECKS=0; DELETE FROM 父表 WHERE ...; SET FOREIGN_KEY_CHECKS=1;

注意，这个设置只对当前会话有效，不是全局的。如果你是通过 docker exec -e "SET FOREIGN_KEY_CHECKS=0; DELETE..." 这种方式执行的，整个 -e 里的 SQL 是在一个会话里跑，没问题。但如果你先执行一条 SET FOREIGN_KEY_CHECKS=0，再执行另一条 DELETE，这是不同的会话，约束检查还是开着的。这就是我说"一条命令里完成所有操作"的原因之一。

4.3 docker exec 与终端交互的细节问题

docker exec 的 -i 和 -t 参数，很多人搞不清什么时候该用哪个。

简单总结：

只加 -t 不加 -i，容易在需要标准输入时卡住，因为命令读不到输入。
只加 -i 不加 -t，可以执行命令，但某些程序会因为没有 TTY 而拒绝运行，或者显示出来非常难看。
交互式 shell 必须 -it 一起用。
非交互式执行命令（比如 docker exec 容器名 mysql -e "..."），不需要 -t，但需要 -i 的时候是配合管道重定向。

比如这条命令：

docker exec -i mysql8 mysql -uroot -p密码 < /tmp/cleanup.sql

这里只能用 -i，如果加了 -t，反而可能因为 TTY 和重定向冲突导致怪异行为。

还有一个细节：容器内执行命令时，命令路径可能不在 PATH 里。比如 MySQL 的客户端在 /usr/bin/mysql，但某些镜像把它装在 /usr/local/mysql/bin/mysql，并且没有加入 PATH。你执行 mysql 提示 command not found，但实际命令存在。排查时可以用：

docker exec 容器名 which mysql

或者直接找路径：

docker exec 容器名 ls /usr/bin | grep mysql docker exec 容器名 ls /usr/local/mysql/bin

如果实在找不到，就在容器里 find 一下：

docker exec 容器名 find / -name mysql -type f 2>/dev/null

这种细节在调试时能省很多时间。

4.4 时区、字符集、环境变量带来的隐形坑

容器默认时区是 UTC，如果你删除数据时用了 NOW() 或者日期时间函数，结果会跟北京时间差 8 小时。我之前清理一批过期数据时，用 DELETE FROM temp_log WHERE created_at < NOW() - INTERVAL 7 DAY; 结果删完发现边界数据没删干净，就是因为容器里是 UTC 时间，判断标准跟业务预期不一致。

要解决的话，要么在 docker run 时加 -e TZ=Asia/Shanghai，要么在容器里同步宿主机时区。docker-compose 里可以这样写：

environment: - TZ=Asia/Shanghai

字符集的问题也容易忽略。如果你的数据库连接串没有指定 charset，容器内的默认字符集可能是 utf8mb4 或者 latin1，具体取决于镜像和配置。如果你删除条件里有中文，比如 DELETE FROM user WHERE name='张三'，字符集不对的话会匹配不到数据或者报错。操作前可以先检查：

SHOW VARIABLES LIKE 'character_set%';

环境变量这块，MySQL 容器通常会注入 MYSQL_ROOT_PASSWORD、MYSQL_DATABASE 等环境变量。它们的作用是初始化时创建用户和数据库。但有个值得警惕的点：不要在生产环境把密码直接写在 docker run 命令里或者 docker-compose.yml 里明文保存，更不要用 env 命令在容器里随便查看环境变量，因为其他拿到容器权限的人也能看到。

再看一遍容器里的环境变量其实也是个排查手段：

docker exec 容器名 env | grep MYSQL

能帮你确认初始化时配置的库名、用户名，但密码就别乱看了，万一旁边有人瞄到，麻烦就大了。

5. 生产环境删数据，再上几道保险

开发环境怎么折腾都行，生产环境删数据就是另一种玩法了。就算你已经在容器里熟练地敲 SQL，我还是建议多考虑几层保护，别嫌麻烦。

5.1 用只读账号与 SQL 审计降低误删风险

生产库的连接信息，我强烈建议不要直接用 root。用完整个 root 权限删数据，万一手滑打错 WHERE 条件，整张表就没了。

更稳妥的做法是：给负责清理数据的人配一个专用账号，只授予必要的权限。比如只允许 DELETE，不允许 DROP、TRUNCATE，更不允许 DROP DATABASE。MySQL 里可以这样：

CREATE USER 'cleaner'@'%' IDENTIFIED BY '强密码'; GRANT SELECT, DELETE ON app_db.* TO 'cleaner'@'%'; FLUSH PRIVILEGES;

如果业务上只需要清理特定表，还可以收窄到表级别：

GRANT SELECT, DELETE ON app_db.temp_log TO 'cleaner'@'%';

这样即使操作失误，DBA 的底线数据（表结构、其他表数据）也不会被破坏。

同时，可以考虑开启 MySQL 的通用日志或者审计日志。MySQL 8.0 自带的审计插件需要额外安装，但如果能配置上，每次 DELETE 都会被记录，包括执行的 SQL 语句、用户名、来源 IP。后续排查数据问题时，这就是最有力的证据。

Redis 那边没有这么细的权限控制，可以设置 --rename-command 把危险命令改名或者禁掉 CONFIG、FLUSHALL 等，但从容器层面讲，最简单的是不要让生产 Redis 暴露未授权访问。容器内部访问还好，如果映射到公网端口又没有密码保护，别人连进来执行一个 FLUSHALL，数据瞬间全没了，那才是真正的灾难现场。

5.2 用客户端工具连接宿主机映射端口会更顺手

生产环境我一般不太喜欢在命令行里删数据，因为一旦 SQL 写错，没有二次确认的机会。Navicat、DataGrip、DBeaver 这类客户端工具通过宿主机映射端口连数据库，至少能看到完整的表结构、数据预览、执行计划，而且大多数工具在执行 DELETE 前会弹确认框。

前提是你在 docker run 或者 docker-compose.yml 里已经映射了端口，比如：

ports: - "3306:3306"

如果端口没映射，也可以从容器内部去验证。但生产环境还是建议保留一个"运维通道"，通过 SSH 隧道或者堡垒机连接，而不是直接把数据库端口暴露到公网。

用客户端工具有个额外的好处：你可以先写一条 SELECT 验证查询条件，确认返回的记录数、数据内容，再把相同的 WHERE 条件改写成 DELETE 执行。这比在命令行里凭感觉删要靠谱得多。

就拿 DBeaver 举例，它支持执行 SQL 前自动生成 SELECT，你先跑边测试，再替换成 DELETE，哪怕操作错了也有个心理预期。

5.3 删完数据后的验证与习惯

删除操作执行完，不代表事情就结束了。我一般会立刻做几件事：

第一，检查影响行数是否在预期范围内。MySQL 客户端执行 DELETE 后会返回 Rows matched 和 Changed，如果没有返回或者返回的数字跟你预估的范围差太远，赶紧查原因，别等到业务方反馈。

第二，备份残留验证。如果删的是生产数据，删完立刻再做一次备份，保证"删完后的状态"也是可恢复的。你可能会觉得这有点多余，但万一删完发现业务方又反悔要找回数据，这时候最新备份就是救命的。

第三，检查自增 ID 是否会有冲突。如果业务表用了自增主键，你删掉了部分记录但没有重置自增，下次插入会用新的自增值，不会复用已删除的 ID。如果业务有 ID 连续性的依赖，需要考虑 ALTER TABLE 表 AUTO_INCREMENT=1 重置，但这一步一定要谨慎，不能乱来。

第四，把操作记录写下来。我习惯在项目运维文档里记一条：什么时间、谁、在哪个容器上、执行了什么 SQL、删了多少行、影响哪些表。平时觉得多余，等需要回溯问题时，这条记录就是最直接的时间线。

习惯这个东西，靠一次两次自觉还不够，最重要的是每次操作都走固定流程。我把自己的流程写在便签上：备份-确认范围-执行删除-验证-记录。这套流程在开发环境和生产环境一视同仁，只是生产环境多一道审批和权限门槛。

最后再说一个比较小的建议：如果你经常需要清理容器里的数据库，不妨把这些常用的删除操作封装成一个脚本，放在宿主机上，参数化地传入容器名、库名、表名、条件。比起每次手动敲一长串 docker exec 命令，脚本更稳定，也更不容易出错。比如我就是写了一个简单的 shell 脚本，每次执行前会先打印将要执行的操作，确认无误后再继续，算是一道简单但有效的安全阀。

这些经验都是我一步步踩出来的，谈不上多高明，但在关键时候能挡住不少低级事故。希望这篇文章能帮你更从容地处理 Docker 里的数据删除操作。