触发器里必须用CURRENT_TIMESTAMP而非NOW()，因其是默认值表达式、兼容性更好且避免ERROR 1442；UPDATE触发器需加WHERE条件判断字段是否真变化，防止无限递归；INSERT和UPDATE触发器必须分开定义。
触发器里用 NOW() 还是 CURRENT_TIMESTAMP？
MySQL 中 CURRENT_TIMESTAMP 和 NOW() 在大多数情况下行为一致，但触发器里必须用 CURRENT_TIMESTAMP（或其等价写法 CURRENT_TIMESTAMP()），否则在某些版本或严格模式下可能报错 ERROR 1442: Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。这是因为 NOW() 被解析为函数调用，而触发器上下文对函数调用有更严限制。
-
CURRENT_TIMESTAMP是默认值表达式，允许直接赋值给列，兼容性更好 - 若使用
datetime类型字段，推荐显式声明为DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，再配合触发器补位（比如需要兼容旧表结构） -
TIMESTAMP类型字段自带隐式行为，但一旦设为NULL或显式插入NULL，会丢失自动更新能力，这点容易被忽略
UPDATE 触发器必须加 WHERE 条件判断吗？
必须。不加判断会导致无限递归：触发器修改行 → 再次触发自身 → 再次修改 → …… 最终报错 ERROR 1442。核心原则是只在真正需要更新时才赋值。
- 检查旧值和新值是否不同：
IF OLD.updated_at != NEW.updated_at THEN SET NEW.updated_at = CURRENT_TIMESTAMP; END IF; - 更稳妥的做法是对比业务字段变化，比如：
IF OLD.status != NEW.status OR OLD.content != NEW.content THEN ... - 不要依赖
OLD.updated_at是否为空来判断——首次插入后该字段已有值，后续更新无法识别“是否真变了” - 如果表没有主键或唯一标识，
OLD和NEW可能不可靠，先确认表结构有效性
INSERT 和 UPDATE 触发器能合并写吗？
不能。MySQL 不支持单个触发器响应多个事件（如 INSERT, UPDATE）。必须拆成两个独立触发器：
-
BEFORE INSERT触发器负责初始化created_at和updated_at -
BEFORE UPDATE触发器只负责更新updated_at（并做变更判断） - 两者命名需区分，例如
trg_orders_before_insert和trg_orders_before_update，避免管理混乱 - 如果误把
INSERT的逻辑塞进UPDATE触发器，会导致新增记录的created_at被覆盖为当前时间，丢失原始创建时间
PostgreSQL 怎么写等效触发器？
PostgreSQL 语法差异大，不能直接套用 MySQL 写法。关键点：
- 函数体必须用
plpgsql语言，且需先CREATE FUNCTION，再CREATE TRIGGER绑定 - 时间字段赋值用
NOW()（PostgreSQL 中它是安全的），不是CURRENT_TIMESTAMP（虽可用，但习惯用NOW()） - 必须显式
RETURN NEW，否则触发器不生效 - 示例片段：
CREATE OR REPLACE FUNCTION update_updated_at_column()<br>RETURNS TRIGGER AS $<br>BEGIN<br> NEW.updated_at = NOW();<br> RETURN NEW;<br>END;<br>$ language 'plpgsql';
- PostgreSQL 对触发器执行顺序更敏感，如果同一字段被多个触发器修改，顺序由创建时间决定，建议一个字段只配一个触发器
触发器看似简单，但跨数据库移植时字段类型、时间函数、递归控制、甚至 SQL_MODE 都可能让逻辑失效。上线前务必在目标环境用真实数据跑一遍 UPDATE + INSERT + NULL 边界场景。
