我来帮你拆解这个迁移时遇到的时间戳问题——这在PG转MySQL的场景里挺常见的，咱们一步步来解决：

一、先搞清楚两个核心问题的根源 #

1. 8小时偏移 + 毫秒丢失/进位 #

你遇到的时间自动加8小时，几乎肯定是时区配置不一致导致的：

• PostgreSQL默认可能用的是UTC或者服务器本地时区，而MySQL的TIMESTAMP类型会把存储的时间转成UTC保存，查询时再根据会话时区转换回来；DATETIME虽然不存时区，但如果迁移工具用了不同时区解析时间，也会出现偏移。
• 至于.921毫秒变成00且进位到下一分钟，是因为你没给MySQL的时间列指定毫秒精度，默认的TIMESTAMP/DATETIME只保留到秒，超过500毫秒的部分会被进位（这是MySQL的默认行为）。

2. MySQL有没有13位timestamp列类型？ #

直接说结论：没有专门的13位timestamp类型。所谓的13位timestamp是指毫秒级的Unix时间戳（比如1577639999921），你完全可以用BIGINT类型存储这个数值；如果是MySQL 5.6.4及以上版本，更推荐用DATETIME(3)或TIMESTAMP(3)直接存储带毫秒的时间格式，比存数值更直观。

二、具体解决步骤 #

1. 对齐两边的时区配置 #

先确认两个数据库的时区：

• 在PostgreSQL中执行：SHOW timezone;
• 在MySQL中执行：SELECT @@global.time_zone, @@session.time_zone;

如果两边时区不一致（比如PG是UTC，MySQL是Asia/Shanghai），要么把MySQL的全局/会话时区改成和PG一致，要么在迁移时显式指定时区转换。比如在导出PG数据时，把时间转成UTC格式的字符串，导入MySQL时也用UTC时区解析。

2. 给MySQL列添加毫秒精度 #

如果你的MySQL版本是5.6.4及以上（执行SELECT VERSION();确认），把目标列的类型改成DATETIME(3)或TIMESTAMP(3)（括号里的3表示保留3位毫秒），这样就能完整存储2019-12-29 15:59:59.921这种带毫秒的时间，不会出现截断或进位。

如果是低于5.6.4的旧版本MySQL，建议升级版本；如果没法升级，就用BIGINT存储PG时间对应的毫秒级时间戳：

• 在PG中转换：EXTRACT(EPOCH FROM your_timestamp_col) * 1000，得到13位数值
• 导入MySQL的BIGINT列，查询时用FROM_UNIXTIME(your_bigint_col / 1000, '%Y-%m-%d %H:%i:%s.%f')转成带毫秒的时间格式

3. 检查迁移工具的处理逻辑 #

有些迁移工具（比如手动导出SQL再导入）会自动截断毫秒部分，或者时区处理出错。可以试试这些优化：

• 用PG的COPY命令导出数据时，指定时间格式为'%Y-%m-%d %H:%i:%s.%f'，确保毫秒被保留
• 导入MySQL时，用LOAD DATA INFILE命令，指定时间列的格式，避免工具自动转换
• 或者用专门的数据库迁移工具（比如Percona Toolkit的pt-table-sync），这类工具通常能更好地处理时区和精度问题

三、验证解决效果 #

修改完配置和列类型后，先迁移一条测试数据，检查：

• 时间是否和PG原始值一致（没有8小时偏移）
• 毫秒部分是否保留（比如2019-12-29 15:59:59.921不会变成2019-12-29 16:00:00）

内容的提问来源于stack exchange，提问作者user2894829