mysql自动时间戳不可靠，必须显式声明datetime类型及default current_timestamp on update current_timestamp约束，否则易因时区、版本、引擎或严格模式导致create_time/update_time失真。
因为不显式定义，就等于把时间管理权交给应用层，而线上服务一旦出现时钟漂移、事务重试、批量导入、跨服务写入等场景，create_time 和 update_time 就会失真甚至错乱——这不是“可能”，是必然发生。
MySQL 自动时间戳不是万能的，默认行为会踩坑
很多人以为加个 CURRENT_TIMESTAMP 就万事大吉，但 MySQL 对 TIMESTAMP 和 DATETIME 的默认逻辑完全不同：
-
TIMESTAMP字段在没有显式指定DEFAULT或ON UPDATE时，MySQL 5.6.5+ 会悄悄给第一个TIMESTAMP列加上DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP——你没写，它帮你写了，而且只允许一个字段享受这个“特权”； -
DATETIME在 MySQL 5.6.5 之前根本不支持自动默认值，5.6.5+ 虽然支持，但如果你建表时漏写DEFAULT CURRENT_TIMESTAMP，它就真成 NULL 或 0000-00-00，而不是当前时间； - 更隐蔽的是：如果表里已有
TIMESTAMP字段且已带自动行为，你再用ALTER TABLE ... ADD COLUMN update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，MySQL 会直接报错Invalid default value for 'update_time'（尤其在 strict mode 下）。
应用层维护时间戳，线上出问题根本没法回溯
当业务代码手动拼 SQL 插入 NOW() 或 LocalDateTime.now()，问题立刻浮现：
- 不同服务部署在不同时区的机器上，
create_time可能相差数小时，JOIN 或分页排序全乱； - 批量导入脚本绕过 ORM，忘记设时间字段，导致大量记录
create_time为NULL或默认零值； - 事务中先 INSERT 后 UPDATE，但应用层两次都用了
now()，update_time和create_time可能完全一致，失去“最后修改”意义； - 微服务 A 写入数据，微服务 B 修改，如果各自生成时间戳，
update_time就不再反映真实更新顺序，审计日志失效。
必须显式声明类型、默认值和更新规则
正确姿势不是“加个时间字段”，而是按字段语义明确约束：
-
create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'—— 用DATETIME避开TIMESTAMP的 2038 年限制和时区转换副作用； -
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最后更新时间'—— 必须同时写全DEFAULT和ON UPDATE，否则 MySQL 5.7+ 严格模式下建表失败； - 如果表已有数据，新增字段时不能只用
ADD COLUMN，得补上NOT NULL和默认值，否则老记录该字段为NULL，后续所有WHERE update_time > ?查询都会漏掉这批数据； - 注意：MySQL 8.0.28+ 支持
DEFAULT CURRENT_TIMESTAMP+ON UPDATE NOW()组合，但NOW()和CURRENT_TIMESTAMP在语义上等价，建议统一用后者，避免混淆。
最常被忽略的一点：即使你用对了语法，如果表引擎不是 InnoDB，或 MySQL 配置了 explicit_defaults_for_timestamp=OFF（旧版本默认），自动时间行为仍可能降级或异常。上线前务必在同版本生产配置的测试库中实测插入和更新两条语句，看时间字段是否如预期变化。
