数据库时间戳存取的那些坑

周四深夜，办公室里的中央空调早就停了只剩下几台显示器发出的微弱嗡鸣声，混杂着硬盘读写时偶尔传来的咔哒声。窗外下着雨，雨滴砸在空调外机上发出闷闷的啪嗒声，像是有人在敲打着铁皮，催促着这栋楼里Zui后几个不肯离开的人。

小汐关上电脑，站起来伸了个懒腰。她走过我身边时轻轻拍了拍我的肩膀："谢了。"她的头发松松地扎着，有几缕Yi经从发圈里滑了出来垂在耳边。她眨了眨眼，睫毛在灯光下投下细小的影子。

"你知道 TIMESTAMP Zui多Neng存到哪一年吗？"小汐抬起头kan着我，眼神里写满了不解。我愣了一下"这个……"我有些尴尬地挠了挠头，"好像是 2038 年？"她点了点头，"对，2038 年。我们的系统Ru果活过那一年，这个字段就会出问题。"

阿辰在旁边喝了口茶，淡淡地说："这才是前后端该有的协作方式。"他端着保温杯走过来身上还披着那件常年不离身的灰色冲锋衣。眼镜在灯光下反着光，让人kan不清他的眼神，但从他嘴角那一丝若有若无的笑意，我知道他肯定又要讲大道理了。

"你把 TIMESTAMP 想象成超市里的鲜牛奶"，他指着白板上的图说"保质期短，而且对环境hen敏感——温度变了它就变质了。你的服务器从北京迁到伦敦，它存的时间就会跟着变，因为它会自动根据服务器时区转换。"

"而 DATETIME"，阿辰画了第二个图，"就像真空包装的食品。保质期长，不受环境影响。不管你把它放在哪个时区的服务器上，它存的值dou不会变。而且这个 hen关键——它表示小数点后保留 3 位，也就是毫秒。"

❌ 坑1：前端 13 位时间戳直接存入 TIMESTAMP

"你传给我的时间戳是 10 位的，"小汐轻叹了口气，用鼠标在控制台里划了一下"但我前端用的是 13 位毫秒时间戳。Date.now 返回的就是 13 位。你给我 10 位，我只Neng自己乘以 1000 补成 13 位，但这样毫秒位永远是 000，同一秒内的操作根本排不了序。"

// 前端创建时间戳的标准Zuo法
const now = Date.now;
console.log; // 输出：1634567890123
// 但后端返回的是这个
const serverTime = 1634567890; // 10 位
const timestamp = serverTime * 1000; // 只Neng硬补成 1634567890000
// 问题：同一秒内的所有操作，毫秒位dou是 000，无法区分先后

统一用 UTC，时区问题交给应用层

"geng重要的是"，阿辰继续说"Ru果用 DATETIME + UTC 的方案，前后端就完全打通了。前端传 13 位时间戳过来你转成 DATETIME 存进数据库。读出来时再转回 13 位返回给前端。精度一点不丢。"

-- 第一步：从 TIMESTAMP 升级为 DATETIME
--  表示保留 3 位小数，即毫秒精度
ALTER TABLE `user_actions`
MODIFY COLUMN `created_at` DATETIME NOT NULL DEFAULT '-- ::';
-- Ru果你还有 updated_at 字段，也一起改了
-- ALTER TABLE `user_actions`
-- MODIFY COLUMN `updated_at` DATETIME NOT NULL;

核心是两个工具函数：13 位时间戳 ↔ DATETIME 的双向转换。

const dayjs = require;
const utc = require;
dayjs.extend;
// =========== 转换工具函数 ===========
/**
 * 前端 13 位毫秒时间戳 → 数据库 DATETIME 格式
 * @param {number} timestamp - 13 位毫秒时间戳，如 1634567890123
 * @returns {string} - 如 "2021-10-18 14:30:00.123"
 */
function timestampToDb {
    return dayjs.utc.format;
}
/**
 * 数据库 DATETIME 格式 → 前端 13 位毫秒时间戳
 * @param {string} datetime - 如 "2021-10-18 14:30:00.123"
 * @returns {number} - 
 */
function dbToTimestamp {
    return dayjs.utc.valueOf;
}

代码改完，我重启了服务。小汐迫不及待地刷新页面。

她快速滚动列表，那些密密麻麻的操作记录按照时间顺序整整齐齐排列，不会再像之前那样同一秒内乱序。

“kan，” 我指着代码说“你前端传过来 1634567890123 ，我用 timestampToDb 转成 '2021-10-18 ::' 存进数据库。读出来时用 dbToTimestamp 转回 1634567890123 返回给你。毫秒位的 123完整保留下来。”

“而且你kan控制台，” 她打开开发者工具，“你返回给我的直接就是位时间戳： 1634567890123 、 1634567890456 …… 我前端不用Zuo任何额外处理，直接用 new Date 就Neng转成本地时间显示。”

“这才是我们应该有的协作方式，” 阿辰微笑着说“前后端统一标准、数据精确传递，这才是高质量开发该有的样子。”

办公室里突然安静下来只有键盘敲击和屏幕滚动的声音。我们dou知道，这次深夜重构，让我们的系统变得geng加健壮，为未来打下了坚实基础。

“早点休息吧，” 阿辰Zui后说了一句，然后转身离开。

窗外的雨还在下但声音Yi经变得hen轻，像是在为这场技术革新默默见证。

*这里是《深夜代码》，我们下期见。

❖ MySQL 数据库中选择合适的时间存储类型至关重要 MySQL 中的 TIMESTAMP 和 DATETIME 各有优劣：

TIMESTAMP

存储范围较小

受时区影响，会自动转换

存储空间较小

DATETIME

存储范围geng大

不受时区影响，保持原值

可精确到毫秒

Zui佳实践使用 DATETIME 存储高精度时间，并统一使用 UTC 时间 进行前后端交互。

通过将数据库字段从 TIMESTAMP geng新为 DATETIME ，并配套实现前后端 13位时间戳 与 DATETIME 的双向转换，我们彻底解决了因精度丢失和时区问题导致的各种诡异Bug，让系统变得geng加可靠，为未来的 奠定了坚实基础。

关注我，和小豆一起在掘金学习geng多开发技巧！

希望这篇文章Neng帮助你在项目中geng好地处理 MySQL 时间存储问题。如有geng多疑问或建议，请随时交流！