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

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

MySQL DATETIME、TIMESTAMP、INT 性能以及使用 MyISAM 进行基准测试 http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-myisam/

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

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

于是我突然恍然大悟——呃，PHP 应用程序都使用什么？ time()!几乎每个 PHP 应用程序的逻辑都基于 Unix Epoch。这意味着大多数对特定时间结果的查询都是基于 time() 开始的然后转换为可用于 MySQL 的字段.

这给我留下了以下内容：

1. 存储为 INT 的 Unix 时间戳是 速度更快、占用空间更小、工作效率更高 本地基于 PHP 的 time() 计算。

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

3. 目前 Unix 和 MySQL 时间戳仅有效到 2037 这意味着你必须使用 较大日期的日期时间字段 未来。

4. MySQL 命令如date = NOW()可以滞后于 使用复制会导致数据不一致。

因此，将其应用到现实生活中我们就会看到答案 鉴于大多数 DBA 会使用像 PostgreSQL 这样更好的引擎，这些结果是否存在？

然而，大多数使用数据库逻辑级别的应用程序可能会选择 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 时间戳是本国的。

Edit:

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