update语句漏写或写错where条件会全表更新，必须通过select预验证、开启sql_safe_updates、分批更新、索引优化及事务控制来防范。
UPDATE语句写错WHERE条件会直接改错全表
不加 WHERE 或 WHERE 条件恒真（比如写成 WHERE 1），MySQL会更新整张表所有行。这是线上事故高发点，尤其在生产环境执行前没做 SELECT 验证时。
实操建议：
- 执行
UPDATE前，先用同样WHERE条件跑一遍SELECT COUNT(*)，确认影响行数合理 - 开发/测试库开启
SQL_SAFE_UPDATES=1（默认开启），它会拒绝没有WHERE或KEY条件的UPDATE/DELETE - 线上变更必须走审批+人工复核，禁止直接粘贴执行
UPDATE多字段时注意赋值顺序和NULL处理
MySQL中 UPDATE t SET a = b, b = a 是原子性交换，但若其中一列是 NULL，结果可能不符合直觉——比如 a = NULL 后再 b = a，b 也会变 NULL，不是“原值交换”。
常见陷阱：
-
SET子句从左到右求值，右边表达式看到的是当前行旧值，左边赋值后新值不影响右边后续字段计算 - 想用旧值做计算，必须显式用变量或子查询，例如：
UPDATE t SET a = @old_b := b, b = @old_a := a（需先SET @old_a = NULL, @old_b = NULL） - 对允许
NULL的字段赋值要明确写col = NULL，不能写col = ''或漏掉——后者可能触发默认值或约束报错
批量更新大表时避免锁表和慢查询
一次更新几百万行，容易导致长时间锁表、主从延迟、甚至OOM。MySQL 5.7+ 默认用行级锁，但范围过大仍会升级为间隙锁或表锁。
稳妥做法：
- 按主键分批次更新，例如：
UPDATE t SET status = 1 WHERE id BETWEEN 10000 AND 19999 AND status = 0，每次控制在 1k–5k 行 - 确保
WHERE条件字段有索引，否则全表扫描 + 锁行 = 雪崩 - 避开业务高峰；监控
SHOW PROCESSLIST和INFORMATION_SCHEMA.INNODB_TRX查长事务 - 考虑用
INSERT ... ON DUPLICATE KEY UPDATE替代部分场景，减少锁竞争
UPDATE返回影响行数不可靠，别依赖它判断逻辑
mysql_affected_rows() 或 mysqli->affected_rows 返回值，在 MySQL 中含义模糊：对单条语句是实际变更行数；但若某行新旧值相同（比如 SET name = 'a' WHERE name = 'a'），它返回 0，即使匹配了 100 行。
所以：
- 不要用影响行数判断“是否找到目标数据”，该用
SELECT先查 - 想确认更新是否生效，要么加
SELECT ... FOR UPDATE显式加锁读，要么在应用层比对前后值 - 开启
sql_mode=STRICT_TRANS_TABLES，能让某些无效更新（如超长字符串截断）直接报错，而不是静默失败
真正难的不是语法，是每次执行前心里得清楚：这次改的是哪几行、为什么必须改、出错了怎么回滚。字段级权限、binlog格式、从库延迟，都会让一个看似简单的 UPDATE 变成排查噩梦。
