concat(id, '\t')是最可靠解法，因\t作为控制字符强制excel识别为文本，避免15位数字截断；mysql用concat，postgresql用||e'\t'，sql server用+char(9)，且必须在sql层处理。
直接在sql查询里给长数字字段末尾加 \t，是最可靠、兼容性最强的解法。其他方法要么无效（比如excel里提前设文本格式），要么有严重限制（比如csv导入向导只对.csv生效、不支持.xlsx）。
为什么CONCAT(id, '\t')比FORMAT()或CAST()更有效
Excel在解析CSV或.xlsx时，会对纯数字字符串“二次猜测”类型——哪怕你用CAST(id AS CHAR)或FORMAT(id, '0')转成字符串，只要内容全是数字，它仍可能按数值处理，触发15位截断。而\t是控制字符，Excel识别逻辑里明确将含控制字符的字段归为文本，跳过所有数字推断。实测中，CONCAT(id, '\t')导出后复制到Excel单元格，能看到光标停在数字后、有明显缩进，说明制表符已生效。
-
\t必须放在字段值末尾，不能被Navicat导出设置里的“去除首尾空白”勾选项吃掉 - MySQL 5.7+ 和 MariaDB 直接支持
CONCAT(id, '\t') - PostgreSQL 要写成
id || E'\t'，注意E''语法不可省略 - SQL Server 用
id + CHAR(9)，CHAR(9)才是制表符的ASCII码
导出CSV后双击打开 vs 走“从文本/CSV”导入流程
如果你无法改SQL（比如权限受限、用的是只读视图），导出为.csv后，**绝对不要双击打开**。双击会触发Excel自动类型识别，照样变科学计数法。必须走Excel的正规导入路径：
- Excel → “数据”选项卡 → “从文本/CSV” → 选中导出的
.csv文件 - 在预览界面，点击目标列（如
order_id）右侧下拉箭头 → 选“文本” - 确认导入，该列左上角会出现绿色角标，表示Excel已按文本读取
这个流程对.xlsx导出文件完全无效，只适用于.csv。
别踩这些坑：单引号、空格、全角字符都靠不住
有人试过在数字前加英文单引号'，看似能强制文本显示，但在Navicat导出场景下极易失效：某些Excel版本或导入方式会自动Trim掉开头的'；部分ETL工具或下游系统会把'123456789012345678当异常字符串报错。空格同理，容易被清洗逻辑过滤。全角字符（如全角单引号）则可能引发编码问题，尤其在跨平台传输时。
-
\t是唯一被Excel各版本一致识别为“文本锚点”的控制字符 - 导出前建议在Navicat结果窗口里复制一格，粘贴到记事本看是否有不可见缩进——有，就说明
\t生效了 - 如果字段本身是NULL，
CONCAT(id, '\t')会返回NULL，需用CONCAT(IFNULL(id, ''), '\t')兜底
真正容易被忽略的是：这个方案必须在SQL层完成，不是导出后补救。一旦数据以数值形式进入Excel，15位后的数字就永久丢失，再改格式也恢复不了原始值。
