MySQL日期时间处理方法：DATE、DATETIME、TIMESTAMP区别与查询

MySQL 日期时间字段看起来简单，但实际项目中很容易踩坑。比如生日应该用 DATE 还是 DATETIME？创建时间应该用 DATETIME 还是 TIMESTAMP？按日期查询时为什么索引失效？跨时区业务又该怎么处理？

日期时间设计关系到数据准确性、查询性能和跨地区展示。本文围绕 DATE、DATETIME、TIMESTAMP 的区别，以及常见查询写法和优化方法做一个完整梳理。

DATE 类型

DATE 只保存日期，不保存具体时间。格式通常是 YYYY-MM-DD。它适合生日、节假日、账单日期、统计日期等只关心日期的字段。

birthday DATE
report_date DATE

如果业务不需要时分秒，就不要使用 DATETIME。字段类型越贴近业务语义，后续查询和维护越清楚。

DATETIME 类型

DATETIME 保存日期和时间，格式通常是 YYYY-MM-DD HH:MM:SS。它适合订单创建时间、文章发布时间、任务开始结束时间等业务时间点。

created_at DATETIME
published_at DATETIME

DATETIME 保存的是字面时间，不会根据时区自动转换。项目里要统一约定使用哪个时区写入和展示。

TIMESTAMP 类型

TIMESTAMP 也保存日期和时间，但它会受到时区设置影响。MySQL 存储时会转换为 UTC，读取时再根据当前时区转换回来。

updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP

TIMESTAMP 常用于记录更新时间、创建时间等系统时间。它的取值范围和时区行为与 DATETIME 不同，跨时区业务中要特别注意。

DATETIME 和 TIMESTAMP 怎么选

如果希望保存业务发生时的字面时间，比如预约的本地时间、会议时间，可以考虑 DATETIME。如果希望记录一个绝对时间点，并希望受数据库时区控制，可以考虑 TIMESTAMP。

很多系统会统一使用 DATETIME，并约定全部按 UTC 或某个业务时区写入。关键不是某个类型绝对更好，而是全项目要统一规范。

默认当前时间

创建时间和更新时间常常需要默认当前时间。

created_at DATETIME DEFAULT CURRENT_TIMESTAMP
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

这样插入数据时会自动写入创建时间，更新记录时会自动更新 updated_at。是否交给数据库自动维护，要看项目规范。

按日期查询

查询某一天的数据时，不建议对字段使用 DATE() 函数，因为这可能导致索引无法有效使用。

WHERE DATE(created_at) = '2026-05-07'

更推荐使用范围查询。

WHERE created_at >= '2026-05-07 00:00:00'
  AND created_at < '2026-05-08 00:00:00'

这种写法更容易利用 created_at 上的索引。

按月份查询

按月份查询也同理，不要在字段上套 MONTH() 或格式化函数。使用起止时间范围更稳。

WHERE created_at >= '2026-05-01 00:00:00'
  AND created_at < '2026-06-01 00:00:00'

范围查询既清晰，也更利于索引优化。

时间索引

如果某个时间字段经常用于查询、排序或分页，可以考虑建立索引。

CREATE INDEX idx_created_at ON orders(created_at);

后台列表常见查询是按状态筛选，再按创建时间倒序排序，这时可以考虑联合索引。

CREATE INDEX idx_status_created ON orders(status, created_at);

时区处理

跨时区系统要统一时间策略。常见做法是数据库统一存 UTC，展示时根据用户时区转换。也有国内业务统一使用 Asia/Shanghai 时间。

无论选择哪种，都要在后端、数据库、前端之间保持一致。最怕一部分按 UTC，一部分按本地时间，最终出现时间差 8 小时之类的问题。

时间戳字段

有些项目会用整数时间戳保存时间，比如秒级或毫秒级 Unix 时间戳。这样跨语言处理方便，但数据库里的可读性较差，日期查询也需要额外转换。

created_ts BIGINT UNSIGNED

如果主要在数据库里做日期筛选和排序，DATETIME 通常更直观。如果主要做跨系统事件流，时间戳也有优势。

避免字符串时间

不要随意用 VARCHAR 保存时间。字符串时间不利于日期计算、范围查询和索引优化，也容易出现格式不统一。

不推荐：created_at VARCHAR(50)

除非是非常特殊的外部原始数据，否则时间字段应该使用日期时间类型或明确的整数时间戳。

常见错误

第一种错误是生日这种纯日期字段使用 DATETIME。第二种错误是时间字段用字符串保存。第三种错误是查询时对字段使用 DATE()、MONTH() 导致索引效果变差。第四种错误是 DATETIME 和 TIMESTAMP 混用却没有统一时区规则。

实践建议

字段只需要日期，用 DATE；需要保存日期和时间，用 DATETIME；需要利用自动更新时间或明确理解时区转换时，可以使用 TIMESTAMP。按日期查询时使用范围条件，避免在字段上套函数。

时间处理最重要的是统一规范。类型选对、时区统一、查询写法正确，后续统计、筛选和排查问题都会轻松很多。