如何解决phpMyAdmin时区导致的查询结果偏差-phpMyAdmin-PHP中文网

phpmyadmin时间不准根源在mysql时区配置：先查@@global.time_zone，若为+00:00或utc则需设为asia/shanghai；若为system再查system_time_zone；务必修改my.cnf中default-time-zone并重启mysql，且需确保时区表已加载。

phpmyadmin显示时间比服务器慢/快几小时，怎么查根源

直接执行select @@global.time_zone, @@session.time_zone;——如果返回+00:00或utc，而你期望东八区，问题就在这里；如果返回system，接着跑select @@global.system_time_zone;确认系统时区是不是asia/shanghai。别只看now()输出，它受会话时区影响，容易误判。

改MySQL配置文件比在phpMyAdmin里SET有效得多

phpMyAdmin本身不存时区，它只是把MySQL返回的值原样展示。临时执行SET time_zone = '+08:00';只对当前连接生效，刷新页面或换标签页就失效。生产环境必须改配置：

编辑/etc/mysql/my.cnf（Linux）或my.ini（Windows）
在[mysqld]段下加一行：default-time-zone = 'Asia/Shanghai'
重启MySQL：sudo systemctl restart mysql
验证是否生效：SELECT @@global.time_zone;应返回Asia/Shanghai

用字符串名比'+08:00'更稳妥，但前提是MySQL已加载时区表——运行SELECT COUNT(*) FROM mysql.time_zone_name WHERE Name = 'Asia/Shanghai';，结果为0就得先执行mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql。

DATETIME和TIMESTAMP字段对时区的反应完全不同

很多人以为改了MySQL时区，所有时间字段就自动“校准”，其实不是：

PHP 8.5.5

PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。

下载

DATETIME：存啥显示啥，完全不涉及时区转换。改time_zone对它没影响
TIMESTAMP：存入时转成UTC，读取时按当前会话time_zone再转回——所以改会话时区，同一条记录查出来的时间字面值会变
如果你的表用的是DATETIME，且数据原本就是按北京时间插入的，那phpMyAdmin显示的就是对的
如果你用的是TIMESTAMP，又在UTC时区下插过数据，现在改成+08:00，查出来的值会自动加8小时，看起来像“跳变”

导出SQL时报#1298错误，本质是时区名不被识别

phpMyAdmin导出时可能自动生成SET time_zone = "+00:00"，导入时MySQL报#1298 - Unknown or incorrect time zone: '+00:00'，说明目标库没加载时区表，或者配置里用了不支持的写法：

删掉导出SQL文件开头的SET time_zone = ...整行，再导入（最简单）
确保目标MySQL已执行mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
避免在配置里写CST——MySQL里CST默认指美国中部时间（UTC-6），不是中国标准时间（UTC+8）
phpMyAdmin自身配置也可能干扰导出行为：清空phpmyadmin.pma__userconfig表，或重命名config.inc.php让其恢复默认

真正麻烦的不是改配置，而是历史数据已经用错时区存进去了——比如用DATETIME存了UTC时间却当北京时间用，这时候光调time_zone没用，得靠DATE_ADD(created_at, INTERVAL 8 HOUR)批量修正。