UPDATE会悄悄修改TIMESTAMP字段，因旧版MySQL自动补全DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP；需用ALTER TABLE显式定义行为，禁用自动更新应改用DATETIME或设NULL。
为什么UPDATE会悄悄改掉你的timestamp字段
MySQL的TIMESTAMP列在旧版本（5.6及之前）或explicit_defaults_for_timestamp=OFF时，只要表中存在至少一个TIMESTAMP列且未显式声明DEFAULT和ON UPDATE，它就会被MySQL“自动补全”为DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。哪怕你建表时只写了t1 TIMESTAMP，后续任何UPDATE（哪怕只改其他字段）都会触发该列更新——这常导致“首次注册时间”被覆盖成“最后登录时间”这类逻辑错误。
用ALTER TABLE精准控制DEFAULT和ON UPDATE行为
别依赖隐式规则，直接用ALTER TABLE重定义列的语义。关键点是：显式声明你想要的组合，不声明的就等于放弃控制权。
- 要记录创建时间且永不变更 → 声明
DEFAULT CURRENT_TIMESTAMP，**不加**ON UPDATE - 要记录最后更新时间 → 必须同时声明
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 要完全禁用自动更新（比如存业务固定时间戳）→ 改用
DATETIME，或设为NULL并显式赋值
示例：把原错用的created_at从自动更新改为只初始化：
ALTER TABLE users MODIFY COLUMN created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP;
注意：执行前务必确认该列当前无ON UPDATE CURRENT_TIMESTAMP残留，可用SHOW CREATE TABLE users检查DDL输出。
explicit_defaults_for_timestamp=ON不是万能解药
设SET @@global.explicit_defaults_for_timestamp = ON后，新创建的表确实不再自动补全ON UPDATE，但**已有表结构不受影响**。已存在的列仍保留建表时隐式生成的ON UPDATE逻辑，必须通过ALTER TABLE ... MODIFY COLUMN显式清除。
- 执行
SET命令只影响后续新建连接和新表 -
SHOW VARIABLES LIKE 'explicit_defaults_for_timestamp'查的是当前会话值，不是全局生效状态 - MySQL 8.0+默认为
ON，但迁移老库时旧表仍需手动修正
DATETIME比TIMESTAMP更可控，但要注意时区
如果业务需要稳定的时间值（如合同签署时间、订单创建时间），DATETIME是更安全的选择——它不随UPDATE自动变，也不做时区转换。但得记住：
-
DATETIME存储的是字面值，不转时区；TIMESTAMP存UTC、读本地时区 - 跨时区应用若混用两者，可能造成“同一时间点显示不同”
-
TIMESTAMP上限是2038年，超限写入直接报ERROR 1292；DATETIME支持到9999年
真正容易被忽略的点：很多ORM框架（如MyBatis、Hibernate）默认把Java LocalDateTime映射到DATETIME，而ZonedDateTime才对应TIMESTAMP。没对齐类型映射，时区问题会在上线后突然爆发。
