mysql触发器中自动填充timestamp字段应优先用current_timestamp而非now()，因其语义更贴近列定义且避免绕过默认行为；字段需设default current_timestamp或允许null以解决insert报错；update触发器中应强制赋值new.updated_at=current_timestamp确保更新。
触发器里用 NOW() 还是 CURRENT_TIMESTAMP？
MySQL 触发器中自动填充 TIMESTAMP 字段，优先用 CURRENT_TIMESTAMP，不是 NOW()。两者在大多数场景下返回值一致，但关键区别在于：当字段定义为 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 时，触发器内显式赋值 NOW() 会绕过该默认行为逻辑，而 CURRENT_TIMESTAMP 在语义上更贴近列定义的“系统当前时间”含义，且在严格模式下更稳定。
实操建议：
- 统一用
CURRENT_TIMESTAMP，避免和表定义中的默认值机制冲突 - 不要在触发器里写
SET NEW.updated_at = NOW();，改用SET NEW.updated_at = CURRENT_TIMESTAMP; - 如果触发器需要兼容 MySQL 5.6 以下版本（已极少见），注意
CURRENT_TIMESTAMP在旧版中可能不支持作为表达式直接赋值，此时退回到NOW()并加注释说明
INSERT 触发器中 NEW.updated_at 赋值失败？检查字段是否允许 NULL
常见错误现象：ERROR 1364 (HY000): Field 'updated_at' doesn't have a default value，即使写了 BEFORE INSERT 触发器给 NEW.updated_at 赋值，仍报错。
根本原因：MySQL 在执行触发器前，已对非空字段做了 NOT NULL 检查；若字段定义为 NOT NULL 且无默认值，又没在 INSERT 语句中显式提供值，就会在触发器执行前就报错——触发器根本没机会运行。
解决办法：
- 字段必须设默认值：
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP - 或允许 NULL：
updated_at TIMESTAMP NULL，再靠触发器保证非空 - 不推荐删掉
NOT NULL又不设默认值，否则 ORM 或应用层容易误判字段可为空
UPDATE 触发器中 updated_at 总是不变？确认是否触发了 UPDATE 操作
现象：执行 UPDATE users SET name='a' WHERE id=1; 后，updated_at 没变。不是触发器写错了，而是 MySQL 的优化机制在起作用：如果新旧值完全相同（包括 NULL 对 NULL），整行不会被标记为“已修改”，触发器里的 BEFORE UPDATE 仍会执行，但 AFTER UPDATE 不一定触发，更重要的是——NEW.updated_at = CURRENT_TIMESTAMP 虽然执行了，但后续因无实际变更，事务提交时可能被跳过写入。
稳妥做法：
- 强制更新时间戳，不管数据是否真变了：
SET NEW.updated_at = CURRENT_TIMESTAMP;放在BEFORE UPDATE中即可 - 不要依赖 “只有数据变化才更新时间戳” 的语义，MySQL 不保证这种行为，尤其配合批量更新或低精度时间类型时
- 如需区分“真更新”和“假更新”，得在应用层或额外字段记录变更标记，触发器做不到可靠判断
触发器 vs 列默认值：什么时候该用哪个？
简单说：能用列默认值（DEFAULT CURRENT_TIMESTAMP / ON UPDATE CURRENT_TIMESTAMP）就别写触发器。触发器是兜底方案，不是首选。
适用触发器的真实场景：
- 需要根据其他字段动态计算时间，比如
status = 'active'时才更新activated_at - 跨表同步时间戳，例如订单表更新时，同步更新用户表的
last_order_time - 兼容老表结构（无法 ALTER 添加
ON UPDATE子句）且不能停机
容易被忽略的点：触发器里调用 CURRENT_TIMESTAMP 是语句开始时间，不是触发器执行时刻；高并发下多条语句在同一毫秒级时间戳，如果业务依赖精确顺序，得额外加 SELECT SLEEP(0.001) 或用 UUID_SHORT() 辅助排序——但这本身已超出时间戳范畴，属于设计权衡了。
