最常用防伪更新手段是UPDATE语句末尾加WHERE比较新旧值，需注意NULL比较问题，可用IS DISTINCT FROM（PG/SQL Server）或IFNULL（MySQL）处理。
用 WHERE 子句过滤掉“伪更新”
直接在 UPDATE 语句末尾加 WHERE，比较新旧值是否不同——这是最常用、最轻量的防伪更新手段。数据库只对真正变化的行执行写操作，避免无谓的锁、日志写入和触发器触发。
常见错误是忽略 NULL 比较：直接写 WHERE column != 'new_value' 在 column 为 NULL 时永远不成立（因为 NULL != anything 是 UNKNOWN）。必须显式处理：
WHERE (column IS NULL AND 'new_value' IS NOT NULL) OR (column IS NOT NULL AND 'new_value' IS NULL) OR column != 'new_value'- 更简洁写法（PostgreSQL/SQL Server 支持）：
WHERE column IS DISTINCT FROM 'new_value' - MySQL 可用
WHERE IFNULL(column, '') != IFNULL('new_value', '')，但注意类型隐式转换风险
用触发器拦截无变化的 UPDATE（慎用）
触发器适合需要统一审计、或业务逻辑复杂到无法在应用层判断的场景。但它会增加每次 UPDATE 的开销，且容易掩盖应用层误操作。
关键点在于：在 BEFORE UPDATE 触发器中对比 OLD.column 和 NEW.column，若全部字段未变，就用 RETURN NULL（PostgreSQL）或 SET NEW.id = NULL 并在后续检查中跳过（MySQL 需配合存储过程模拟）。
- PostgreSQL 示例：
CREATE OR REPLACE FUNCTION skip_unchanged_update() RETURNS trigger AS $$ BEGIN IF OLD.col1 IS NOT DISTINCT FROM NEW.col1 AND OLD.col2 IS NOT DISTINCT FROM NEW.col2 THEN RETURN NULL; -- 不执行实际更新 END IF; RETURN NEW; END; $$ LANGUAGE plpgsql; - MySQL 不支持直接取消语句，需改用存储过程封装逻辑，否则触发器只能抛错或静默修改
NEW值，不可靠
应用层做变更检测再决定是否发 UPDATE
把判断逻辑提到代码里，比数据库层更可控，也更容易复用（比如结合 ORM 的脏检查机制）。但前提是应用能准确拿到原始值——不能依赖缓存或本地副本，必须是刚 SELECT 出来的快照。
- ORM 如 Django 的
Model.save(update_fields=[...])本质就是只更新指定字段，但不会自动跳过值未变的情况，仍需手动比对 - 使用
SELECT ... FOR UPDATE加锁后比对再更新，可避免并发覆盖，但会提高锁竞争 - Node.js + pg 示例：
const oldRow = await client.query('SELECT col1, col2 FROM t WHERE id = $1', [id]); if (oldRow.rows[0].col1 !== newValue1 || oldRow.rows[0].col2 !== newValue2) { await client.query('UPDATE t SET col1 = $1, col2 = $2 WHERE id = $3', [newValue1, newValue2, id]); }
UPDATE ... RETURNING 配合应用层判断（PostgreSQL 专属）
利用 UPDATE ... RETURNING * 返回实际被修改的行数和内容，让应用决定后续动作。它不阻止更新执行，但给你“反悔”的机会——比如发现没改任何行，就跳过日志记录或消息推送。
注意：即使 WHERE 条件不匹配导致零行更新，RETURNING 也不会报错，只是返回空结果集。别把它当成“是否执行了更新”的唯一依据，而应结合 rowcount 或返回数据本身判断。
- 执行后检查影响行数：
res.rowCount === 0表示 WHERE 无匹配，res.rowCount > 0但res.rows.length === 0理论上不会发生（除非 RETURNING 为空） - 若需确认“值确实变了”，仍要对比
res.rows[0].col和你传入的新值——因为 WHERE 已确保变化，但 RETURNING 是最终写入后的值，可用于验证
最容易被忽略的是时间戳类字段（如 updated_at）：即使业务字段没变，你可能仍想更新它。这时 WHERE 里就不能简单排除该字段，而要单独处理——比如用 UPDATE ... SET col = ..., updated_at = NOW() WHERE col IS DISTINCT FROM ...，否则 updated_at 永远不会刷新。
