必须用BEFORE UPDATE，因AFTER执行时数据已写入无法干预；BEFORE可检查OLD.created_at≠NEW.created_at并SET NEW.created_at=OLD.created_at静默还原，或SIGNAL抛错拒绝修改。
触发器该用 BEFORE 还是 AFTER
必须用 BEFORE UPDATE。因为 AFTER UPDATE 触发时数据已经改写完成，再干预毫无意义；而 BEFORE UPDATE 允许你检查并修改即将写入的值，甚至中止操作。
常见错误是误用 AFTER，结果发现 created_at 字段照样被更新——不是触发器没生效，而是它生效得太晚了。
实操建议：
- 只对目标字段（如
created_at）做校验，避免全字段拦截导致其他合法更新失败 - 在触发器里用
OLD.created_at != NEW.created_at判断是否有人试图修改 - 若检测到修改，直接
SET NEW.created_at = OLD.created_at覆盖，而不是抛异常（除非业务明确要求拒绝）
MySQL 中阻止 created_at 被更新的具体写法
MySQL 不支持直接 RAISE ERROR（8.0.16+ 才有 SIGNAL），所以更稳妥的做法是“静默修正”：
DELIMITER $$
CREATE TRIGGER prevent_created_at_update
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.created_at != NEW.created_at THEN
SET NEW.created_at = OLD.created_at;
END IF;
END$$
DELIMITER ;
注意点：
-
users表名和created_at字段名需按实际替换 - 触发器名（
prevent_created_at_update）不能重复，否则创建失败报错ERROR 1359 (HY000): Trigger already exists - 如果表已有大量数据，触发器本身不影响查询性能，但会轻微增加每次
UPDATE的开销
PostgreSQL 怎么实现等效逻辑
PostgreSQL 更严格，推荐用 RAISE EXCEPTION 主动拒绝，而非覆盖：
CREATE OR REPLACE FUNCTION protect_created_at()
RETURNS TRIGGER AS $$
BEGIN
IF OLD.created_at IS DISTINCT FROM NEW.created_at THEN
RAISE EXCEPTION 'created_at is immutable';
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER prevent_created_at_update
BEFORE UPDATE ON users
FOR EACH ROW
EXECUTE FUNCTION protect_created_at();
关键差异：
-
IS DISTINCT FROM比!=安全，能正确处理NULL值比较 - 函数必须先创建，再绑定触发器；顺序颠倒会报错
function "protect_created_at" does not exist - 使用
RAISE EXCEPTION会让应用收到明确错误，比静默覆盖更容易暴露上游 bug
容易被忽略的边界情况
很多人测试时只改 created_at，却忘了这些场景也会意外触发：
- 全字段
UPDATE语句（如UPDATE users SET name='x', created_at=NOW() WHERE id=1），即使你没想改时间，也可能带上旧值或默认值 - ORM 自动生成的更新（如 Django 的
save()、Sequelize 的update()），可能默认包含所有字段，导致created_at被传入 - 某些客户端工具（如 DBeaver、Navicat）执行“编辑行”后保存，会生成带全部列的
UPDATE，极易踩坑
真正保险的做法不是只防字段变更，而是确保建表时就设好约束：created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL，再配合触发器双保险——毕竟触发器管不了 INSERT 时乱填值。
