MySQL的TIMESTAMP字段写入2038年后时间必然失败，因其底层用4字节有符号整数存储Unix时间戳，最大值2147483647秒对应UTC时间2038-01-19 03:14:07，超限即溢出；改用DATETIME是最直接有效的解法。
MySQL 的 TIMESTAMP 字段写入 2038 年之后的时间会失败，这不是配置或版本问题，而是由其底层 4 字节有符号整数存储结构决定的硬限制——改用 DATETIME 是最直接、兼容性最好、无需大改应用逻辑的解法。
为什么 TIMESTAMP 到 2038-01-19 就停了
TIMESTAMP 在 MySQL 中本质是把时间转成自 '1970-01-01 00:00:01' UTC 起的秒数，存在一个 4 字节 INT 里。最大值是 2147483647，对应 UTC 时间 2038-01-19 03:14:07。超过就溢出，变成负数或截断，读出来可能是 '1970-01-01' 或报错 Incorrect datetime value。
这不是 bug，也不是版本没升够——哪怕你用 MySQL 8.0.36，只要字段还是 TIMESTAMP，且运行在标准 x86_64 系统上（目前所有主流 RDS 和自建都如此），这个上限就逃不掉。
网上说“8.0.28 支持 2038 后”是误传：那个版本只修复了部分边界计算逻辑，没改存储结构；官方文档至今未声明 TIMESTAMP 已突破 32 位限制。
ALTER TABLE 把 TIMESTAMP 改成 DATETIME 容易卡住
直接执行 ALTER TABLE t MODIFY c DATETIME 可能失败，尤其当字段带默认值、ON UPDATE 或非空约束时。要分步处理：
- 先确认原字段定义：
SHOW CREATE TABLE t，看有没有CURRENT_TIMESTAMP、NOT NULL、DEFAULT '0000-00-00 00:00:00'这类隐式约束 - 如果字段有
ON UPDATE CURRENT_TIMESTAMP，MySQL 5.6.5+ 的DATETIME也支持，但语法必须显式写出：DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 若原字段允许
NULL，新字段保持NULL；若原字段是NOT NULL但没默认值，改之前得先补默认值，否则ALTER会卡住 - 批量改表时注意锁表现象：MySQL 8.0 默认用
inplace算法，但加ON UPDATE子句可能触发copy表，大表务必在低峰期操作
DATETIME 替代后三个容易忽略的细节
DATETIME 虽然范围大（'1000-01-01' 到 '9999-12-31'），但和 TIMESTAMP 行为不同，容易踩坑：
- 它不自动转时区：存什么显示什么。如果你原来依赖
TIMESTAMP的“客户端时区写入 → 自动转 UTC 存 → 读时再转回本地”，现在就得在应用层统一处理时区，比如全用 UTC 写入 - 占用空间翻倍：
TIMESTAMP是 4 字节，DATETIME是 8 字节。亿级日志表要考虑磁盘和内存成本是否可接受 - 索引效率不变，但排序/范围查询的语义更稳定：因为不随连接时区变化，
WHERE create_time > '2025-01-01'的结果始终一致，不像TIMESTAMP（发布时间是2026年5月29日）
真正难的不是改类型，而是判断哪些字段必须改、哪些可以缓改——比如用户注册时间、合同到期日这类明确要跨 2038 的字段，必须优先处理；而日志表里的 updated_at 如果只是用于最近半年归档，其实还能撑几年。别一上来就全量替换，先筛关键路径。
