phpMyAdmin导出SQL时间戳“不正确”本质是MySQL与PHP时区配置错配所致：MySQL需设default-time-zone="+08:00"并重启，PHP需在php.ini中设date.timezone="Asia/Shanghai"并重启Web服务，同时避免导出含SET time_zone语句。
phpmyadmin 导出的 sql 文件里时间戳“不正确”，根本不是导出功能本身格式化错了，而是它忠实地记录了 mysql 返回的原始值——而这个值，已经在读取或写入环节被时区错配污染了。
为什么 NOW() 和查询结果差整小时？
这是最典型的信号：说明 MySQL 服务层的时区没对齐。
-
SELECT NOW(), @@session.time_zone;返回的时间比你本地北京时间早/晚整数小时 → 问题在 MySQL 层 - MySQL 全局时区是
SYSTEM或+00:00，但你的业务期望是东八区 → 所有TIMESTAMP字段都会被自动转换成 UTC 存储，查出来再转回会话时区（若会话时区又没设对），就漂移了 - 别改
my.cnf里的default-time-zone为SYSTEM—— 它依赖系统时区，不可靠；应显式设为+08:00 - 改完必须重启 MySQL：
sudo systemctl restart mysql，reload不生效
为什么 PHP 层也得同步改 date.timezone？
phpMyAdmin 自身用 PHP 函数生成页面时间（比如导出文件名里的 20260605-1846.sql）、处理表单提交时间、调用 strtotime() 解析用户输入等，全依赖 PHP 的时区设置。
- 如果
php.ini中date.timezone没设，或设成PRC/GMT+8/空值 → PHP 静默退回到系统时区（常为 UTC），所有由 PHP 生成的时间文本都错 - 必须编辑
phpMyAdmin首页「PHP 信息」页显示的Loaded Configuration File路径下的真实php.ini，取消注释并写死：date.timezone = "Asia/Shanghai" - 改完必须重启 Web 服务：
sudo systemctl restart apache2或sudo systemctl restart php8.2-fpm - 验证命令：
php -r "echo date('Y-m-d H:i:s');"输出应为当前北京时间
导出文件里出现 SET time_zone = "+00:00" 报错 #1298 怎么办？
这不是时间戳“格式”问题，是导入时 MySQL 不认识这个时区字符串，直接卡在第一行。常见于 XAMPP、宝塔等环境未加载时区表。
- 先确认目标 MySQL 是否支持
+00:00：登录后执行SELECT * FROM mysql.time_zone_name WHERE Name = '+00:00';，为空就说明没加载 - 临时解法：手动删掉导出 SQL 文件开头的
SET time_zone = "+00:00";行（用 VS Code 或sed -i '1d' dump.sql） - 根治法：用命令行加载时区表：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql（路径按实际调整） - 更稳妥的导出设置：在
phpMyAdmin「导出」→「自定义」里，把SQL 兼容模式设为NONE，避免生成带时区的 SET 语句
DATETIME 和 TIMESTAMP 在导出里表现不同，怎么区分？
导出文件里你看到的“时间戳”，大概率只是字段名含 timestamp，不代表类型是 Unix 时间戳；真存 INT 型时间戳的字段，phpMyAdmin 就直接导出数字，不会转日期。
立即学习“PHP免费学习笔记（深入）”；
-
DATETIME：不涉及时区转换，导出就是原样字符串，如'2026-06-05 18:46:00'，安全但不自动适配时区 -
TIMESTAMP：导出时按当前会话时区转成字符串，但写入时又会转回 UTC 存储 → 如果会话时区乱，导出内容本身就错 - 查表结构用：
SHOW COLUMNS FROM your_table LIKE 'created_at';看Type列，别光看字段名 - 迁移时若不确定，优先把
TIMESTAMP改成DATETIME，省去时区纠缠
真正麻烦的从来不是导出那一刻，而是 MySQL 和 PHP 两层时区配置各自为政，又都不报错——直到你发现某条记录的创建时间比服务器日志还早两天。
