根本原因是Excel双击打开CSV时自动将长数字识别为数值并截断至15位有效数字，导致末位变0或显示为科学计数法；正确做法是用Excel“数据→从文本/CSV”导入向导并手动设列为文本，或在SQL中用CONCAT(..., '\t')等方式添加制表符强制转文本。
CSV导入后长数字变000或科学计数法，不是Navicat的问题
navicat 导入 csv 时本身不修改字段值，数字精度丢失发生在 excel 打开 csv 的环节——excel 自动把纯数字字符串（如身份证号、银行卡号）识别为数值类型，超过 15 位就截断尾数，变成 1.23457e+17 或末三位归零。用记事本打开 csv 文件，内容仍是完整的；问题只出在 excel 双击打开这个动作上。
导出时加制表符 \t 是最稳的兜底方案
在 Navicat 的 SQL 查询里对目标字段做字符串拼接，让 Excel 解析时一眼认出这不是纯数字：
-
MySQL / MariaDB：写成CONCAT(id_card, '\t') -
PostgreSQL：写成id_card || E'\t'（注意E''语法必须带） -
SQL Server：写成id_card + CHAR(9)
别用空格或单引号替代： （空格）可能被 Excel 导入时 trim 掉，'（单引号）在某些版本里反而触发异常解析。制表符 \t 不占显示宽度、不破坏原始数据结构，且兼容所有主流数据库和 Excel 版本。
导入时必须走 Excel 的「从文本/CSV」向导
即使导出时没加 \t，也能补救，但前提是不能双击打开 CSV 文件：
- Excel 菜单栏 → 数据 → 从文本/CSV → 选中文件
- 预览界面中，点击目标列（如
order_id）标题 → 顶部下拉选 文本 - 确认编码为
UTF-8（中文乱码时可试GBK）→ 点击 加载
这个流程对 .csv 有效，对 .xlsx 导出文件无效；如果 CSV 首行有 BOM，Excel 通常能自动识别 UTF-8，否则手动勾选编码。
别信 CAST(... AS CHAR) 或 FORMAT() 能解决问题
这些函数确实返回字符串，但 Excel 在解析 CSV 时仍会根据内容“猜”类型。比如 CAST(123456789012345678 AS CHAR) 结果是 "123456789012345678"，但 Excel 看到纯数字+引号，仍可能当成数值处理——尤其当引号是字段分隔符而非文本限定符时。
真正起效的是破坏“纯数字”结构：\t、"（英文双引号）、'（单引号）都行，但只有 \t 不影响后续清洗，也不依赖 Excel 是否启用“文本限定符”选项。
复杂点在于：如果源头字段在数据库里就是 INT 类型，那前导零或超长位数其实在入库时就丢了，导出再怎么兜底也拿不回来——得先改表结构为 VARCHAR。
