根本原因是Excel将日期序列值（如45231）按常规数字格式渲染，而非日期格式；Navicat仅输出数值，不控制Excel单元格格式，需在SQL中用DATE_FORMAT或TO_CHAR显式转为标准日期字符串，并导出为.xlsx格式，避免.xls兼容性问题及前8行类型推断错误。
navicat导出excel后日期变成一串数字（如45231）或显示为1900-01-01，根本原因不是数据丢了，而是excel把日期序列值当成了普通数字——navicat没主动格式化，excel就按默认规则渲染。
导出时用DATE_FORMAT显式转字符串
Navicat本身不控制Excel单元格格式，它只输出值。要让Excel“看到”标准日期文本，就得在SQL里提前转换：
- 对MySQL：用
DATE_FORMAT(your_date_col, '%Y-%m-%d')或DATE_FORMAT(your_datetime_col, '%Y-%m-%d %H:%i:%s') - 对PostgreSQL：用
TO_CHAR(your_date_col, 'YYYY-MM-DD') - 避免只用
CAST(your_date_col AS CHAR)——不同数据库行为不一致，MySQL可能返回20260727这种无分隔符格式，Excel无法识别 - 如果字段是
DATETIME但只想导出日期部分，别依赖Excel自动截断，DATE()函数更可靠
导出设置里避开Excel 97–2003 (.xls)格式
.xls格式对日期支持极差，尤其遇到NULL或空值时容易塌成1900-01-01；.xlsx虽好，但Navicat某些版本（如v16.0.12之前）在写入长文本列时会静默截断，连带影响日期列解析。
- 导出格式务必选
Excel文件2007或以上版本(.xlsx) - 在导出向导的「选项」页，勾选
Export data with quotes——防止含斜杠的日期（如2026/07/27）被误判为公式 - 不要选
Export only structure，这个选项会导致日期字段全为空，但表头还在，容易误判为“格式问题”
Excel打开后仍异常？先确认是不是CSV被当Excel打开了
很多人导出的是.csv却双击用Excel打开，Excel会按系统默认编码（通常是GBK或ANSI）解析，日期字段里的/或-被当成分隔符切开，结果整列偏移、日期错位，看起来像“变数字”。
- 检查文件后缀：如果是
.csv，别双击，改用Excel菜单栏【数据】→【自文本或CSV】导入，在预览窗口手动选编码65001 UTF-8 - 如果必须用
.csv且含中文日期，导出时在Navicat「高级」页把Character set设为UTF-8-BOM（注意不是UTF-8），否则Excel打不开中文 - Excel里右键日期列 →「设置单元格格式」→「日期」→选带
-分隔符的格式（如2026-07-27），这步只能补救，不能修复已错位的数据
为什么CAST或CONVERT有时也不管用？
因为Navicat导出逻辑会根据前8行内容推断字段类型。如果前几行日期都是NULL或空字符串，它可能把整列当VARCHAR(1)处理，后续CAST结果被截断——你看到的2026-就是典型表现。
- 导出前先运行
SELECT COUNT(*) FROM your_table WHERE your_date_col IS NOT NULL;，确保有非空样本 - 若必须处理大量
NULL，在SQL里用COALESCE(DATE_FORMAT(your_date_col, '%Y-%m-%d'), '')兜底，避免空值干扰类型推断 - 终极方案：导出为
.csv，用Python或pandas读取后再写入.xlsx，完全绕过Navicat的字段长度猜测机制
最麻烦的不是日期显示不对，而是你改了Navicat设置、调了Excel格式、重导了三次，结果发现原始SQL里your_date_col字段本身就是INT类型存的Excel序列值——这时候所有前端操作都白忙，得回数据库改字段类型或加转换逻辑。
