Atoms代码生成后修改时间字段类型二次修改做法

MySQL修改时间字段类型需先查清定义，再用MODIFY/CHANGE COLUMN调整；注意NULL约束、ON UPDATE行为、时区转换及应用层ORM同步，避免数据错位或静默失败。

你需要在Atoms代码生成后，把已生成的数据库表中时间字段类型从DATETIME改为TIMESTAMP，或反过来调整精度、时区支持、默认值行为，同时确保已有数据不丢失、应用层读写不受影响。

确认当前字段定义与依赖关系

执行 SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT, EXTRA FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'your_table' AND COLUMN_NAME IN ('created_at', 'updated_at'); 查看原始定义。重点核对：是否含 ON UPDATE CURRENT_TIMESTAMP；是否为 NULLABLE；默认值是 CURRENT_TIMESTAMP 还是 CURRENT_TIMESTAMP()；extra 字段是否含 DEFAULT_GENERATED（MySQL 5.7+ 对自动更新字段的标记）。

【必须先查清原有定义，否则 ALTER COLUMN 可能静默失败或触发意外默认值覆盖】

检查应用代码中是否硬编码了该字段的类型假设——例如 Python 的 SQLAlchemy 模型里写了 sa.DateTime(timezone=True)，但数据库实际是无时区 DATETIME，此时改类型前必须同步修正 ORM 配置。

修改字段类型的具体操作

方法一：使用 MODIFY COLUMN（推荐，语义清晰，兼容性好）

ALTER TABLE your_table MODIFY COLUMN created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP;

这条命令会重定义字段类型、空值约束和默认值，但不改变列名和位置。若原字段允许 NULL，而新定义为 NOT NULL，且表中存在 NULL 值，则执行失败，需先 UPDATE SET created_at = NOW() WHERE created_at IS NULL; 再执行 MODIFY。

方法二：使用 CHANGE COLUMN（适用于需同时改名或调整顺序）

ALTER TABLE your_table CHANGE COLUMN created_at created_at TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

注意：CHANGE 后必须重复写两次字段名（旧名→新名），即使不改名也要照写。ON UPDATE CURRENT_TIMESTAMP 只对 TIMESTAMP 类型生效，对 DATETIME 无效（MySQL 5.6.5+ 对 DATETIME 支持 ON UPDATE，但需显式启用 explicit_defaults_for_timestamp=OFF）。

处理 TIMESTAMP 特有的时区陷阱

第一步：确认 MySQL 服务器时区设置 SELECT @@global.time_zone, @@session.time_zone;

第二步：若业务依赖本地时区（如东八区），且字段改为 TIMESTAMP，MySQL 会将写入值按 session 时区转为 UTC 存储，读取时再转回 session 时区。这意味着：同一行数据，在不同时区连接下 SELECT 出来的时间字符串不同。

第三步：为避免歧义，统一在应用连接串中指定 time_zone='+08:00'，或在建表时显式声明：created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '存储为 UTC，应用层负责时区转换'。

如果原字段是 DATETIME 且你曾用 STR_TO_DATE('2026-08-19 20:56:00', '%Y-%m-%d %H:%i:%s') 手动插入过带时区偏移的字符串，现在改为 TIMESTAMP 后，该值会被当作本地时间转存为 UTC，导致时间错位——此时必须先用 CONVERT_TZ() 校正存量数据。