绝大多数业务场景下，TIMESTAMP 比 INT 更合适；仅当需跨数据库兼容、规避2038年问题且能接受应用层强干预时才选INT。INT存时间戳导致SQL不可读、丧失内置日期函数支持、索引优化不准、无毫秒支持；TIMESTAMP虽有时区自动转换和2038年限制，但DATETIME在无需时区转换时更稳定、范围大、支持毫秒、行为可控。
直接说结论：绝大多数业务场景下，TIMESTAMP 比 INT 更合适；只有当你明确需要跨数据库兼容、或必须规避 2038 年问题、且能接受应用层强干预时，才考虑 INT 存 UNIX 时间戳。
为什么别用 INT 存时间戳（除非真有硬需求）
用 INT 存秒级 UNIX 时间戳看似省空间、计算快，但代价是把本该由数据库承担的时间语义完全推给应用层：
- 所有时间比较、范围查询（如
WHERE log_time > 1716415740）都失去可读性，SQL 变成“数字谜题”，维护成本陡增 - 无法直接使用 MySQL 内置函数做日期运算，比如
DATE_ADD()、YEAR()、TIMEDIFF()，必须先套一层FROM_UNIXTIME(log_time)，性能和可读性双降 - 索引仍可用，但优化器对
INT字段的统计信息不如原生时间类型准确，尤其在复杂 JOIN + 时间过滤组合下容易选错执行计划 - 毫秒支持为零——
INT本身不带精度，若存毫秒需用BIGINT，又失去“小整数”优势
TIMESTAMP 的真实行为和常见误判
很多人以为 TIMESTAMP “自动转时区”是优点，其实它是一把双刃剑，关键看你怎么用：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 插入时不显式指定时区，MySQL 会按当前会话
time_zone将值转为 UTC 存储；查询时再按会话时区转回本地时间——这意味着同一行数据，在不同时区连接下查出的值不同 -
TIMESTAMP的默认行为依赖全局或会话级time_zone设置，一旦 DBA 调整了服务器时区（比如从+08:00改成SYSTEM），历史数据的显示值可能集体偏移 - 它的有效范围被钉死在
'1970-01-01 00:00:01'到'2038-01-19 03:14:07'（UTC），2026 年已进入倒计时阶段，金融、IoT 等长生命周期系统需警惕 - 支持小数秒（如
TIMESTAMP(3)），但存储开销从 4 字节涨到 7 字节，与DATETIME(3)持平，此时时区优势不再明显
DATETIME 往往才是更稳的选择
当你的业务不需要自动时区转换，或者你已在应用层统一处理时区（比如全站用 UTC 存储、前端按用户偏好渲染），DATETIME 实际上比 TIMESTAMP 更可控：
- 值就是你插入的那个字面量，不随服务器或会话时区变化——
INSERT INTO t VALUES ('2026-05-22 14:30:00')，查出来永远是这个字符串（忽略小数秒精度差异） - 范围极大（
'1000-01-01'到'9999-12-31'），彻底避开 2038 问题 - 支持毫秒（
DATETIME(6)），且无论是否启用，固定占 8 字节，空间可预期 - 允许设置默认值为
CURRENT_TIMESTAMP（MySQL 5.6.5+），也能触发ON UPDATE CURRENT_TIMESTAMP，功能不输TIMESTAMP
真正容易被忽略的是：TIMESTAMP 和 DATETIME 在建表时若未显式声明 NOT NULL，MySQL 可能悄悄加 DEFAULT CURRENT_TIMESTAMP 或其它隐式行为，尤其在旧版本中容易引发意外。务必检查 SHOW CREATE TABLE 输出，而不是只看 CREATE 语句。时区策略一旦定下，就别在运行中随意改 time_zone，否则等于主动制造数据歧义。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
