Navicat导入Excel时数字精度丢失的根本原因是Excel自身对超15位数字的近似存储，Navicat只是读取已被篡改的值；改字段为DECIMAL无效，必须改用CSV/TXT文本格式导出并以VARCHAR接收。
navicat导入excel时数字精度丢失，不能靠改目标字段类型为decimal解决
这是个常见误解。把MySQL表里的字段从INT或BIGINT改成DECIMAL(20,0)，并不能阻止Navicat在导入阶段就把长数字（比如身份证号、订单号）当成浮点数截断——数据在进数据库之前，就已经被Excel“污染”了。
Excel导出时数字就被Excel改写，Navicat只是照单全收
当你用Navicat直接导入.xlsx文件，它底层调用的是Excel引擎（如Apache POI）读取单元格值。而Excel对超过15位的数字，内部存储已经是近似值（例如110101199003077032 → 110101199003077000）。Navicat读到的，就是这个被舍入后的数值，后续再怎么设DECIMAL都于事无补。
- 验证方法：在Excel里右键单元格 → “设置单元格格式” → 切换为“文本”，再双击编辑栏看真实值；如果末尾已变成
000，说明原始数据已不可逆丢失 - 哪怕你手动把Excel列设为“文本格式”，只要该列曾被Excel识别为“数字”并参与过计算或排序，就可能触发自动修正
- Navicat不会警告你“这一列数字已被Excel篡改”，它只忠实地把读到的值插入数据库
真正有效的导出方案：绕过Excel解析引擎
核心思路是不让Navicat接触.xlsx，改用纯文本格式传输原始字符，由数据库按字符串原样接收。
- 在Navicat中执行查询时，用
CONCAT("\t", id)或CONCAT("'", id)给数字加前缀，强制导出为文本（注意：单引号可能被Excel自动剥离，制表符\t更稳定） - 导出格式选
CSV或TXT，不是XLSX；编码选UTF-8 with BOM或确认Notepad++里显示为UTF-8无BOM - 导入时，目标字段必须是
VARCHAR（不是DECIMAL），长度足够（如VARCHAR(32)），且“空值”选项勾选“空字符串转NULL”要慎用，避免把'0000123'变成NULL - 如果源数据来自Excel，先导出为CSV → 用Notepad++打开 → 编码转UTF-8 → 保存 → 再用Navicat导入该CSV
为什么DECIMAL字段反而可能让问题更隐蔽
当错误地依赖DECIMAL来“修复”精度，容易忽略真正的破坏环节，导致后续排查困难。
-
DECIMAL(20,0)能存20位整数，但如果你导入的是Excel已经舍入过的110101199003077000，存进去的仍是错的 - 某些Navicat版本在导入CSV时，若字段声明为
DECIMAL，会尝试做类型转换，遇到带前导零的字符串（如'00123'）可能截掉零，变成123 - 如果字段本意是标识符（非数值运算），用
DECIMAL违反语义，还可能影响索引效率和范围查询逻辑
最稳妥的做法，是从源头切断Excel对数字的干预：不双击打开原始文件，不用Excel“另存为”CSV（它会偷偷格式化），所有导出操作通过SQL拼接字符串完成。一旦数据以varchar形式进入数据库，后面想转成数字、校验、比对，才真正可控。
