在2038年，UNIX_TIMESTAMP（）是否会因未签名的Int列而失败？

Question

我一直小心翼翼地使用无符号值。因此，我的所有时间戳字段都是未签名的。而不是像你们所有人将在几十年内面对的那样处理2038年的错误，而是在我可能已经死亡或者至少已经长期退休之后，其他人可以处理2108年的问题。

或者我想。然而，我注意到，在我依赖MySQL的超级方便的UNIX_TIMESTAMP（）函数而不是让PHP使用time（）解析查询的任何情况下，我的所有努力都可能完全没用。如果UNIX_TIMESTAMP（）足够聪明（或愚蠢）来包装以便它在这段时间后仍然有用，那将是很好的，但显然它只是返回0.（而且这一次我觉得我因使用时间而感到愚蠢（当让MySQL使用UNIX_TIMESTAMP（）时效率更高。）

在某些情况下，我一直在转换到一个新标准，我称之为'millitime'，这是自Unix纪元存储在64位数字以来的毫秒数。似乎有一个更好的权衡，就是拥有2.92亿年的毫秒级精度，而不是拥有2920亿年的秒数。由于大多数服务器每秒处理大量请求，因此具有这种精确度非常重要，而我强调要考虑管理未来3亿年事件日期的实际应用。 （人类甚至会存在吗？）似乎没有这个标准，所以我认为需要用microtime（）函数用PHP手工解析。

  function millitime () {
    $a = microtime();
    return substr($a, 11).$a[2].$a[3].$a[4];
  }

所以我有几个问题：

1. 这是真的吗？ UNIX_TIMESTAMP（）即使被放入无符号的4字节字段也会失败吗？
2. 您是否期望在2038年之前更新UNIX_TIMESTAMP（）以包装或以其他方式解决此问题，或者MySQL是否会破坏？您认为当这个日期临近时，MySQL将最有可能适应的方式。
3. 当我知道我不需要超过几秒钟的精度并且不需要在2108之后使用系统时，最简单和最有效的无符号替代方案是什么？ MySQL是否具有64位或无符号的等效值，并且仍然可以存储在4字节的字段中？
4. 如上所述生成millitime（）的最佳（最快）方法是放在数据库中还是在PHP中使用？不反对抨击。