根本原因是导出目标（如Excel、CSV）自动将数字型字段识别为数值并抹去前导零；Navicat导出本身忠实于查询结果，问题在于格式选择与目标程序解析逻辑。
navicat 15 导出数据时字段零填充丢失，根本原因不是 navicat 本身“删了零”，而是导出目标（如 excel、csv）在后续打开时自动识别为数值类型，并抹掉前导零。navicat 导出过程本身是忠实的——select 返回什么，它就原样写入文件；问题出在「导出格式选择」和「目标程序解析逻辑」上。
导出为 CSV 时如何让数字字段带前导零
CSV 是纯文本，不带格式信息。能否保留前导零，取决于你是否在字段值周围加了英文双引号，并且是否显式声明该列为文本类型。
- 在 Navicat 导出向导第 2 步（导出设置）中，勾选 “导出记录”，并点击右下角 “高级” 按钮
- 在弹出窗口中，将
Text qualifier设为"（双引号），并勾选Quote all text fields—— 这会让所有字段（包括数字型字段）都被双引号包裹，例如："00123"而非00123 - 确保数据库中该字段本身是字符串类型（
VARCHAR/CHAR），而不是INT或TINYINT；若底层是数值类型，Navicat 会按数值取值（00123 → 123），再加引号也无济于事 - 导出后，用记事本或 VS Code 打开 CSV 文件确认内容是否含引号；若直接双击用 Excel 打开，仍可能触发自动数值解析 —— 此时应改用 Excel 的「数据 → 从文本/CSV」导入流程，并在列类型中手动设为「文本」
导出为 Excel（.xlsx）时避免科学计数法与截断
Navicat 导出 Excel 时默认使用二进制格式（.xlsx），但 Excel 在打开时仍会按列内容启发式判断格式。前导零、长数字（如身份证、订单号）极易被转成数值并丢零或变科学计数法。
- 不要双击打开导出的
.xlsx文件；应启动 Excel 后，通过 数据 → 从工作簿 导入，并在导入向导中为对应列选择「文本」格式 - 若必须双击打开，可在导出前在 SQL 查询中强制转为文本：例如原字段叫
order_no，改写为CONCAT('', order_no) AS order_no或LPAD(order_no, 12, '0')（MySQL），确保结果集里该列值是字符串 - Navicat 不支持导出时为 Excel 单元格预设「文本格式」，所以依赖 SQL 层做类型兜底是最可靠方式
- 注意：如果字段本身含纯数字但需保留前导零（如
'007'），而数据库里存的是INT类型，那无论怎么导出都拿不到零 —— 零在入库时已被丢弃，这是源头问题，需先改表结构为VARCHAR
为什么 Navicat 的“自动补零”设置对导出无效
Navicat 设置里的「自动补零」（在字段属性中勾选 Zerofill）仅影响 MySQL 表定义中的显示宽度（如 INT(6) ZEROFILL），且只在 MySQL 客户端查询返回时由服务端补零；它不改变实际存储值，也不参与 Navicat 导出逻辑。
-
ZEROFILL是 MySQL 特有属性，仅对整数类型生效，且在 MySQL 8.0.17+ 中已被标记为 deprecated - Navicat 导出时读取的是字段真实值（比如存储的是
123），不会根据INT(6) ZEROFILL自动变成'000123' - 真正可控的方式只有两种：① 把字段类型改为
VARCHAR并在应用层/SQL 层补零；② 导出前用LPAD()或CONCAT()显式格式化
最易被忽略的一点：零填充是否必要，得先看字段语义。像订单号、编码类字段，本质就是标识符，不是数值，理应存为字符串；强行用数值类型存储再靠各种补零技巧“抢救”，反而增加维护成本和出错概率。
