navicat 连接 mysql 时 timestamp 显示 null 或偏移 8 小时，是因未配置 servertimezone 导致本地时区误解析 utc 存储值；需在连接字符串添加 &servertimezone=asia/shanghai&usetimezone=true 并重输密码验证。
Navicat 连接 MySQL 时 TIMESTAMP 显示 NULL 或偏移 8 小时
这不是数据库存错了，是 Navicat 用本地系统时区解释了 MySQL 的 UTC 存储值。MySQL 的 TIMESTAMP 类型默认以 UTC 存、按会话时区转，而 Navicat 若没显式指定 serverTimezone，就会拿 macOS/Windows/Linux 的本地时区去反向解析——比如你服务器在阿里云上海节点（UTC+8），Navicat 却按 UTC 解，结果就少 8 小时或变 NULL。
必须进连接属性 → 「高级」页 → 在「连接字符串」末尾手动追加：
&serverTimezone=Asia/Shanghai&useTimezone=true- 阿里云 RDS 等环境可能需写成
&serverTimezone=GMT%2B8（%2B是 URL 编码的+） - 改完务必右键连接 → 「编辑连接」→ 重输密码，否则 Navicat 仍用旧握手缓存
验证是否生效：连上后执行 SELECT @@time_zone, NOW(), SYSDATE();，三个结果应都落在北京时间范围内（如 SYSTEM 或 +08:00）。
DATETIME 字段在 Navicat 和命令行里显示不一致
DATETIME 本身不带时区信息，但客户端会按自己理解的“本地时间”去渲染。典型现象是：命令行查出来是 2026-09-07 15:30:00，Navicat 却显示 2026-09-07 07:30:00——说明 Navicat 解析时用了 UTC，而 MySQL 服务端或会话时区是 +08:00。
解决路径不是改字段类型，而是对齐解析逻辑：
- 优先检查数据库服务端时区：
SELECT @@global.time_zone, @@session.time_zone;，确认不是SYSTEM且系统实际时区为CST或+08:00 - Navicat 连接高级设置中，勾选「使用服务器时区」或手动填入
+08:00（部分旧版仅支持偏移量） - 如果仍不准，临时补救：连接后执行
SET time_zone = '+08:00';，但别依赖它长期运行
导出 Excel 后日期变成 44562 这类数字
这不是 Navicat 导出失败，是 Excel 没识别出这是日期——它把原始数值当成了序列天数（1900-01-01 是 1）。Navicat 导出时若字段是 DATETIME 类型，Excel 有可能按底层数值接收，而非格式化字符串。
最稳的修复方式是导出前就在 SQL 层控制输出形态：
- 用
DATE_FORMAT(created_at, '%Y-%m-%d %H:%i:%s')强制转成字符串，导出后 Excel 不会误判 - 避免用
CAST(created_at AS CHAR)，不同驱动行为不一致 - 如果必须保留原生类型供下游计算，导出为
.xlsx而非.csv，兼容性更好
注意：DATE_FORMAT() 输出的是字符串，不能再用于日期函数运算，只适合报表展示。
导入 Excel 时日期列被识别成文本或 1900-01-20
Navicat 导入向导对 Excel 日期的自动识别很脆弱，尤其当源文件存在空单元格、混合格式（部分是文本“2026/09/07”，部分是 Excel 原生日期）时，整列容易被判定为 VARCHAR。
关键动作在导入前和导入中：
- Excel 端先统一格式：选中日期列 → 右键「设置单元格格式」→「日期」→ 选
2026年9月7日类样式 - Navicat 导入时点「高级」→ 找到对应字段 → 手动将数据类型设为
DATETIME或DATE，别信自动推断 - 若已导入错误，不要直接 UPDATE 字符串转日期；先用
STR_TO_DATE(col, '%Y/%m/%d')校验可解析性，再批量转换
跨平台最易忽略的一点：macOS 和 Windows 的 Excel 默认日期基准不同（1904 vs 1900），但 Navicat 不处理这个差异，全靠你导出前在 Excel 里关掉「使用 1904 日期系统」选项。
