UPDATE语句不会自动跳过未变更字段，必须显式用WHERE条件排除（如nickname != 'new_name'），或应用层先查后判再更新，以避免无效写入和触发器误触发。
UPDATE 语句本身不会自动跳过未变更的字段值
SQL 标准里没有“仅当值改变才更新”的内置开关。执行 UPDATE table SET col = 'x' WHERE id = 1，哪怕当前 col 就是 'x'，这条语句依然会触发行锁定、写入 WAL（如 PostgreSQL）、生成 binlog（如 MySQL），甚至可能激活 ON UPDATE CURRENT_TIMESTAMP 或触发器。这不是“无效操作”，而是真实发生的写操作。
用 WHERE 子句显式排除不变的行
最常用、最可控的方式：把“值是否变化”逻辑搬到 WHERE 条件里。比如想更新用户昵称但只在新昵称不等于当前值时才改：
UPDATE users SET nickname = 'new_name' WHERE id = 123 AND nickname != 'new_name';
注意点：
-
!=在 NULL 场景下失效——nickname != 'new_name'遇到nickname IS NULL会返回UNKNOWN，整行被过滤掉。稳妥写法要加IS DISTINCT FROM（PostgreSQL）或手动处理 NULL（MySQL/SQLite） - MySQL 中可用
IFNULL(nickname, '') != 'new_name'，但要注意类型隐式转换风险 - 如果更新多个字段，条件得写成
(a != 'v1' OR b != 'v2')，而不是a != 'v1' AND b != 'v2'——后者是“所有字段都变了才更新”，通常不是你想要的
应用层先 SELECT 再判断再 UPDATE（“select-then-update”）
适合逻辑复杂、涉及多字段比对、或需要精确控制并发行为的场景。典型流程：
SELECT id, nickname, updated_at FROM users WHERE id = 123;
拿到结果后，在代码里判断：if current.nickname != new_nickname: 再发 UPDATE。好处是逻辑清晰、可读性强；坏处是多一次网络往返，且存在竞态窗口（两次查询之间别人可能已改）。
缓解竞态的方法：
- 加
FOR UPDATE锁（PostgreSQL/MySQL InnoDB）：SELECT ... FOR UPDATE，确保后续 UPDATE 能原子执行 - 用带版本号的乐观锁：
UPDATE users SET nickname='x', version=2 WHERE id=123 AND version=1，检查ROW_COUNT()是否为 1
触发器或存储过程封装“智能更新”逻辑（慎用）
某些数据库支持在触发器里拦截并丢弃无实质变更的 UPDATE。例如 PostgreSQL 可写一个 BEFORE UPDATE 触发器函数，对比 OLD 和 NEW 记录：
IF OLD.nickname IS NOT DISTINCT FROM NEW.nickname THEN RETURN NULL; -- 跳过本次更新 END IF;
但要注意：
- 触发器无法阻止 WAL 写入或行锁申请，只是跳过实际修改，性能收益有限
- MySQL 不支持在触发器中“取消”UPDATE（只能报错或改 NEW 值），所以这条路基本走不通
- 调试和排查成本高，容易掩盖真实意图，团队协作时易引发困惑
真正难的不是“怎么写条件”，而是厘清“谁该负责判断变更”——是数据库层兜底，还是应用层明确决策？后者通常更透明、更易测试，也更容易应对字段级权限、审计日志等延伸需求。
