数据库更新语句实际上挺像给数据库做手术，得拿刀尺量量数据，再拿个剪刀切一刀，还得确认切口里没藏坏东西。 平时写个 `UPDATE` 语句，大家习惯直接写 `UPDATE table_name SET column = value WHERE condition;`。
这别看标准，但实际干活时总让人头大。
比如你想把表 `users` 里年龄大于 18 的用户的昵称改成“成年小王”，代码写得明明白白，但有时候数据量特别大，一次性全删了再插进去，要么中间断开了，好办出难题。
这时候咱们就不能只盯着那一行代码，得先看看表里到底存了啥。 最费事的实际上不在于逻辑，而在于那些“脏数据”。
比如你要把某个字段里的特殊字符去掉，要么把格式统一一下。
要是直接死命令 `UPDATE account SET status = 'paid' WHERE id = 100;`，万一 `100` 号账户里还有几笔还没付的钱，哪怕写个 `WHERE id = 100 AND status = 'pending'` 也没用，出于系统可能先更新了状态，然后忘了把钱扣了，要么反过来，害得钱扣了但状态没变，最终账目对不上。 这时候就得换个思路。
不要想着一次性把所有符合条件的数据全改了，最好是“挑选式”地改。就像做饭，不是把锅里所有的水都倒掉再重新煮，而是挑出那些该煮的，一个一个地加个锅，煮了再捞出来。在 SQL 里，这对应着 `UPDATE` 语句配合 `WHERE` 子句，但更讲究的是数据预览和验证。 你能够用 SQL 自带那种“刷新”要么“查看”功能，拿着那个 `SELECT FROM table_name WHERE ...` 的截图，对着屏幕看。万一你改错了，把 `status` 改成 `sold`，结局那几笔钱还没付呢，目前钱全扣掉了，回头得找客服解释，多累啊。
这时候，先让系统把更新前的样子全列出来，确认没难题了，再执行更新。 还有一种情况，就是数据量特别大，全查一遍忒费流量和 CPU 了。
比如你有一张超过百万行的 `order` 表，你想把其中订单金额小于 10 的订单取消，直接全查全改，系统可能会卡顿半天，就连超时。
这时候就需求引入一些高级的工具要么脚本，比如用 Python 要么专门的 ETL 工具，先跑个“预处理”脚本。脚本运行搞定后，它会筛选出那几笔需求取消的订单，把表里的结构先更新一下，然后再去执行正式的 `UPDATE` 命令。
这样既保证了速度，又保证了准性。 在写代码的时候，我们往往喜爱用大括号里的 `SET` 局部来描述最终想变成的样子，比如 `UPDATE users SET name = CONCAT(name, ' (Adult)')`。
这实际上是个挺碎的操作，出于 `name` 这个字段可能包含空格，也可能包含特殊符号，有时候需求清洗，有时候只是好办追加。
要是直接去改，好办出错。
这时候就能够用参数化的方式写逻辑，要么干脆把这段逻辑封装成一个视图，要么一个临时表，让更新过程变得透明。 举个例子，假设你有一张 `inventory` 表，记录着仓库里的货物。
你想把那些过期超过 30 天的货物标记为“报废”，然后自动把数量减 0。
要是直接写 `UPDATE inventory SET status = 'banned' WHERE expired_days > 30;`，万一过期天数的小数点位数不一样，比如有个存了 30.05 天的，要么 29.99 天的，结局就全变了。
这时候，先查一下当前表里最接近过期状态的那些记录，确认下它们的过期天数具体是多少，再拍板如何更新。 这种分步走的策略，实际上挺常见的。在大项目中，往往会有“查看 - 修正 - 更新 - 记录”的循环。
有时候更新后，发现某些数据出于更新规则的难题，又得重新去调。
这时候，别急着做其他事，先把更新前的快照保存下来，要么在日志里记录一下。
这样万一后续逻辑变了，要么数据源变了，你起码知道原来是啥样子，好回退。 除了逻辑上的“看 - 改”，在执行层面也得讲究策略。有些数据库对大量数据更新有锁机制，要是一次性把所有知足条件的记录都要锁起来，整个表可能要瘫痪一下。
这时候就需求分批更新。
比如每次更新 1 万条，然后查一下还有多少没改的，直到把所有符合条件的都处理完为止。
这就像开车，不能全油门冲那会儿，得多踩几次离合再加速。 另外，别忘了回滚。数据库更新是有开销的，要是中途出错了，要么更新规则写错了，后果挺严重。
故此，更新语句最好带有逻辑上的“回滚保护”。
比方说，先给所有处于 `delete` 状态的数据打上“锁”，确认它们确实不需求动，然后再启动真正的更新。
要是执行后发现还有其他数据需求动，那就把刚刚锁住的那些再释放，要么重新处理。 在实际工程中，我们还会用“条件更新”来优化性能。
有时候不需求把整个表全改，只需求改特定分区要么特定条件下的局部数据。
比如只更新那些 `location` 字段是‘北京’且 `amount` 大于 100 的数据，这样查询快，更新也省资源。
这就像你要给全市的公园修剪草坪，不是全园子都剪，而是分批次，先给北京的，再给上海的。 自然，最稳妥的办法还是结合应用层的校验。做更新之前，先让前端或中间件把数据校验一遍，确保来源可靠，格式对。
只有数据干净利落了，才准去动数据库。
这时候更新语句就像是一个经过质检的工人，拿着尺子量过、用尺量过，最终才敢挥刀。 总而言之，数据库更新语句加条件，核心在于“稳”。稳不是指代码写得最漂亮，而是指数据最保险。
不要怕费事，多查多看，多试多改。在写那条 SQL 的时候，脑子里多问几个“万一”，问自己要是数据没改错，会不会是一堆废数据；要是改错了，会不会引发连锁反应。把这些疑问变成代码里的防护网，你的系统才不会出于那一行更新语句给搞砸。


相关标签：