From 7cab5c812b7dd47a12c4fb55b2a0811be2206060 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=99=BE=E5=A7=90?= Date: Wed, 26 Aug 2026 18:47:46 +0800 Subject: [PATCH] =?UTF-8?q?post:=20=E4=B8=80=E6=9D=A1=20RENAME=20=E6=B8=85?= =?UTF-8?q?=E4=BA=86=20235=20=E8=A1=8C=E6=95=B0=E6=8D=AE(=E8=84=B1?= =?UTF-8?q?=E6=95=8F=E7=89=88)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/posts/rename-cascade-data-loss.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/rename-cascade-data-loss.md b/content/posts/rename-cascade-data-loss.md index 2715381..52105da 100644 --- a/content/posts/rename-cascade-data-loss.md +++ b/content/posts/rename-cascade-data-loss.md @@ -56,7 +56,7 @@ MySQL 的 CASCADE 删除，其实**绝大多数时候也不会真的删干净** 这单没出人命，靠三件事： -1. **有备份**。迁移前刚打了 `app.db.bak-cattype-20260826131355`，恢复 `resources` 235 行。 +1. **有备份**。迁移前刚打了 `cattype` 那次重建的备份，恢复 `resources` 235 行。 2. **恢复时发现二次级联**。`DROP resources` 又清了 `resource_channels`，也是靠同一份备份恢复。 3. **审计脚本兜底**。迁移后不是只看表面，而是逐表核对行数，才确认两个表都受损、都恢复到位。