php - MySQL 日期时间和时间戳字段是否比 Unix 时间戳整数更适合 PHP 应用程序？

Question

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

MySQL DATETIME vs TIMESTAMP vs INT performance and benchmarking with MyISAM

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

但是，在文章的结尾，他又做了一个不使用 MySQL 函数的测试，您突然发现，当按 unix 时间戳搜索时，直接 INT 的速度是两个 MySQL 选项的 2 倍。

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

这给我留下了以下内容:

1. 以 INT 形式存储的 Unix 时间戳是 更快，占用更少的空间，并且工作 原生基于 PHP 的 time() 计算。

2. MySQL 日期类型更适合 来自 MySQL 的操作和逻辑 边。

3. 暂时Unix和 MySQL 时间戳仅在 2037 这意味着您必须使用 较大日期的日期时间字段 future 。

4. 像 date = NOW() 这样的 MySQL 命令可能会滞后 使用复制导致数据不一致。

所以将其应用到现实生活中我们就会看到答案 这些结果给出了大多数真正的 DBA 会使用更好的引擎，如 PostgreSQL - 是否有 arny

但是，大多数达到使用数据库逻辑级别的应用程序可能会使用 PostgreSQL。这意味着我们所有其他程序员只将 MySQL 用作我们数据的存储 jar (你知道这是真的)，这使得保持字段小、快、UNIX INT 看起来实际上是最佳选择。

那么大家怎么看呢？

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

Answer 1

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

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

但是，如果您使用的是 PHP，则这可能没有实际意义:PHP 在其大部分日期和时间函数中都对日期和时间使用 unix 时间戳，除非您使用的是 64 位版本，否则它将具有相同的限制。

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

如果你关心的话。将日期作为 unix 时间戳放入 INT 字段中并不是 self 描述的；如果不以适当的方式转换数据，您将无法查看数据。但这可能对您没有影响。

另一方面，假设您使用的是 PHP，那么一旦您将时间转换为 PHP，您就必须将它转换回 Unix 时间戳，无论如何才能用它做任何有用的事情，因为对于 PHP， Unix 时间戳是原生的。

编辑:

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