TIMESTAMP 字段在 MySQL 中受限于 32 位有符号整数存储 Unix 时间戳，上限为 2038-01-19 03:14:07 UTC，溢出后变为负值并跳回 1901 年；改用 DATETIME 可突破该限制但需处理时区、空间和业务逻辑适配。
TIMESTAMP 字段在 MySQL 中确实卡死在 2038-01-19 03:14:07 UTC，这不是配置错误、不是版本太低、也不是 SQL 模式问题——是硬编码在存储结构里的限制，改不了。
为什么 TIMESTAMP 到 2038 就崩了
TIMESTAMP 内部用一个 32 位有符号整数存 Unix 时间戳（秒数），起始点是 '1970-01-01 00:00:01' UTC。最大值 2147483647 秒刚好落到 2038-01-19 03:14:07 UTC。再加 1 秒就溢出成负数，对应时间直接跳回 1901-12-13 左右。
- 哪怕你用 MySQL 8.0.36，只要字段类型还是
TIMESTAMP，这个上限就逃不掉 - 网上说“8.0.28 支持 2038 后”是误传：它只修复了部分边界计算逻辑，没改底层 4 字节存储
- 非严格模式下插入超限值会静默截断为最大值；严格模式则直接报错
Incorrect datetime value
ALTER TABLE 把 TIMESTAMP 改成 DATETIME 的实操要点
直接 ALTER TABLE t MODIFY c DATETIME 很容易失败，尤其带约束时。得按步骤来：
- 先查原定义：
SHOW CREATE TABLE t，重点看有没有CURRENT_TIMESTAMP、ON UPDATE CURRENT_TIMESTAMP、NOT NULL、DEFAULT '0000-00-00 00:00:00'这类隐式行为 - 如果原字段有
ON UPDATE CURRENT_TIMESTAMP，新DATETIME也支持，但必须显式写全：DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 若原字段是
NOT NULL且没默认值，改之前得先补个默认值，否则ALTER会卡住 - 大表操作注意锁：MySQL 8.0 默认用
inplace算法，但加ON UPDATE子句可能触发全表 copy，务必选低峰期执行
DATETIME 替代后必须面对的三个现实
DATETIME 范围大（'1000-01-01' 到 '9999-12-31'），但行为和 TIMESTAMP 完全不同，不能简单一换了之：
- 它不自动转时区：存什么显示什么。如果你原来依赖
TIMESTAMP的“客户端写入 → 自动转 UTC 存 → 读时转回本地”，现在就得在应用层统一处理时区，推荐全用 UTC 写入 - 空间翻倍：从 4 字节涨到 8 字节。亿级日志表要算清楚磁盘和 buffer pool 成本
- 索引效率不变，但排序/范围查询更稳定——因为不再受连接时区影响，语义更可预期
