问题:PHP 应用程序的 MySQL 日期时间和时间戳字段是否比 Unix 时间戳整数更好?

我正在阅读一篇文章,该文章显示了一些非常好的信息和基准,这些信息和基准关于三种不同的 MySQL 日期/时间存储选项的执行情况。

MySQL DATETIME vs TIMESTAMP vs INT 性能和使用 MyISAM 进行基准测试

在阅读这篇文章时,您开始意识到使用 int 只是一种浪费,您应该改用 MySQL Datetime 或 Timestamp 列类型。

然而,在文章的最后,他又做了一个不使用 MySQL 函数的测试,你突然发现,当通过 unix 时间戳搜索时,直接 INT 的速度是两个 MySQL 选项的 2 倍。

所以我突然明白了 - duh,PHP 应用程序都使用什么? time()! 几乎每个 php 应用程序的逻辑都基于 Unix 纪元。这意味着在特定时间的大多数结果查询都基于 time() 开始_然后转换为使用 MySQL 的字段_。

这给我留下了以下信息:

1. 以 INT 形式存储的 Unix 时间戳更快,占用更少空间,并且可以与 PHP 的基于 time() 的计算一起工作。

2. MySQL Date 类型更适合 MySQL 端的操作和逻辑。

3. 目前 Unix 和 MySQL 时间戳都只在 2037 年之前有效,这意味着您必须使用 datetime 字段来处理未来更大的日期。

4.date = NOW()等 MySQL 命令在使用复制时可能会滞后,从而导致数据不一致。

因此,将其应用到现实生活中,我们会看到这些结果的答案是因为大多数真正的 DBA 会使用像 PostgreSQL 这样更好的引擎 - 有没有

但是,大多数使用 DB 逻辑级别的应用程序可能会使用 PostgreSQL。这意味着我们所有其他程序员只使用 MySQL 作为我们数据的存储罐(你知道这是真的),这使得保持字段小而快,UNIX INT 似乎实际上是最好的选择。

那你们怎么看?

时间戳真的比 MySQL 日期字段更适合 PHP 应用程序吗?

解答

MySQL 的日期格式没有 2038 年的问题。

MySQL 的日期从 1000 年到 9999 年是可靠的,而 Unix 时间戳可能会在 2038 年之后或 1902 年之前搞砸,除非系统中的所有内容都是 64 位的。

但是,如果您使用的是 PHP,这可能没有实际意义:PHP 在其大多数日期和时间函数中使用 unix 时间戳作为日期和时间,除非您使用的是 64 位构建,否则它将具有相同的限制。

您将使用用于此目的的字段类型。

如果你在意。将日期作为 unix 时间戳放入 INT 字段不是自描述的;如果不以适当的方式转换数据,您将无法查看数据。但这对你来说可能没有什么不同。

鉴于您使用的是 PHP,另一方面,一旦您将时间转换为 PHP,您无论如何都必须将其转换回 Unix 时间戳才能对其进行任何有用的操作,因为对于 PHP,Unix 时间戳是本国的。

编辑:

当我写这个答案时,我没有使用 PHP 的 DateTime 类。使用 DateTime 类消除了使用 Unix 时间戳的任何需要,并消除了 32 位/64 位问题。感谢 Charles 在下面的评论中指出了使用它的好方法。