我做过很多非常庞大的MySQL数据库，其中之一是一个数据跟踪应用程序，每天为一些用户记录数百万条记录。
epoch优于datetime的原因：

• int只有4个字节，而datetime有8个字节--对于存储/内存和最终的索引/性能来说更好。
• 大多数服务器端语言在重新格式化数据之前都需要将字符串格式转换为int格式
• 不依赖于时区-使用datetime，您需要转换不使用时区标识符存储的字符串，但只需要知道时区转换为

你可以将日期存储为一个字符串，这会占用大量的空间，MySQL经过优化，可以将Unix时间戳中的日期存储为一个10位数，仅使用4个字节
DateTime类型使用8个字节，所以速度会比epochs慢，但是你可能要考虑到mySQL有20或30个函数可以使用DATETIME类型，所以根据你正在做的事情，你必须考虑转换所需的时间。
直接回答你的问题是没有什么比时代更快！

首先，忘记时间戳。2k 38 epochalypse比你想象的要近。
由于有其他的即时数据类型，在DATETIME中没有时区信息，我们存储BIGINT epochtimemillis并不比UTC DATETIME更糟糕，直到他们（DB制造商）想出一个新的“即时”数据类型尽快给我们给予。
如果你只打算记录瞬间，BIGINT epochimemillis是好的。你可以随时在应用程序中进行日期计算，但要注意，你可能会被迫在应用程序中进行日期计算！（我的意思是，当你不能实现你需要的WHERE子句时，性能非常差）。
我一般喜欢避免疯狂的所有层次摆弄时区，你读过文档吗？这是完全荒谬的。Java在变化，驱动程序在变化，服务器在变化，一堆混乱的属性试图告诉驱动程序和服务器如何处理时区，默认值也会改变（就像8. 0. 23的混乱）。服务器只是没有强制客户端知道它在存储什么。
这也难怪为什么很多开发者会选择逃避这一切，这就是为什么我们想要一个新的64 bbits的“即时”数据类型。如果这意味着继续使用“时间戳”的话，我会很乐意做一个大的迁移--就像驱动程序会对我不变的代码进行无故障处理一样。
有了BIGINT，排序和查找东西的年龄或时间差变得非常容易。不需要解释，只需做整数除以60，3600，1440，86400，无论你需要什么通常的倍数。
使用BIGINT纪元时间米利斯.日期渲染完全是一个表示问题，而不是存储问题。许多api都可以使用它，比如stripe。
做日期测试（组bys小时的一天，其中小时之间0和8，等）可能需要一个虚拟列，让你的UTC做那些花式查询/聚合.无论你觉得有在虚拟列的索引是一样好，作为一个实际的datetime列.特别是围绕DST的变化，这是不容易处理23小时或25小时天.
希望这有助于不要害怕使用BIGINT纪元时间（米利斯）。