MySQL

测试时间：2023-8

启动MySQL服务后，将系统时间调制2038年01月19日03时14分07秒之后的日期，发现MySQL服务自动停止。

根据最新的MySQL源码（mysql-8.1.0）分析，sql/sql_parse.cc中依然存在2038年千年虫问题

/*
      If the time has gone past end of epoch we need to shutdown the server. But
      there is possibility of getting invalid time value on some platforms.
      For example, gettimeofday() might return incorrect value on solaris
      platform. Hence validating the current time with 5 iterations before
      initiating the normal server shutdown process because of time getting
      past 2038.
*/
if (tries > max_tries) {
     /*
        If the time has got past epoch, we need to shut this server down.
        We do this by making sure every command is a shutdown and we
        have enough privileges to shut the server down

        TODO: remove this when we have full 64 bit my_time_t support
      */
     LogErr(ERROR_LEVEL, ER_UNSUPPORTED_DATE);
     const ulong master_access = thd->security_context()->master_access();
     thd->security_context()->set_master_access(master_access | SHUTDOWN_ACL);
     error = true;
     kill_mysql();
 }

TODO: remove this when we have full 64 bit my_time_t support：表示直到MySQL完成支持64位时间戳时才移除这个限制

PostgreSQL

测试时间：2023-8

测试版本：psql-10.1、psql-15.4

启动postgresql服务后，将系统时间调制2038年01月19日03时14分07秒之后的日期，psql-15.4版服务正常运行，数据库可以正常读写；但是重启服务postgresql失败（也就是说postgresql在2038年后无法正常启动）。psql-10.1服务直接挂掉，不能使用。

日志分析：

从日志上可以看出，调整时间后，重启postgresql，日志中的记录时间有问题；启动过程中一直报“D:/PostgresSQL/15/share/timezone”目录不存在，这个问题可能是postgresql获取时区出了问题（有可能是系统的问题）。

Mariadb

测试时间：2023-8

测试版本：10.8.8，11.1.2-GA（测试日期的最新版）

现象与PostgreSQL类似，调整时间后能正常读写，但是不能重启。（未分析日志）

从Mariadb的官网上，可以查到旧版计划（5.6版本）中就有用关于解决2038年千年虫问题的计划；好像未彻底实时（Mariadb不存在5.6版本）。

总结

距离下一次千年虫还有15年的时间，但愿MySQL能修复这个问题；不过按照Oracle的德性，不排除到了2038年停止MySQL社区版的维护，强制用户升级到企业版（大赚一笔）。

Mariadb、PostgreSQL 未来几年修复千年虫问题的可能性还是比较大的（毕竟已经修复了一部分），我们尽请期待吧。