开启 sql_safe_updates 是防范 update 漏写 where 导致全表更新的最有效机制，它拦截无 where、where 未用索引列及多表 update 定位模糊三类操作，并需配置到 mysqld 配置文件中永久生效。
UPDATE 漏写 WHERE 会静默更新全表，不是报错，而是直接执行——这是生产事故最高发的场景。靠“小心点”没用，必须靠机制卡住。
开启 sql_safe_updates 是最有效的第一道防线
sql_safe_updates 是 MySQL 内置的安全开关，设为 1 后，会拦截三类高危操作：
- UPDATE 没有 WHERE 子句
- UPDATE 的 WHERE 条件未使用主键或索引列（例如 WHERE name = 'xxx' 但 name 没索引）
- 多表 UPDATE 无法确认是否通过键值精确定位（如 JOIN 条件缺失或模糊）
它不会阻止所有误操作，但能拦下 80% 以上的裸更新。永久生效需写入配置文件：
mysqld [mysqld] sql_safe_updates = 1或者在启动时加参数：
--sql-safe-updates。注意：该变量是会话级的，只对当前连接生效，所以配置文件方式更可靠。
执行前必须用 SELECT 预查匹配行数和样本数据
sql_safe_updates 不是万能的——它不校验你写的 WHERE 是否逻辑正确。比如你想改“今天创建的订单”，却写了 WHERE DATE(created_at) = CURDATE()，这个条件本身能走索引吗？它实际匹配多少行？
- 先跑：SELECT COUNT(*) FROM orders WHERE created_at >= '2026-10-15 00:00:00'; 看数量是否合理
- 再抽样：SELECT id, status, created_at FROM orders WHERE created_at >= '2026-10-15 00:00:00' LIMIT 5;
- 如果 COUNT(*) 返回几百万，而你本意只改几十条，说明条件写错了
这一步不能跳，尤其在用 ORM 或拼接 SQL 的场景下，生成的 WHERE 往往藏有陷阱（比如漏了 AND tenant_id = ?）。
多表 UPDATE 和子查询 UPDATE 容易踩哪些坑
多表UPDATE 不支持标准 SQL 的 FROM，必须显式 JOIN，且字段引用必须带别名：
- ✅ 正确：UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.status = 'shipped' WHERE c.level = 'vip';
- ❌ 错误：UPDATE orders, customers SET orders.status = 'shipped' WHERE customers.level = 'vip'; —— 缺少 ON 条件，变成笛卡尔积，可能误更新上万行
子查询更新更危险：UPDATE t SET x = (SELECT MAX(y) FROM t) 会触发 ERROR 1093。绕过方法必须包两层：
UPDATE t SET x = (
SELECT max_y FROM (
SELECT MAX(y) AS max_y FROM t
) AS tmp
);
注意内层子查询必须有别名（AS tmp），否则语法报错。
LIMIT 不是安全阀，只是行数限制器
UPDATE ... LIMIT 100 只保证最多改 100 行，不保证这 100 行是你想要的。比如：
UPDATE logs SET processed = 1 WHERE status = 'pending' LIMIT 100;
如果 status 没索引，MySQL 会全表扫描，随机挑前 100 行更新——你本想按时间顺序处理最新日志，结果改了一堆陈年旧数据。
真正可控的方式是结合排序和派生表：
UPDATE logs l
JOIN (
SELECT id FROM (
SELECT id FROM logs
WHERE status = 'pending'
ORDER BY created_at DESC
LIMIT 100
) AS t
) AS t2 ON l.id = t2.id
SET l.processed = 1;
但要注意：ORDER BY 字段必须有索引，否则性能断崖下跌；大表慎用，先 EXPLAIN 看执行计划。
最后提醒一句：sql_safe_updates 开启后，UPDATE 成功返回但 ROW_COUNT() 是 0，这事很常见——条件没匹配到任何行。业务代码里不检查这个返回值，等于把“什么都没改”当成“已经改好了”。
