应使用IF NOT (NEW.updated_at <=> OLD.updated_at)安全判断时间戳字段是否被修改，该操作符可正确处理NULL；有效期校验必须放在BEFORE UPDATE中拦截非法状态，避免数据已落库导致不一致。
UPDATE 触发器里怎么判断是否改了时间戳字段
触发器不能靠“猜”哪列被更新，必须显式检查 OLD.updated_at 和 NEW.updated_at 是否不同。MySQL 的 BEFORE UPDATE 触发器中，OLD 是原值，NEW 是待写入值——直接比对二者即可，别用 IF NEW.updated_at != OLD.updated_at 这种写法，因为 NULL 参与比较会返回 UNKNOWN，导致逻辑跳过。
正确做法是：
IF (NEW.updated_at <> OLD.updated_at) OR (NEW.updated_at IS NULL) <> (OLD.updated_at IS NULL) THEN
这个表达式能安全处理 NULL，覆盖所有变更场景。
有效期校验逻辑该放在 BEFORE 还是 AFTER 触发器里
必须用 BEFORE UPDATE。因为你要在数据写入前拦截非法状态：比如 expires_at 已过期但用户仍试图更新其他字段，这时就得拒绝整个 UPDATE 操作。若放到 AFTER 里，数据已落库，再抛错会导致事务回滚困难，还可能触发下游监听或缓存更新，造成不一致。
典型校验逻辑包括：
-
NEW.expires_at IS NOT NULL AND NEW.expires_at < NOW()→ 过期时间不能设在过去 -
NEW.status = 'active' AND (NEW.expires_at IS NULL OR NEW.expires_at <= NOW())→ active 状态必须配有效未来过期时间 - 若业务要求“更新时间戳即重置有效期”，则需同步修正
NEW.expires_at（例如设为DATE_ADD(NOW(), INTERVAL 30 DAY)）
触发器里调用 NOW() 会不会导致主从时间不一致
会，而且很隐蔽。MySQL 主从复制默认是 STATEMENT 格式时，NOW() 在从库重放时取的是从库本地时间，不是主库执行时的时间。结果就是：主库写入的 expires_at 值，在从库上可能早于或晚于预期，触发器后续校验或业务查询都可能出错。
解决方法只有两个：
- 把 binlog_format 改成
ROW（推荐），这样NOW()在主库求值后，实际时间戳作为值传到从库，不再二次计算 - 或者彻底避免在触发器里用
NOW()，改用应用层传入确定时间戳（如NEW.updated_at由客户端或 ORM 统一生成并传入）
注意：CURRENT_TIMESTAMP 作为列默认值是安全的，但进触发器参与逻辑运算时，等价于 NOW()，同样受复制格式影响。
触发器修改 NEW 字段后，会不会影响外键或索引约束检查
会，而且顺序是：触发器修改 NEW → 执行外键约束检查 → 执行唯一/主键索引检查 → 最终写入。也就是说，如果你在 BEFORE UPDATE 里把 NEW.expires_at 改成了一个违反 CHECK 约束的值（比如负数），或者改成和另一行冲突的主键，数据库会在触发器之后立刻报错，而不是静默忽略。
所以务必确保触发器内的修正逻辑本身合法：
- 不要绕过已有
CHECK（如CHECK (expires_at > created_at)） - 如果表有
ON UPDATE CASCADE外键，触发器改了被引用列，会连带触发级联动作——这通常不是你想要的，建议这类字段禁止在触发器中修改 - 批量 UPDATE 时，每个行都会单独走一遍触发器逻辑，性能开销不可忽视，高并发下容易成为瓶颈
真正难缠的不是语法，而是触发器介入后，数据状态的“隐式变更”——开发查 bug 时往往先看 SQL，再看应用代码，最后才想起还有个藏在数据库里的触发器悄悄改了值。
