UPDATE语句必须带WHERE条件，否则会无差别修改全表；应先用SELECT验证目标行，启用SQL_SAFE_UPDATES，避免函数作用于索引字段，NULL需用IS NULL判断，并注意外键与触发器的隐式影响。
UPDATE 语句必须带 WHERE，否则全表覆写
不加 WHERE 的 UPDATE 是最常见误操作来源——它会无差别修改整张表所有行。比如执行 UPDATE users SET status = 'inactive';，没加条件，结果所有用户都被设为 inactive。
实际开发中，只要不是明确要批量更新全部数据（极少见），就必须写 WHERE。MySQL 不会主动阻止你删光或改光，它只忠实地执行你的命令。
- 上线前用
SELECT先验证条件：比如要改UPDATE orders SET paid = 1 WHERE id = 123;，先跑SELECT * FROM orders WHERE id = 123;确认目标存在且唯一 - 测试环境务必开启
SQL_SAFE_UPDATES=1（默认开启），它会拒绝没有主键/索引字段参与WHERE的 UPDATE，避免扫全表 - 生产环境执行前，建议加事务包裹：
BEGIN; UPDATE ... ; SELECT ROW_COUNT();，确认影响行数合理再COMMIT
WHERE 条件里别用函数或表达式过滤主键/索引字段
想按时间范围更新？别写 WHERE DATE(created_at) = '2024-05-01'。这会让 MySQL 无法使用 created_at 上的索引，被迫全表扫描，大表可能卡死。
正确做法是把函数移到右边，让左边保持字段原样：
- ❌ 错误：
WHERE YEAR(created_at) = 2024→ 索引失效 - ✅ 正确：
WHERE created_at >= '2024-01-01' AND created_at → 可走索引 - 复合索引要注意顺序：如果
(status, created_at)有索引，WHERE status = 'pending' AND created_at > '2024-05-01'能命中；但反过来WHERE created_at > '2024-05-01'单独用就用不上
多字段更新时，NULL 值要显式判断，不能用 = NULL
很多人写 WHERE field = NULL，结果一条都匹配不到——因为 NULL 在 SQL 里不等于任何值，包括它自己。这是标准 SQL 行为，MySQL 严格遵守。
需要判断空值，必须用 IS NULL 或 IS NOT NULL：
- ❌
UPDATE logs SET processed = 1 WHERE error_msg = NULL;→ 永远不生效 - ✅
UPDATE logs SET processed = 1 WHERE error_msg IS NULL; - 如果字段允许 NULL，又想同时覆盖空字符串和 NULL，得写：
WHERE COALESCE(error_msg, '') = ''，但注意COALESCE也会让索引失效
更新涉及外键或触发器时，小心隐式行为
外表关联字段被更新，可能触发级联动作；有 BEFORE UPDATE 触发器时，甚至可能悄悄改掉你传入的值。
这类问题往往不报错，但结果不符合预期。比如更新 user_id 字段后发现日志里多出几条记录，其实是触发器自动补了 audit 日志。
- 查外键约束：
SELECT CONSTRAINT_NAME, UPDATE_RULE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'your_table' AND REFERENCED_TABLE_NAME IS NOT NULL; - 查触发器：
SHOW TRIGGERS LIKE 'your_table'; - 临时禁用触发器仅限调试：
SET @TRIGGER_CHECKS = FALSE;，但千万别在生产环境长期关
实际写 UPDATE 最容易翻车的地方，不在语法多难，而在「以为自己知道条件怎么写」——比如自作主张用函数包装索引字段、漏看外键级联、或者把 NULL 当普通值去比。这些都不是报错型问题，而是静默错改，等发现时数据已经污染了。
