乱码源于导出链路中UTF-8被误读为GBK/ANSI，数字字段变形是Excel自动类型识别所致；MySQL导出CSV需指定CHARACTER SET utf8mb4并加BOM头，身份证等字段须加引号或\t前缀强制文本格式。
直接结论：乱码不是Excel的问题，而是导出链路上至少有一环把UTF-8当成了GBK或ANSI解析；身份证、手机号等数字型字段在Excel里变科学计数法或截断，本质是Excel自动识别类型导致的格式丢失，跟编码无关。
MySQL INTO OUTFILE 导出CSV时中文变“锟斤拷”
这是最典型的跨编码误读：MySQL默认用UTF-8存中文，INTO OUTFILE 输出的是纯UTF-8字节流，但Windows下双击CSV会强制用系统ANSI（即GBK）打开——一个汉字被拆成两个字节分别当ASCII字符解，就变成“锟斤拷”。
- 必须显式指定字符集：
SELECT * FROM my_view INTO OUTFILE '/tmp/data.csv' CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n'; - 即使指定了
utf8mb4，Excel仍可能识别失败——因为UTF-8无BOM头，Excel不主动检测。临时补救：用记事本打开该CSV，另存为「UTF-8-BOM」格式（Notepad++里叫“UTF-8 with BOM”） - 别依赖
CONVERT(... USING gbk)硬转：MySQL的GBK实现不完整，遇到生僻字会报Illegal mix of collations，且转完后在Linux服务器上反而无法被其他UTF-8工具读取
Excel导入向导中选错编码导致字段错位
很多人跳过导入向导，直接双击CSV，结果不仅乱码，连列都对不上——这是因为ANSI解析把多字节UTF-8序列当成多个单字节字段切分了。
- 正确流程：Excel → 「数据」选项卡 → 「从文本/CSV」→ 选中文件 → 在预览窗口左下角手动选「65001: Unicode (UTF-8)」→ 点「加载」
- 如果导入后第一列是空的，大概率是原CSV带BOM头但Excel误判成其他编码；此时点「转换数据」进Power Query，选择「使用第一行作为标题」前先点「高级编辑器」，删掉开头的
#table前那行BOM字节（通常显示为乱码方块） - 避免用
SELECT ... INTO OUTFILE生成无表头CSV：Excel导入时无法自动识别字段名，必须手写UNION ALL拼接表头行，但要注意UNION ALL要求所有列类型兼容，字符串字段得统一CAST为CHAR，否则报错
身份证号、手机号在Excel里变1.23E+17或末尾变0
这不是编码问题，是Excel自动将长数字识别为数值并应用科学计数法，同时抹去末尾的0（比如`110101199003072100`变成`110101199003072000`）。
- 导出前在SQL里加引号包装：
SELECT CONCAT('"', id_card, '"') AS id_card, ... FROM my_view INTO OUTFILE ...，确保Excel把它当文本读 - 更稳妥的做法是加制表符前缀：
SELECT CONCAT('\t', id_card) AS id_card, ...，Excel会识别\t开头的列为文本（注意：此法仅在用「从文本/CSV」导入时生效，双击打开无效） - 如果必须用
.xls或.xlsx扩展名（而非CSV），不要用INTO OUTFILE直接写，它生成的是纯文本，Excel打开时仍会触发自动类型推断；改用Python的xlsxwriter或Java的Apache POI，显式设单元格格式为TEXT
视图字段含计算逻辑时导出结果与预期不符
比如视图里有CONCAT('U', user_id)，导出后发现前面多出空格，或者日期字段变成2026-06-03 14:12:00但Excel显示为数字串45821.59——这是MySQL和Excel对字符串/时间类型的隐式转换差异。
- 时间字段务必显式格式化：
DATE_FORMAT(create_time, '%Y-%m-%d %H:%i:%s')，避免MySQL返回datetime类型让Excel自行解析 - 拼接字段用
TRIM()兜底：CONCAT('U', TRIM(CAST(user_id AS CHAR)))，防止源字段带不可见空格影响后续处理 - 视图若引用了函数如
MD5()或UUID()，导出后长度固定但内容含短横线，Excel可能误判为日期格式（如550e8400-e29b-41d4-a716-446655440000），此时应在SQL里再套一层REPLACE(..., '-', '_')或直接加引号
真正麻烦的不是某一步怎么做，而是整个链路里任意一环没对齐编码或格式预期：MySQL连接用utf8mb4，但客户端命令行没加--default-character-set=utf8mb4参数；导出文件是UTF-8，但运维同学用scp传到Windows后被某些FTP工具静默转码；甚至Excel版本差异也会导致BOM识别行为不同——这些细节不逐个核对，光调一个地方根本解决不了问题。
