MySQL Workbench：连接、查询建模与本地资产治理
在 Linux 桌面连接一次性 MySQL
准备一台 Ubuntu 24.04 图形桌面，当前普通用户可操作 Docker Engine，并可按下文安装 MySQL Workbench。数据库只发布到这台机器的回环地址，Workbench 也在本机运行；若桌面在另一台主机，127.0.0.1 指向那台桌面，不能直接照抄，应先配置经授权的 SSH 转发。实验只使用合成订单和临时密码。
已安装 Workbench 时，先用 /usr/bin/mysql-workbench --version 记录本机版本。尚未安装时，到MySQL 官方 APT 仓库下载页选 Ubuntu 对应的 mysql-apt-config 包，核对下载域名、发行版与签名/校验材料后，按官方仓库指南配置；不要把网页示例中的旧包名照抄为当前文件名。把下载的文件放到本人可读目录，再在 Ubuntu 终端执行：
set -euo pipefail
read -r -p 'mysql-apt-config .deb 的绝对路径: ' REPO_DEB
[[ "$REPO_DEB" = /* ]] || { echo '请输入绝对路径' >&2; exit 1; }
test -f "$REPO_DEB" || { echo '找不到仓库配置包' >&2; exit 1; }
test "$(dpkg-deb -f "$REPO_DEB" Package)" = mysql-apt-config || exit 1
sudo apt install "$REPO_DEB"
sudo apt-get update
apt-cache policy mysql-workbench-community核对 apt-cache policy 的 Candidate 不是 (none)，候选来源是预期的 MySQL 官方仓库；本机已配置其他 MySQL APT 仓库时先确认仓库冲突和发行线，不直接覆盖配置。接着安装候选版本并核对实际启动程序：
WB_VERSION="$(apt-cache policy mysql-workbench-community | awk '/Candidate:/{print $2}')"
test -n "$WB_VERSION" && test "$WB_VERSION" != '(none)' || exit 1
sudo apt-get install "mysql-workbench-community=$WB_VERSION"
/usr/bin/mysql-workbench --versionmysql-workbench-community 是 Oracle 官方包名，发行版自行维护的 mysql-workbench 是另一来源；Linux 安装说明区分了两者。启动命令和--version 选项由 Workbench 官方文档定义。若安装失败，保留 apt-cache policy、APT 错误和发行版信息，先处理包源或依赖问题，不能用来历不明的二进制覆盖。
在 Bash 中先检查同名容器和卷；只要存在就停止启动，先弄清其归属，不要复用或删除。为新实验设一份管理员密码。此一次性密码会保存在 Docker 容器元数据里，不能使用生产凭据：
set -euo pipefail
if docker container inspect workbench-learning >/dev/null 2>&1 ||
docker volume inspect workbench-learning-data >/dev/null 2>&1; then
echo '实验容器或卷已存在；停止启动并核对归属' >&2
exit 1
fi
test -z "$(ss -H -lnt '( sport = :3307 )')" || { echo '3307 已占用' >&2; exit 1; }
read -r -s -p '实验 MySQL 管理员密码: ' MYSQL_ROOT_PASSWORD
printf '\n'
test -n "$MYSQL_ROOT_PASSWORD" || exit 1
export MYSQL_ROOT_PASSWORD
docker volume create --label article-lab=mysql-workbench \
--label role=mysql-data workbench-learning-data
docker run -d --name workbench-learning \
--label article-lab=mysql-workbench \
-p 127.0.0.1:3307:3306 \
-e MYSQL_ROOT_PASSWORD \
--mount type=volume,src=workbench-learning-data,dst=/var/lib/mysql \
mysql:8.4.11 || { unset MYSQL_ROOT_PASSWORD; exit 1; }
unset MYSQL_ROOT_PASSWORDdocker ps --filter name=workbench-learning 应显示正在运行的容器；Docker 官方 MySQL 标签列有 8.4.11。首次初始化完成前，客户端可能收到连接拒绝；先用 docker logs workbench-learning 看是否已有 ready for connections，若容器退出则检查初始化错误。初始化失败仍可能留下本次容器和卷，不要重新运行创建命令或复用旧卷来猜密码；核对标签和挂载后按末节的清理路径退出，再建新的实验。进入容器内的 MySQL 客户端，按提示输入刚才的管理员密码；这条连接走容器本地 Socket，不是桌面随后使用的宿主 3307 端口。
docker exec -it workbench-learning \
mysql --no-defaults --user=root --password在这个一次性实例里建立订单、订单明细两张有关联的样本表和读账号。把 <one-off-reader-password> 替换为本次实验专用密码后再执行；它会经过交互客户端，不能使用生产凭据。密码若含单引号需要按 MySQL 字符串语法转义；简单做法是临时生成只含字母和数字的实验值。管理员应看到建库、两张表各插入两行、建用户和授权均成功。
CREATE DATABASE workbench_lab;
CREATE TABLE workbench_lab.app_order (
id BIGINT PRIMARY KEY,
created_at DATETIME NOT NULL,
status VARCHAR(16) NOT NULL,
KEY idx_order_created_at (created_at)
);
CREATE TABLE workbench_lab.app_order_line (
order_id BIGINT NOT NULL,
line_no INT NOT NULL,
sku VARCHAR(32) NOT NULL,
PRIMARY KEY (order_id, line_no),
CONSTRAINT fk_order_line_order FOREIGN KEY (order_id)
REFERENCES workbench_lab.app_order(id)
);
INSERT INTO workbench_lab.app_order VALUES
(1, NOW() - INTERVAL 2 HOUR, 'PAID'),
(2, NOW() - INTERVAL 1 HOUR, 'PENDING');
INSERT INTO workbench_lab.app_order_line VALUES
(1, 1, 'sample-101'),
(2, 1, 'sample-202');
CREATE USER 'workbench_lab_ro'@'%' IDENTIFIED BY '<one-off-reader-password>';
GRANT SELECT ON workbench_lab.* TO 'workbench_lab_ro'@'%';输入 exit 离开管理会话。按 Workbench 新建连接与 Standard TCP/IP 字段设置：首页 MySQL Connections 旁点击 +，Connection Name 填 workbench-learning-ro，Connection Method 选 Standard (TCP/IP)，Hostname 填 127.0.0.1，Port 填 3307，Username 填 workbench_lab_ro，Default Schema 填 workbench_lab。密码框留空，让 Test Connection 时再输入刚设置的只读密码；不必保存到 Password Vault。测试成功后打开 SQL Editor，先核对身份：
SELECT CURRENT_USER(), DATABASE(), @@port;CURRENT_USER() 应为 workbench_lab_ro 的授权项，DATABASE() 应为 workbench_lab，而 @@port 应为容器内部的 3306，不是宿主映射的 3307。
随后执行下面的只读查询，应返回 PAID 和 PENDING 两条记录。只在这份可删除的实验库中逐条执行两项拒写测试：CREATE TABLE 和 UPDATE 都应因只读账号缺权限而失败；如果写入成功，先停止实验并核对 CURRENT_USER()、连接卡片及授权，不要继续做导出或 Safe Updates 实验。
SELECT id, created_at, status
FROM workbench_lab.app_order
WHERE created_at >= NOW() - INTERVAL 1 DAY
ORDER BY created_at DESC
LIMIT 20;
CREATE TABLE workbench_lab.permission_probe(id INT);
UPDATE workbench_lab.app_order SET status = 'CANCELLED' WHERE id = 2;这条本机路径只证明桌面连接、查询和数据库授权。它没有验证跨主机 TLS、堡垒机或生产备份；这些操作需要按后文对应身份、证书和恢复条件另行执行。
连接实例与 SQL Editor
Workbench 从首页的连接卡片进入 MySQL 实例，在 SQL Editor 中浏览 schema、执行查询和查看结果。连接名称、颜色与分组便于区分环境；服务器仍按实际连接的账户授权，因此创建连接后要先查询实例和登录身份，再操作数据。
一条可信连接要回答更具体的问题：TCP 最终落在哪台实例，SSH 隧道经过哪个跳板，TLS 是否校验服务器主机名，MySQL 实际用哪个 user@host 做授权，默认 schema 是什么，SQL Editor 是否仍有未提交事务。Workbench 把这些信息分散在连接编辑器、状态栏、Output 和服务器响应里，操作者必须主动把它们对齐。
Workbench 是独立桌面产品。对象浏览、SQL Editor、Visual Explain、EER Model、迁移向导、连接缓存和本地历史都属于它自己的生命周期。MySQL 发行内的命令行、部署、InnoDB、复制和恢复则沿着 MySQL 权威主文章 的实例证据链继续展开，避免出现另一套彼此漂移的 mysql CLI 教程。
安装时同时确认发行线和服务器兼容面
MySQL Workbench 的官方安装说明提供 Windows、Linux 与 macOS 发行物，Linux 包型按对应发行版步骤选择。建模功能不依赖在线服务器，SQL 开发和管理功能则需要连接 MySQL。Workbench 与 MySQL Server 的发布节奏不同；连接测试通过后，还要检查目标服务端版本对应的管理页面、语法解析、Performance Dashboard 和导出工具。
安装后从 Help 菜单查看 Workbench 版本和 System Info。团队升级服务器前，应使用同一 Workbench 构建回归连接、认证插件、TLS、对象树、Visual Explain、Data Export/Import 和关键管理页面。发现管理能力不兼容时，先收窄 Workbench 的职责，而不是因为查询可用就让它继续承担生产变更。
Linux 与 macOS 上的服务器管理功能可能调用本机 sudo。只做 SQL 查询的成员不需要因此获得主机提权；进程启停、配置文件修改和日志读取应通过单独的运维入口完成。安装包来源、签名、系统依赖和卸载路径也要记录，不能从不明镜像下载桌面端后直接导入生产连接。
每一种连接方法都多了一段需要验证的身份
Workbench 的连接编辑器不是通讯录。它同时保存网络终点、默认 schema、TLS 参数、SSH 参数和本地凭证引用。常用字段可以按故障层解释：
| 配置 | 它真正决定什么 | 首个可用证据 |
|---|---|---|
| Hostname / Port | MySQL TCP 终点 | timeout、refused、服务器 @@hostname 与 @@port |
| Username | 客户端提交的账户名 | USER() 与 CURRENT_USER() |
| Default Schema | 连接后的默认名称解析上下文 | DATABASE()，不会额外授予权限 |
| SSL Mode / CA | 是否加密、是否验证 CA 与主机名 | Ssl_cipher 和证书错误 |
| SSH Host / User / Key | 到跳板机的隧道身份 | 主机指纹、SSH 日志、隧道本地端口 |
| Timeout | 客户端建立连接或等待的预算 | 关闭窗口后仍需检查服务端线程 |
直连开发库时使用 Standard TCP/IP。跨不可信网络时，SSL Mode 选择 Verify Identity，并由受控路径提供 CA。它不仅要求加密，还会把连接主机名与服务器证书身份匹配。证书名不一致时应修正 DNS、证书 SAN、代理 SNI 或连接别名；把模式降为 Required 只能证明“某个对端提供了加密”，不能证明它就是目标数据库。
需要跳板机时使用 Standard TCP/IP over SSH。第一次连接会涉及 SSH 主机指纹，指纹应从资产系统或运维渠道核对，不能在告警压力下直接接受。SSH 成功只说明工作站到跳板机的第一段成立；隧道后的 MySQL TLS、账号认证和 schema 权限仍需独立验证。
SSH 私钥、数据库密码和 CA 私钥不应随连接导出包分发。Workbench 的 Password Storage Vault 只解决当前工作站如何保存密码，不解决共享账号、最小权限、轮换和离职回收。团队连接模板可以保存别名、端口、证书来源和申请入口，真实 Secret 由个人或工作负载身份系统签发。
Test Connection 之后，马上查询服务端身份
进入 SQL Editor 后先运行一条不依赖业务表的身份查询：
SELECT
VERSION() AS server_version,
@@hostname AS server_host,
@@port AS server_port,
CURRENT_USER() AS authenticated_account,
USER() AS submitted_identity,
DATABASE() AS current_database,
CONNECTION_ID() AS connection_id;
SHOW SESSION STATUS LIKE 'Ssl_cipher';CURRENT_USER() 是服务端实际用于权限判断的账户，USER() 是客户端提交的用户与来源。两者不同通常意味着命中了意外的 user@host、匿名账户或代理身份。DATABASE() 与连接卡片标注的环境不一致时，不要继续打开业务表；先修正默认 schema 或连接终点。
Ssl_cipher 非空表示当前会话加密。它不能单独证明主机名已经校验，因此需要和连接编辑器里的 Verify Identity、CA 路径一起留证。Connection ID 则是后续追踪慢查询、锁等待和取消状态的关联键；截图只留连接名称而没有服务器身份，证据强度很低。
Visual Explain 是计划阅读器，不会替你判断成本
对同一查询先执行普通 EXPLAIN FORMAT=JSON：
EXPLAIN FORMAT=JSON
SELECT id, created_at, status
FROM workbench_lab.app_order
WHERE created_at >= NOW() - INTERVAL 1 DAY
ORDER BY created_at DESC
LIMIT 20;SQL Editor 可以将计划切换为 Visual Explain。图形把访问方式、表、连接与成本估算变得更易读，但它仍然消费服务器生成的计划。小表上优化器选择全表扫描不一定有问题；判断要结合估算行数、过滤比例、排序、临时表和生产基线。
不要为了得到“真实耗时”随手执行 EXPLAIN ANALYZE。它会真实运行语句。对复杂查询、锁敏感表或可能返回大量数据的场景，普通计划、Performance Schema 与隔离环境复现应先完成，再决定是否执行分析版本。
计划截图也可能泄露 schema、表名、谓词字面量和行数估算。向工单附图前要裁掉连接身份和敏感条件，并保留查询指纹、服务器版本和统计信息基线；只有一张彩色计划图，无法支持后续复现。
从现有表生成 EER 模型
本机样本中，app_order_line.order_id 有一条真实外键指向 app_order.id。先在只读连接的 SQL Editor 核对两张表的定义，再按 Reverse Engineering 官方步骤打开 Database → Reverse Engineer，选 workbench-learning-ro 连接和唯一的 workbench_lab schema，只选这两张表并保留 Place imported objects on a diagram。执行后查看任务日志，EER 图上应有两张表及从订单明细到订单的外键关联；如果只显示两个无连线方框，回到数据库核对外键是否真实创建，不能靠手绘连线冒充服务端约束。
模型另存为本机私有目录中的 .mwb 文件。它是 Workbench 的设计资产，不是 MySQL 备份；保存模型不会修改在线数据库。在模型页按官方 SQL 脚本导出使用 File → Export → Forward Engineer SQL CREATE Script 生成 DDL 到另一份文件，检查其中的表名、列类型、主键和外键。此处只查看脚本，不连接生产库执行；模型改变、SQL 文件生成和服务端 schema 变更是三件不同的事。若要正式变更，仍需经过迁移脚本审查、测试和回退设计，而不能把 EER 图直接当作已部署结构。
Safe Updates 能拦截部分误触，不能创造只读账号
Workbench 的 Safe Updates 会让一部分缺少键条件或 LIMIT 的 UPDATE、DELETE 返回错误。先在 Preferences → SQL Editor 的主设置中确认 Safe Updates 已开启，然后重新连接，使新会话采用相应设置；官方首选项说明也明确要求重新连接。这个实验需要有 UPDATE 权限，不能继续用前面的只读账号：否则得到的是权限拒绝，无法判断 Safe Updates 是否生效。在本页一次性实例上，重新用前述 docker exec -it workbench-learning mysql --no-defaults --user=root --password 进入管理员会话，创建另一份临时维护账号；把下面的占位密码替换成不同的实验密码后再执行：
CREATE USER 'workbench_lab_rw'@'%' IDENTIFIED BY '<separate-temporary-secret>';
GRANT SELECT,UPDATE ON workbench_lab.app_order TO 'workbench_lab_rw'@'%';新建该账号的独立连接，只访问隔离的 workbench_lab。SQL Editor 先查询 CURRENT_USER()、@@sql_safe_updates，确认账号为 workbench_lab_rw、设置为 1，再逐条运行：
START TRANSACTION;
UPDATE workbench_lab.app_order SET status = 'CANCELLED';
-- 上条应报 1175；不要关闭 Safe Updates 继续。
ROLLBACK;
SELECT id,status FROM workbench_lab.app_order ORDER BY id;预期错误码为 1175，最后两行状态仍为 PAID、PENDING。若是 1142，则先核对账号与 UPDATE 权限，不能算本次实验通过。带主键条件的更新可能被允许，DDL 也不由此设置统一拦截；生产只读仍由 MySQL GRANT 保证。
同一个 Workbench 服务器连接下的多个查询标签可能共享会话和事务状态。切换标签不等于获得新事务；需要独立隔离级别或提交边界时，应打开新的连接，并在状态栏确认实际 connection。关闭编辑器前检查是否存在待提交事务，不能假设窗口关闭一定触发预期回滚。
临时写账号还可以使用 START TRANSACTION READ ONLY 给当前事务增加第二道限制，但 MySQL 对临时表和 DDL 的语义需要单独理解。事务只读同样不能代替服务端最小权限。
Data Export 有三种完全不同的结果
Workbench 的 Result Grid 可以把当前查询结果导出为 CSV、JSON、HTML、XML 等格式；Table Data Export 以表为对象处理 JSON 或 CSV；Management Navigator 的 Data Export/Import 则处理 MySQL SQL 格式，并调用 mysqldump 等客户端工具。三者的风险和恢复能力不同，不能统一叫“导出备份”。
结果集导出只适合受限样本。查询本身要限定字段、时间窗和行数，文件写入权限受控目录，工单只引用脱敏副本。隐藏 Result Grid 中的一列不代表导出一定排除它，导出前应重新检查字段集合。
Data Export 向导可以选择 schema、表、存储过程和事件，并输出项目目录或单一 SQL 文件。开始前在 Options 或日志中确认实际 mysqldump 二进制版本；Workbench 与服务器版本不配对时，导出失败可能来自客户端工具兼容，而不是数据库损坏。
Data Import 会执行文件中的 SQL。目标 schema、对象覆盖、字符集、约束和 DDL 隐式提交都会影响结果。第一次恢复放在隔离实例，保留 Import Progress 日志，再核对对象数、行数、约束与抽样数据。SQL dump 含 DDL、账户或敏感业务数据时，其保护级别不低于源数据库。
桌面向导不应成为无人值守生产备份。正式备份需要服务端一致性策略、加密、保留、校验、恢复演练和 RPO/RTO；Workbench 更适合开发迁移、受控小规模导出和人工恢复验证。
在前面的合成库中，可以把结果集导出与表导入走通。先由本机只读连接执行下面的查询，在 Result Grid 选择 Export recordset to an external file，格式选 CSV，保存到本人创建的私有目录；结果集导出说明明确它导出的是当前查询结果。命令行创建目录只是为本次下载确定宿主落点，Workbench 的保存对话框要选这个绝对路径：
LAB_EXPORT_DIR="$(mktemp -d)"
chmod 700 "$LAB_EXPORT_DIR"
printf 'CSV 保存目录：%s\n' "$LAB_EXPORT_DIR"SELECT id, status
FROM workbench_lab.app_order
ORDER BY id;把文件命名为 app_order_sample.csv。回到宿主终端，确认确实生成了本次文件，打开前几行应看到 id,status 两列及 1,PAID、2,PENDING 两条数据；是否写入列名、字段引号和分隔符以实际导出设置为准，导入时须与文件一致。若目录为空或字段不符，先看 Workbench Output 与导出对话框，不将成功提示当作文件校验。
test -s "$LAB_EXPORT_DIR/app_order_sample.csv" || exit 1
sed -n '1,3p' "$LAB_EXPORT_DIR/app_order_sample.csv"要验证导入，用前文相同的容器内管理员入口，在这份一次性 schema 上给临时写账号增加新建/写入表的权限；不要给只读账号加权，也不要把实验授权复制到生产库：
docker exec -it workbench-learning \
mysql --no-defaults --user=root --passwordGRANT CREATE, INSERT, SELECT ON workbench_lab.* TO 'workbench_lab_rw'@'%';输入 exit 离开管理员会话，重新连接 Workbench 的写账号，使新授权对该连接生效；MySQL 的权限生效规则区分表、数据库和全局权限，重连可以避开旧会话的默认库权限缓存。核对 CURRENT_USER() 为 workbench_lab_rw，然后在 workbench_lab 下打开 Table Data Import Wizard。选择刚导出的 CSV、创建新表 app_order_import_probe，按文件实际内容设置首行是否为列名，检查 id 映射为整数、status 为文本，再启动导入；不要指向原 app_order 表。Import Results 应显示两行成功，随后查询新表：
SELECT id, status
FROM workbench_lab.app_order_import_probe
ORDER BY id;预期仍是两条记录。若导入失败，先核对写账号的 SHOW GRANTS、CSV 列名/编码和目标表是否因前次尝试已存在；不能在原表上反复重试。这个 CSV 没有 created_at、索引或约束，验证的是受限结果集的往返，不是数据库备份恢复。退出实验时按后文处理新表、CSV 和 Workbench 本地历史。
Workbench 在本机留下的不止连接密码
Workbench 的用户配置目录按平台不同。Windows 通常位于 %AppData%\MySQL\Workbench\，macOS 位于用户 Library 的 Application Support，Linux 位于 ~/.mysql/workbench/。真正需要治理的是目录中的对象：
| 本地资产 | 保存内容 | 退出时关注什么 |
|---|---|---|
connections.xml | 首页连接定义 | 别名、内部地址、用户名和凭证引用 |
server_instances.xml | 与连接关联的服务器管理信息 | 主机与管理路径 |
sql_history/ | SQL Editor 执行过的明文 SQL | 密码、token、个人数据、修复语句 |
sql_workspaces/ | 标签顺序和编辑工作区 | 未保存查询与 schema 线索 |
log/ | 启动和 SQL action 结果 | 路径、插件、连接错误和内部地址 |
cache/ | 每连接缓存和列宽等状态 | 删除或重命名连接后仍可能残留 |
snippets/、scripts/ | 自定义 SQL、脚本和扩展 | 可执行内容、秘密和团队所有权 |
SQL History 是明文，不是安全审计仓库。生产查询若包含真实订单号、token 或修复参数，它们会离开 MySQL 权限系统进入工作站。团队应明确允许记录哪些语句、个人设备是否允许生产连接、必要证据如何脱敏归档，以及何时清理个人副本。
删除首页连接不会自动保证所有 cached files、workspace、history 和日志消失。人员离职、设备报废或连接退役时，先保留必须审计的脱敏材料，再按明确路径处理这些目录；不要只在 UI 删除连接卡片就宣布回收完成。
连接备份功能会生成包含配置的归档。它适合迁移个人设置，却可能把内部地址、用户名和连接结构带到另一台电脑。导出前移除生产连接与不应共享的凭证引用，归档进入受控存储，恢复后重新验证每条连接的账号和 TLS。
窗口关闭后，服务端查询可能还在跑
Workbench 报连接超时或用户关闭标签，不等于 MySQL 已经终止语句。查询卡住时记录 Connection ID，由有权限的管理入口检查 Performance Schema 或 process list，确认语句状态、等待事件和资源占用，再决定是否取消。
一个 Workbench 连接标签可能建立不止一条物理连接，管理功能还会增加连接需求。多人值班同时打开多个实例，会消耗 max_connections。容量评估既要看数据库 QPS，也要看桌面连接数、长结果集网络流量、Workbench 内存和导出磁盘。
Can't connect 应先区分 timeout 与 refused；前者多在 DNS、VPN、路由和防火墙，后者多在监听端口和服务状态。Access denied 说明网络已经到达服务端，应核对 user@host、认证插件和授权。TLS 错误则保留 CA、主机名和证书链信息，不把连接模式降级为修复。
对象树卡顿可能来自元数据范围过大、缓存或网络，不应通过给账户授予全库权限来“加快加载”。收窄 schema、刷新对象和观察 SQL action 日志，通常比扩大权限更能定位问题。
清理实验时沿着本地副本反向退出
管理员先删除实验账户和数据库：
DROP USER IF EXISTS 'workbench_lab_ro'@'%';
DROP USER IF EXISTS 'workbench_lab_rw'@'%';
DROP DATABASE IF EXISTS workbench_lab;工作站随后删除实验连接、导出的 CSV/JSON/SQL、临时 CA 副本和不再需要的连接备份。再检查 Workbench 配置目录中的 sql_history、sql_workspaces、log 与 cache，只处理本次连接对应的明确目标。需要审计的材料先脱敏进入受控系统，不机械销毁正式事件证据。
若使用本页的独立 Docker 实验，还要确认 workbench-learning 容器和 workbench-learning-data 卷确属本次实验、无需保留，再删除它们；卷内数据不可恢复。若使用的是现有共享 MySQL，不执行这组 Docker 清理命令。下面先核对容器标签、实际挂载与卷标签，输入完整容器名确认后才停止并删除；容器创建失败而只留下卷时，此步骤不会猜测归属或删除卷，应先人工核对卷标签和内容。
test "$(docker inspect -f '{{index .Config.Labels "article-lab"}}' workbench-learning)" = mysql-workbench || exit 1
test "$(docker inspect workbench-learning --format '{{range .Mounts}}{{if eq .Destination "/var/lib/mysql"}}{{.Name}}{{end}}{{end}}')" = workbench-learning-data || exit 1
test "$(docker volume inspect -f '{{index .Labels "article-lab"}}' workbench-learning-data)" = mysql-workbench || exit 1
read -r -p '将删除本次数据库和卷；输入 workbench-learning 确认: ' answer
test "$answer" = workbench-learning || exit 1
if test "$(docker inspect -f '{{.State.Running}}' workbench-learning)" = true; then
docker stop workbench-learning || exit 1
fi
docker rm workbench-learning || exit 1
docker volume rm workbench-learning-data生产连接退役还要撤销数据库账户和授权、轮换共享凭证、删除堡垒机权限、收回 SSH key 和设备会话。Workbench 本地清理只是其中一层。密码若已经出现在 SQL History、日志、截图或连接导出包中，删文件不能撤回泄漏，必须轮换凭证并复核审计记录。