update语句必须带where，否则会全表覆写；建议先用select验证条件、开启sql_safe_updates、确保where字段有合适索引、避免在where中对字段使用函数。
UPDATE 语句必须带 WHERE，否则全表覆写
不加 WHERE 的 UPDATE 是高危操作，MySQL 不会警告，直接修改所有行。线上误执行 UPDATE users SET status = 0; 这种语句，可能瞬间让全部用户被禁用。
实操建议：
- 执行前先用
SELECT验证条件：比如要更新status = 1的用户，先跑SELECT id, name FROM users WHERE status = 1 LIMIT 5; - 开发环境养成习惯：在 MySQL 客户端里开启安全模式（
SET SQL_SAFE_UPDATES = 1;），这样没带WHERE或WHERE不含主键/索引字段时会报错Error Code: 1175 - 涉及大表更新时，避免
WHERE条件走全表扫描——检查执行计划：EXPLAIN UPDATE ...（注意 MySQL 8.0.19+ 才支持对UPDATE直接EXPLAIN，低版本用等价SELECT替代）
WHERE 条件字段没索引，更新慢还锁表
例如 UPDATE orders SET paid = 1 WHERE created_at > '2024-01-01' AND user_id = 123;，如果 created_at 没索引，MySQL 可能扫完整个分区甚至全表，期间持有行锁或间隙锁，阻塞其他读写。
实操建议：
- 用
SHOW INDEX FROM orders;确认WHERE中的字段是否有有效索引；复合条件优先建联合索引，顺序按「等值匹配 → 最左前缀 → 范围查询」排，比如上面例子更适合(user_id, created_at) - 时间范围更新慎用函数：写成
WHERE DATE(created_at) = '2024-01-01'会让索引失效，应改用WHERE created_at >= '2024-01-01 00:00:00' AND created_at - 大表批量更新别一次性干完：拆成按主键分段，比如
WHERE id BETWEEN 10000 AND 19999 AND status = 0，每次更新 1 万行，降低锁等待和 binlog 压力
UPDATE 多字段时，SET 子句顺序无关，但 NULL 处理要小心
SET 后字段顺序不影响结果，但若某字段设为 NULL，而该列定义是 NOT NULL 且无默认值，就会报错 Error Code: 1048；更隐蔽的是，某些字段类型（如 TIMESTAMP）在设为 NULL 时可能被自动转成当前时间，行为取决于 explicit_defaults_for_timestamp 配置。
实操建议：
- 更新前查表结构：
SHOW CREATE TABLE users;，确认字段是否允许NULL、有无默认值、是否自增 - 避免隐式类型转换：比如
SET score = '95'（字符串）更新INT字段，虽能成功但触发隐式转换，影响性能；统一用对应类型字面量 - 想保留原值就别写进
SET：不要写SET name = name, email = 'a@b.com'，冗余且可能因并发导致意外覆盖
WHERE 条件里用子查询，性能差还可能报错
比如 UPDATE logs SET processed = 1 WHERE id IN (SELECT id FROM temp_queue WHERE batch = '202405');，MySQL 5.6+ 会将子查询转成关联，但若 temp_queue 没索引或数据量大，仍可能慢；更麻烦的是，MySQL 不允许在子查询中直接引用被更新的表，会报 Error Code: 1093。
实操建议：
- 把子查询结果先落临时表：
CREATE TEMPORARY TABLE tmp_ids AS SELECT id FROM temp_queue WHERE batch = '202405';，再UPDATE logs JOIN tmp_ids ON logs.id = tmp_ids.id SET processed = 1; - 确认子查询返回的字段类型和主表匹配：比如
logs.id是BIGINT，但子查询返回的是VARCHAR，会导致索引失效 - 线上禁用未加 LIMIT 的子查询更新，防止内存爆掉——
IN子查询结果集过大时，优化器可能放弃使用索引
真正难的不是语法，是判断 WHERE 条件到底命中多少行、锁哪些索引、会不会拖垮从库同步。上线前拿慢日志和 SHOW PROCESSLIST 对着看，比背一百遍语法管用。
