MySQL的日期时间和时间戳字段比Unix时间戳ints更好吗？

Question

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

MySQL日期时间vs时间戳与INT性能以及使用MyISAM进行基准测试

在阅读这篇文章时，您开始有这样的想法:使用int只是一种浪费，您应该使用MySQL、Datetime或时间戳列类型。

然而，在本文的末尾，他又做了一次不使用MySQL函数的测试，您突然发现，在使用unix时间戳进行搜索时，直INT的速度是两个MySQL选项的2倍。

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

这使我有以下几点：

1. 以INT形式存储的Unix时间戳速度更快，占用的空间更少，并且本机使用PHP的基于时间()的计算。
2. MySQL日期类型更适合MySQL端的操作和逻辑。
3. 就目前而言，Unix和MySQL时间戳只能工作到2037年，这意味着将来必须对较大日期使用日期时间字段。
4. MySQL命令(如date = NOW() )在使用复制时可能会滞后，导致数据不一致。

所以把这个应用到现实生活中，我们看到了这样的答案，考虑到大多数真正的DBA会使用更好的引擎，比如PostgreSQL -有arny吗？

但是，大多数达到使用DB逻辑级别的应用程序都可能与PostgreSQL兼容。这意味着，我们所有其他程序员只对数据使用MySQL作为存储池(您知道这是正确的)，这使得使字段保持较小、快速，UNIX看起来实际上是最好的选择。

你们觉得怎么样？

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

Answer 1

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位问题。感谢查尔斯在下面的评论中指出了一个很好的使用方法。

Answer 2

我总是喜欢以mySQL格式存储日期，因为这样可以简化查询中的比较。mySQL也有一些很好的日期格式化选项：http://www.dan.co.uk/mysql-date-format/

对不起，我应该补充一句，我真的不知道哪个是更有效的速度--这是你问题的一个重要部分。

Answer 3

我喜欢将所有的逻辑保持在一个单一的、高级别的域中(这是用php编写的应用程序)。MySQL是一个储罐--它应该留在这里。我更喜欢使用一个类，比如http://www.symfony-project.org/plugins/sfDateTime2Plugin，然后使用->dump()或->get()来达到适当的格式。在应用程序域中编写(并扩展)高级操作比使用静态mysql接口快得多，也容易得多。

PostgreSQL的界面在MySQL上清理。但是我们仍然在这里谈论MySQL，因为它很受欢迎。这就提出了一个重要的考虑。在编写代码或设计系统时，遵守约定通常是有意义的，即使它在计算效率上不如其他较不为人所知的选项。这一点很重要，因为它有利于另一种效率--其他人的可读性。通常，可读性和可理解性低效率比计算效率低导致了更大的业务开销(和时间)。

不过，我完全支持尝试INTs。请试一试，把你的发现写下来。

干杯