MySQL触发器无法自动监听列更新，必须用IF NOT (OLD.col <=> NEW.col)准确判断字段是否真变更；因NULL != NULL返回NULL导致条件失效，而<=>可安全处理NULL，避免漏判或冗余日志。
MySQL 触发器无法“只监听某列更新”，但可以用 IF NOT (OLD.col NEW.col) 准确判断该列是否真被修改过——这是最常用、最可靠的写法。
为什么不能用 != 判断列是否变更
因为 NULL != NULL 返回的是 NULL（不是 TRUE），会导致条件失效，漏掉 NULL → NULL 以外的变更（比如 'a' → NULL 或 NULL → 'b'）。
-
是 MySQL 的“安全等于”操作符，NULL NULL返回TRUE，'x' NULL返回FALSE，行为可预测 - 写成
OLD.email != NEW.email在字段含NULL时大概率出错，尤其业务中邮箱允许为空时 - 若必须用
!=，得补全逻辑：(OLD.email != NEW.email) OR (OLD.email IS NULL) != (NEW.email IS NULL)，太冗长且易错
如何在 BEFORE UPDATE 中仅对变更列做响应
典型场景：用户改了 status，才自动更新 updated_at 并写日志；其他列（如 name）更新时不触发。
- 把逻辑包裹在
IF NOT (OLD.status NEW.status)内，而不是直接写在触发器顶层 -
SET NEW.updated_at = NOW()必须放在这个IF块里，否则每次UPDATE都会重置时间戳 - 日志插入也得放同一
IF下，避免无意义的审计记录膨胀 - 示例片段：
DELIMITER $$
CREATE TRIGGER update_order_status_log
BEFORE UPDATE ON orders
FOR EACH ROW
BEGIN
IF NOT (OLD.status <=> NEW.status) THEN
SET NEW.updated_at = NOW();
INSERT INTO order_status_log(order_id, old_status, new_status)
VALUES (OLD.id, OLD.status, NEW.status);
END IF;
END$$
DELIMITER ;多个列都要监控时怎么写才不爆炸
别堆 IF 嵌套，用布尔表达式合并判断更清晰。例如要监控 email 和 phone 任一变更：
- 写成
IF NOT (OLD.email NEW.email AND OLD.phone NEW.phone)，表示“只要有一个不同就进块内” - 如果想区分是哪个列变，再拆成两个独立
IF，各自处理对应逻辑（比如只改email就发验证邮件，只改phone就触发短信校验） - 切忌用
OLD.* != NEW.*—— MySQL 不支持通配符比较，语法直接报错 - 表加了新审计列？必须手动扩写触发器，没有自动适配机制
常见误操作：在 AFTER UPDATE 里改 NEW 或读 OLD
AFTER UPDATE 触发器里，NEW 已不可赋值（SET NEW.xxx = ... 会报错），OLD 虽可读但已无实际意义——数据早已落盘。
- 所有需要“干预更新行为”的逻辑（比如拦截、默认值填充、联动改值）必须放在
BEFORE UPDATE -
AFTER UPDATE只适合纯副作用操作：发消息、写日志、调外部接口（且需注意事务一致性） - 想在更新后“基于新值再改一次本行”？不行——会触发递归调用，MySQL 默认禁止，强行开会有死锁风险
真正容易被忽略的是：触发器里的逻辑一旦写死列名，就和表结构强耦合。上线后加个 nickname 字段，想让它也进审计日志？得人工找到所有相关触发器，逐个补上判断——自动化生成或元数据驱动在这里基本不可行。
