必须显式设置连接时区参数并使用自定义SQL导出：右键编辑连接→高级→连接字符串末尾添加&serverTimezone=Asia/Shanghai&useTimezone=true，保存后执行DATE_FORMAT()格式化时间字段，导出时选UTF-8 with BOM及双引号限定符。
导出前必须显式设置连接时区参数
navicat 默认用系统本地时区发起 mysql 连接，而 mysql 服务端通常以 utc 存储 timestamp，查出来再转成会话时区——如果两者没对齐，导出的日期时间就会偏移或变 null。这不是显示问题，是值本身被错误转换了。
关键动作：右键连接 → 编辑连接 → 切到「高级」页，在「连接字符串」末尾手动追加：&serverTimezone=Asia/Shanghai&useTimezone=true（阿里云 RDS 等环境可能需写成 &serverTimezone=GMT%2B8）。
- 改完必须重新输入密码并保存，否则 Navicat 会缓存旧握手信息，新参数不生效
- 验证是否生效：连上后执行
SELECT @@time_zone, NOW(), SYSDATE()，三个结果应一致且落在你预期的时区范围内 - 别只填
useTimezone=true——它单独存在无效，必须配对serverTimezone
导出时避免用表直导，优先走自定义 SQL
直接选表导出，Navicat 会调用驱动默认的字符串转换逻辑，对 DATETIME 或 TIMESTAMP 字段不做干预，容易把时间转成数值或错误时间戳（尤其 MySQL 5.6+ + 高版本 Navicat 组合）。
更可控的做法是：新建查询 → 手动格式化时间字段 → 导出查询结果。
- 例如：执行
SELECT DATE_FORMAT(created_at,'%Y-%m-%d %H:%i:%s') AS created_at FROM your_table - 确保查询已执行且结果集正确（注意右下角“只读取前 N 行”是否启用，大数据量要设为 0）
- 务必点击保存按钮（? 图标），命名为类似
export_with_tz——未保存的查询不会出现在导出源列表中 - 导出向导第一步，选左侧「查询」节点，而不是「表」节点
导出 CSV 时中文和时间字段同时保真要兼顾编码与分隔符
即使时间值正确，导出为 CSV 后用 Excel 打开仍可能乱码或时间被识别为数值，本质是目标程序解析逻辑干扰了原始内容。
两个硬性条件缺一不可：
- 编码必须选
UTF-8 with BOM，否则 Windows 下 Excel 默认用 ANSI 打开，中文直接崩 - 勾选「文本限定符」（双引号
"），并开启Quote all text fields—— 这能让时间字符串如"2026-07-28 14:30:00"原样写入，防止 Excel 自动转成日期类型或科学计数法 - 导出后先用记事本或 VS Code 打开确认内容是否含引号；若直接双击 Excel 打开仍异常，改用 Excel 的「数据 → 自文本/CSV」导入流程，并手动指定编码为
65001 UTF-8
大数据量导出失败或时间字段异常，别硬扛 GUI
Navicat GUI 导出超过 10 万行容易内存溢出或假死，尤其开启「导出列标题」+「UTF-8 BOM」+「含 NULL 处理」时，时间字段可能中途截断或格式错乱。
绕过界面，用命令行脚本更稳：
- 在 Navicat 中右键表 → 「复制为 INSERT 语句」或「生成 SQL 文件」，拿到带
DATE_FORMAT()的完整查询 - 用
mysqldump加--where和--fields-enclosed-by='"'参数重跑，例如：mysqldump -u user -p --where="created_at >= '2026-01-01'" --fields-enclosed-by='"' db table > out.csv - 注意
mysqldump默认输出 SQL，要导出 CSV 得配合--tab或管道转格式，或用mysql -e "SELECT ..." | sed流式处理
真正容易被忽略的是：时区设置只作用于当前连接，每次新建查询或导出任务都得确认它是否生效；而导出路径里的文件名、BOM、引号这些细节，一旦漏掉一个，Excel 就会按自己理解“修正”你的数据。
