漏写 where 会导致 mysql 全表更新，因 update 不校验 where 存在性；必须启用 sql_safe_updates=1 并配合 select 验证、事务包裹及索引驱动的分批更新来防范。
为什么漏写 WHERE 会直接更新全表
MySQL 的 UPDATE 语句不校验 WHERE 是否存在，只要语法合法就执行。漏写 WHERE 不会报错，而是静默地把整张表所有行的指定字段设为同一值——比如 UPDATE users SET status = 'inactive' 会让全部用户状态变 inactive。这不是“删数据”，但业务影响等同于炸库。
必须开启 SQL_SAFE_UPDATES=1
这是最硬核的兜底机制，不是可选项。它要求 UPDATE 或 DELETE 必须满足：带 WHERE 且至少一个条件字段是主键或索引列；或带 LIMIT；或两者都有。否则直接报错 Error 1175: You are using safe update mode。
- 会话级启用：
SET sql_safe_updates = 1（当前连接生效） - 全局级启用：
SET GLOBAL sql_safe_updates = 1，或在my.cnf中加sql_safe_updates=1并重启 - 确认是否生效：
SHOW VARIABLES LIKE 'sql_safe_updates'，返回ON才算成功
写 UPDATE 前强制用 SELECT 验证 + 事务包裹
即使开了安全模式，也不能跳过人工验证。真实线上事故里，很多是 WHERE 字段名拼错（如 user_id 写成 userid），导致条件永远不匹配，实际变成无条件更新。
- 先跑对应
SELECT：比如要执行UPDATE orders SET paid = 1 WHERE order_id = 123，先查SELECT * FROM orders WHERE order_id = 123确认目标存在且唯一 - 生产环境务必用事务：
BEGIN; UPDATE ... ; SELECT ROW_COUNT();—— 看返回影响行数是否符合预期，再决定COMMIT还是ROLLBACK - 别信 GUI 工具的“安全提示”：有些客户端只检测语句里有没有
WHERE字样，不验证其有效性
真要全量更新，必须分批 + 索引驱动
业务确实需要改全表（比如补默认值），不能靠关安全模式硬来。否则 InnoDB 会锁住所有聚簇索引记录，其他查询全被阻塞。
- 先预估范围：
SELECT COUNT(*) FROM t WHERE col IS NULL - 用主键/索引字段切片，避免
LIMIT带来的全表扫描加锁：UPDATE t SET col = 0 WHERE col IS NULL AND id BETWEEN 10000 AND 19999 - 确保
WHERE条件能走索引：别写WHERE DATE(created_at) = '2024-01-01'，应改为WHERE created_at >= '2024-01-01' AND created_at
真正容易被忽略的是：安全模式只拦语法，不拦逻辑错误；而分批更新时若没用主键范围切割，LIMIT 只控制修改行数，不减少锁范围——一次扫几百万行、锁几百万行，照样拖垮数据库。
