MySQL时间类型选型：timestamp与datetime实战指南

1. 时间类型选型的核心痛点

MySQL中timestamp和datetime的选型问题，是每个后端开发者都会遇到的经典选择题。我经历过三次线上事故后才真正明白：时间类型选错不是语法错误，而是隐藏在表结构里的定时炸弹。

去年支付系统就曾因为timestamp的时区转换特性，导致跨时区用户的对账时间全部错乱。更棘手的是，这类问题往往在开发环境无法复现，直到生产环境多时区用户访问时才突然爆发。

2. 两种类型的本质差异

2.1 存储机制剖析

datetime在MySQL中固定占用8字节存储，格式为YYYY-MM-DD HH:MM:SS。它就像机械手表——显示什么时间完全取决于你怎么设置，服务器重启、时区变更都不会影响存储的值。

timestamp则占用4字节，存储的是UTC时间戳。可以把它想象成联网的电子表：当你修改时区设置时，所有timestamp字段的显示值都会自动变化。其实际存储的是从'1970-01-01 00:00:01'到当前时间的秒数。

2.2 时区处理实验

我们在同一台服务器上做测试：

sql复制SET time_zone = '+08:00';
INSERT INTO test_time VALUES (NOW(), NOW());

SET time_zone = '+00:00';
SELECT * FROM test_time;

datetime列显示的值保持不变，而timestamp列会显示为减去8小时后的UTC时间。这就是支付系统事故的根本原因——美国用户看到的是UTC时间，而亚洲团队看到的是本地时间。

3. 生产环境选型指南

3.1 必须选用timestamp的场景

1. 需要自动记录数据变更时间的场景：

sql复制ALTER TABLE orders 
ADD COLUMN update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

这是timestamp的杀手级特性，可以自动追踪记录最后修改时间。

2. 分布式系统跨时区同步：
   当纽约和上海的服务器需要显示统一时间时，timestamp的UTC特性反而成为优势。只需要在应用层统一转换为目标时区即可。