时间数据几乎是所有业务表都绕不开的字段：订单创建时间、日志记录时间、用户注册时间等等。很多团队在建表时随手选一个类型就用，等到数据量上千万、报表查询超时才发现问题。MySQL 中存储时间有多种方案，不同方案在存储开销、查询性能、时区处理上的差别相当大，选型不当还会引发线上事故。这篇文章从类型对比、索引优化、查询写法三个角度，系统地梳理时间数据处理的最佳实践。
一、时间类型怎么选：DATETIME、TIMESTAMP 还是 BIGINT
MySQL 原生提供了 DATE、TIME、DATETIME、TIMESTAMP、YEAR 五种时间类型，实际业务中最常用的是 DATETIME 和 TIMESTAMP，另外也有不少团队习惯用 BIGINT 存 Unix 时间戳。三者的核心差异需要先弄清楚。
DATETIME 占用 8 字节，存储范围从 1000-01-01 00:00:00 到 9999-12-31 23:59:59，它保存的是字面时间值，写入什么就存什么，不受时区影响。TIMESTAMP 占用 4 字节，取值范围只到 2038-01-19 03:14:07（著名的 2038 问题），它的特点是存储时自动转换为 UTC，读取时再按会话时区转换回本地时间。这意味着同一个 TIMESTAMP 字段，不同时区的客户端读出来的值不一样，这在跨时区业务里可能是优势，也可能是隐患。
BIGINT 存时间戳的好处是计算方便、跨语言通用，Java、Go、Python 都能直接处理毫秒时间戳，做时间差运算也快。缺点是可读性差，排查问题时不能一眼看出时间，也无法直接使用 MySQL 的时间函数，需要先用 FROM_UNIXTIME 转换。
-- 三种方式的建表示例 CREATE TABLE t_datetime ( id BIGINT PRIMARY KEY AUTO_INCREMENT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_timestamp ( id BIGINT PRIMARY KEY AUTO_INCREMENT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_bigint ( id BIGINT PRIMARY KEY AUTO_INCREMENT, created_at BIGINT NOT NULL COMMENT '毫秒时间戳' );
选型建议可以总结为：一般业务表优先使用 DATETIME，配合应用层统一时区，行为最可控；如果表数据量极大且对存储空间敏感，TIMESTAMP 可以省一半空间，但要评估 2038 限制；只有需要频繁做时间运算或与缓存、消息队列交互时，才考虑 BIGINT。另外 MySQL 8.0.19 之后支持 DATETIME 和 TIMESTAMP 的小数秒精度，例如 DATETIME(3) 可存毫秒，只多占约 3 字节，比在业务层拼毫秒到字符串里优雅得多。
二、时区处理的常见坑与正确做法
TIMESTAMP 的时区自动换算是新手最容易踩的坑。它的转换依赖 time_zone 系统变量，这个变量分全局和会话两级。如果 JDBC 连接串里带了 serverTimezone 参数，或者应用服务器与数据库时区不一致，就可能出现「写入的时间读出来差了 8 小时」的经典问题。排查时可以先执行下面的语句确认当前状态。
-- 查看当前会话与全局时区 SELECT @@session.time_zone, @@global.time_zone; -- 临时设置会话时区 SET time_zone = '+8:00'; -- 永久设置需修改配置文件 -- [mysqld] -- default-time-zone = '+8:00'
推荐的实践是：整个体系统一使用 UTC 或统一使用东八区，不要混用。使用 DATETIME 时，数据库不做任何换算，应用层负责把用户所在时区转换后再展示；使用 TIMESTAMP 时，务必保证所有连接的 time_zone 一致。需要注意的是，修改 time_zone 不会改变已存储的 DATETIME 数据，但会影响 TIMESTAMP 的读取显示值，所以线上变更时区前一定要评估影响范围。
另一个细节是 DEFAULT CURRENT_TIMESTAMP 与 ON UPDATE CURRENT_TIMESTAMP。这两个属性可以让数据库自动维护创建时间和更新时间，避免应用层遗漏赋值。MySQL 8.0 中一个表可以有多个这样的字段，5.7 及以前只能有一个 TIMESTAMP 字段带默认值，升级时可以利用新特性把 created_at 和 updated_at 都交给数据库维护。
三、时间查询的索引优化与高效写法
时间字段的查询性能，关键在于索引设计和条件写法。最常见的性能杀手是对时间列使用函数，例如 WHERE DATE(created_at) = '2024-05-01'，这种写法会导致索引失效，全表扫描。正确做法是改写成范围条件，让优化器能走索引区间扫描。
-- 错误写法：函数作用在列上，索引失效 SELECT * FROM orders WHERE DATE(created_at) = '2024-05-01'; -- 正确写法：范围条件，可走索引 SELECT * FROM orders WHERE created_at >= '2024-05-01 00:00:00' AND created_at < '2024-05-02 00:00:00';
同理，WHERE YEAR(created_at) = 2024、LIKE '2024-05%' 这类写法也应避免。如果确实需要按月、按天聚合统计，可以在表中增加冗余的日期列（DATE 类型）并建立索引，写入时由应用或触发器填充，查询时直接等值匹配该列，性能远好于对原始时间列做函数运算。
对于按时间范围查询高频的场景，可以把时间列放在联合索引的最左侧。例如查询某用户最近的订单，建立 (user_id, created_at) 的联合索引，既能快速定位用户，又能利用索引内的时间有序性直接取最近 N 条，避免文件排序。
-- 联合索引让查询直接利用索引有序性 ALTER TABLE orders ADD INDEX idx_user_time (user_id, created_at); -- 取某用户最近 10 笔订单，无需额外排序 SELECT * FROM orders WHERE user_id = 10086 ORDER BY created_at DESC LIMIT 10;
当时间数据达到亿级，单表索引和 B+ 树的代价会急剧上升，此时应考虑按时间分区（PARTITION BY RANGE）。分区裁剪能让查询只扫描涉及的分区，历史数据也可以通过删除分区快速清理，比 DELETE 快几个数量级。要注意分区键必须是主键和唯一索引的一部分，这是使用分区表的硬性约束。
-- 按月分区的日志表
CREATE TABLE access_log (
id BIGINT AUTO_INCREMENT,
created_at DATETIME NOT NULL,
ip VARCHAR(46),
PRIMARY KEY (id, created_at)
)
PARTITION BY RANGE (TO_DAYS(created_at)) (
PARTITION p202404 VALUES LESS THAN (TO_DAYS('2024-05-01')),
PARTITION p202405 VALUES LESS THAN (TO_DAYS('2024-06-01')),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
-- 删除整个分区清理历史数据，秒级完成
ALTER TABLE access_log DROP PARTITION p202404;
四、总结
时间数据的处理原则可以归纳为几条：类型上优先 DATETIME，需要毫秒精度就用 DATETIME(3)，跨时区团队统一时区策略；写入上交给 DEFAULT CURRENT_TIMESTAMP 自动维护；查询上避免对时间列套函数，坚持范围条件写法，配合联合索引和必要时的时间分区。这些细节单独看都不起眼，但组合起来往往决定了系统在高并发、大数据量下的表现。建表前多花十分钟考虑时间字段的选型，远比上线后加索引、改类型成本低得多。