不能直接用 ALTER TABLE ... MODIFY 改类型，因为 DATETIME 与 TIMESTAMP 底层存储和时区处理机制不同，隐式转换易导致值截断、时区偏移或报错；须通过添加新列、CONVERT_TZ 显式转换、再替换的三步法安全迁移。
为什么不能直接用 ALTER TABLE ... MODIFY 改类型？
MySQL 对 DATETIME 和 TIMESTAMP 的底层存储与语义处理完全不同：DATETIME 是纯值存储（不带时区），TIMESTAMP 则始终按 UTC 存储、读取时转为会话时区。直接 MODIFY 会触发隐式转换，可能导致值被错误截断或时区偏移——比如原值 '2023-10-01 02:00:00' 在夏令时切换点附近可能变成 '2023-10-01 01:00:00' 或报错 Incorrect datetime value。
实操建议：
- 先确认字段无非法值：
SELECT * FROM tbl WHERE col IS NOT NULL AND col '2038-01-19 03:14:07';（TIMESTAMP有效范围受限） - 检查是否被索引/外键/生成列依赖，这些约束在类型变更时会失败
- 若表很大，避免单次
ALTER锁表；考虑用pt-online-schema-change或分批更新
安全转换的三步法：先加列、再赋值、最后替换
核心思路是绕过 MySQL 的隐式转换逻辑，由你控制时区上下文和空值处理。
实操步骤：
- 添加新
TIMESTAMP列：ALTER TABLE tbl ADD COLUMN col_ts TIMESTAMP NULL; - 用
CONVERT_TZ()显式转换（推荐）：UPDATE tbl SET col_ts = CONVERT_TZ(col_dt, '+00:00', @@session.time_zone) WHERE col_dt IS NOT NULL;—— 这确保原DATETIME被当作 UTC 时间处理，再转成当前会话时区对应的时间戳 - 删旧列、改名列：
ALTER TABLE tbl DROP COLUMN col_dt, CHANGE col_ts col_dt TIMESTAMP NULL;
注意：CONVERT_TZ(col_dt, 'SYSTEM', 'UTC') 适用于原 DATETIME 值本就表示本地时间的场景；务必根据业务含义选对源时区。
TIMESTAMP 默认值和自动更新行为必须显式声明
MySQL 5.6.5+ 中，TIMESTAMP 列若未指定默认值，会自动设为 CURRENT_TIMESTAMP 且开启 ON UPDATE CURRENT_TIMESTAMP，这往往不是你想要的。
避免意外行为：
- 建新列时明确写死默认值：
ADD COLUMN col_ts TIMESTAMP NULL DEFAULT NULL - 如果需要保留原
DATETIME的“无默认”语义，绝不能省略DEFAULT NULL，否则 MySQL 会悄悄加上DEFAULT CURRENT_TIMESTAMP - 已有数据迁移后，检查
SHOW CREATE TABLE tbl输出，确认col_ts没带自动生成逻辑
迁移后验证时区敏感性和边界值
转换完成不等于万事大吉。常见漏检点：
- 连接客户端时区变化是否影响读取结果？用
SELECT col_dt, UNIX_TIMESTAMP(col_dt) FROM tbl LIMIT 1;对比前后UNIX_TIMESTAMP值是否一致（该函数返回秒级整数，不受会话时区影响） - 测试夏令时临界点：
SELECT CONVERT_TZ('2023-11-05 01:30:00', 'America/New_York', 'UTC');看是否正确回退一小时 - 应用层 ORM（如 Laravel Eloquent、Django ORM）可能缓存列类型元信息，需重启或清缓存
真正麻烦的从来不是语法，而是原 DATETIME 到底代表“服务器本地时间”“UTC 时间”，还是“用户填写的模糊时间”——这个语义一旦搞错，转换后的 TIMESTAMP 就全盘失准。
