一套安全的数据修改习惯

INSERT、UPDATE 和 DELETE 会改变真实数据。一条条件错误的 SQL 可以在几秒钟内影响大量 Row，所以真正重要的不只是会写语法，还要形成稳定的工作方式。

先确认连接环境

公司常有 Development、Testing、Staging 和 Production。测试库的数据可以重建，Production 却服务真实用户。写操作前确认服务器、Database 和 Schema；不要只凭窗口颜色或记忆判断。

Development — 个人开发数据

Testing — 自动或手动测试

Staging — 上线前验证

Production — 真实业务数据

UPDATE 和 DELETE 前先写 SELECT

最终想用 WHERE city = 'Tokyo' 修改用户时，先运行相同条件的 SELECT。结果正是目标 Row，才执行写操作。删除 Home 商品也一样：先证明条件正确，再删除。

关注 affected rows

你应提前知道大约会影响多少 Row。按唯一 id 修改用户通常预期 1 row affected；若工具报告 500，就说明实际范围与预期不符。不要忽略执行反馈。

优先使用唯一条件

修改特定记录时，WHERE id = 3 通常比 WHERE name = 'Chris' 更可靠，因为名字可能重复。批量操作当然可以使用类别或日期，但条件必须与意图范围一致。

不要对写操作“试一下”。 不确定 DELETE 会做什么时，把它改成 SELECT 先观察。正确心态是“先知道会发生什么，再执行”，而不是“先执行，再看看发生了什么”。

在非生产环境验证复杂操作

大量或复杂修改最好先在 Development 或 Testing 使用有代表性的测试数据验证逻辑和影响范围。学习 SQL 也应使用可以随时重建的练习 Database。

不要假设一定可以 Undo

许多工具开启 Auto Commit，写操作执行后立即保存。事务可以帮助一组操作一起成功或撤销，但在深入学习之前，不要假设错误 SQL 一定能靠一个 Undo 按钮恢复。Backup 和日志恢复远比事前检查困难。

写操作后再次 SELECT

修改前预览，修改后验证，再结合 affected rows，形成闭环。

推荐的 UPDATE 工作流

把 Bob 从 Osaka 改为 Tokyo：先用 id 2 查询并确认是 Bob；执行带相同 WHERE 的 UPDATE；查看 1 row affected；再次查询 id 2，确认 city 已变化。

推荐的 DELETE 工作流

删除 id 3 的测试商品：先查询确认对象；执行带 id 条件的 DELETE；检查 1 row affected；最后查询 id 3 应无结果。这些步骤比最短 SQL 更重要，尤其当开始处理 JOIN、子查询、批量修改和 Production。