MySQL
测试时间：2023-8
启动MySQL服务后，将系统时间调制2038年01月19日03时14分07秒之后的日期，发现MySQL服务自动停止。
根据最新的MySQL源码（mysql-8.1.0）分析，sql/sql_parse.cc中依然存在2038年千年虫问题
if (tries > max_tries) { 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 未来几年修复千年虫问题的可能性还是比较大的（毕竟已经修复了一部分），我们尽请期待吧。
来源地址：https://blog.csdn.net/qq_27953479/article/details/132535812
