SQL导入日期偏移因时区未对齐，需确保客户端、服务端及字段类型三处时区一致：MySQL需在导入前执行SET time_zone='+08:00'；PostgreSQL应在连接串中指定timezone=Asia/Shanghai；图形工具须在导入设置中配置时区而非SQL编辑器。
SQL导入时日期偏移几小时，大概率是时区没对齐
mysql、postgresql 或 sqlite 在解析 2023-10-05 14:30:00 这类无时区标记的字符串时，会按服务端默认时区解释。你本地导出时用的是东八区，服务器却是 utc，结果所有时间自动减 8 小时——不是数据错了，是解释错了。
关键不是“补一行命令”，而是确认三处时区是否一致：客户端连接时区、服务端全局时区、表字段类型是否带时区语义。
MySQL 导入前必须设 SET time_zone = '+08:00'
MySQL 的 LOAD DATA INFILE 或客户端批量导入（如 mysql -e "INSERT..."）不会继承 shell 的 TZ 环境变量，也不读取 my.cnf 里的 default-time-zone（除非显式启用）。不手动设，就走服务端 global time_zone，默认常为 SYSTEM（即系统 UTC）。
- 导入 SQL 文件前，在文件开头加：
SET time_zone = '+08:00'; - 用命令行导入时，不要直接
mysql db < data.sql，改用：mysql -e "SET time_zone = '+08:00';" db && mysql db < data.sql - 如果字段是
DATETIME（无时区），该设置只影响字符串到时间的转换过程；如果是TIMESTAMP，还会触发自动时区转换，要更小心
PostgreSQL 要在连接串里加 options=-c%20timezone%3DAsia%2FShanghai
PostgreSQL 不认 SET timezone 的 SQL 命令作为导入前置动作（psql 会执行，但 COPY 或 psql -f 下行为不稳定）。真正可靠的是把时区钉死在连接层。
- 使用
psql导入：psql "host=localhost dbname=mydb options=-c%20timezone%3DAsia%2FShanghai" -f data.sql - 用
COPY从 CSV 导入时，时区由 client_encoding + timezone 共同决定，仅靠SET timezone不生效 -
Asia/Shanghai比+08更稳妥——后者不处理夏令时（虽然中国不用，但 PostgreSQL 内部逻辑仍区分）
CSV / Excel 导入工具（如 DBeaver、TablePlus）容易忽略连接级时区
图形工具通常复用一个连接池，连上后就不再动态更新时区。即使你在 SQL 编辑器里执行了 SET timezone，后续的“右键导入 CSV”操作仍走原始连接配置。
- DBeaver：右键表 → “Import data” → 第二步 “Settings” → 展开 “Advanced settings” → 手动填
timezone=Asia/Shanghai - TablePlus：连接设置 → “Advanced” → “Default timezone” 选对应时区，**不是**在 query editor 里 SET
- 这类工具若导出再导入，原始 CSV 里的日期列若没带
T和Z（如2023-10-05T14:30:00+08:00），就完全依赖连接时区解释
最麻烦的不是设错，而是设了却没生效——比如 MySQL 里 SELECT @@time_zone 返回 SYSTEM，你以为改了，其实只是 session 级生效，而导入命令根本没走这个 session。盯住实际执行导入的那个上下文，而不是你认为“应该管用”的地方。
