根本原因是MySQL默认用utf8mb4编码导出CSV而Excel（尤其旧版）默认按GBK解析，且不识别UTF-8无BOM文件；可靠解法是用CHARACTER SET gbk导出并显式指定FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY ' '。
MySQL里SELECT INTO OUTFILE导出CSV，为什么Excel打开全是乱码？
根本原因是MySQL默认用utf8mb4编码写入文件，而Windows版Excel（尤其2019及更早）读CSV时默认按ANSI（即系统本地编码，如GBK）解析。UTF-8无BOM的CSV，Excel根本不会识别。
- 临时解法：导出时强制加BOM头——但
SELECT INTO OUTFILE不支持直接写BOM，得靠后续工具补，不推荐 - 真正靠谱的做法：改用
CHARACTER SET gbk导出，适配Excel默认行为（仅限中文Windows环境） - 命令示例：
SELECT * FROM users INTO OUTFILE '/tmp/users.csv' CHARACTER SET gbk FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY ' ';
- 注意路径必须是MySQL服务端可写的绝对路径，且
secure_file_priv限制必须放开，否则报错The MySQL server is running with the --secure-file-priv option
导出字段含逗号、换行或引号时，FIELDS ENCLOSED BY必须用双引号
CSV规范要求：只要字段值含,、
或"，就必须用引号包裹；若字段本身含引号，还得转义为两个双引号（""）。MySQL的SELECT INTO OUTFILE能自动处理转义，但前提是明确指定OPTIONALLY ENCLOSED BY '"'。
- 漏写
OPTIONALLY ENCLOSED BY会导致字段分裂，Excel列错位 - 别用单引号——Excel只认双引号作为字段定界符
- 如果字段里有双引号，MySQL会自动转成
""，无需手动替换 - 换行符建议统一用
SELECT INTO OUTFILE无法替代mysqldump或客户端导出
它只是服务端写文件，不经过客户端，也不走网络传输，所以快且省带宽。但这也带来硬约束：
- 输出路径只能是MySQL服务所在机器的本地路径，你本地电脑根本拿不到文件，除非再用
scp或FTP拉回来 - 没有进度提示、无压缩、无分片，大数据量时容易卡住或超时（受
max_allowed_packet和net_write_timeout限制） - 权限要求高：需要
FILE权限，且不能跨库导出（比如SELECT ... FROM db1.t1 JOIN db2.t2会失败） - 替代方案更稳：用
mysql -e "SELECT ..." > output.csv，由客户端拼接，编码和换行可控，适合中小数据量
导出后Excel仍显示异常？先检查LINES TERMINATED BY和区域设置
即使编码、引号都对了，Excel还可能错行——常见于Linux服务器导出时用了
而非
，或者Windows Excel的“数据”→“从文本/CSV”导入功能没选对分隔符。
- 务必显式写
LINES TERMINATED BY ' '，别依赖默认值 - Excel 365/2021建议用“数据→从文本/CSV”手动导入，在向导里选
UTF-8编码、逗号分隔、双引号包裹，比双击打开可靠得多 - Mac版Excel对UTF-8无BOM支持较好，但依然要确认系统区域设置里的“默认编码”是否为UTF-8
- 如果数据里有NULL值，MySQL默认导出为空字符串，Excel看不出区别；需要
IFNULL(col, '\N')显式标记才能分辨
实际用的时候，最常卡在secure_file_priv路径限制和Excel编码误判这两处。前者查SHOW VARIABLES LIKE 'secure_file_priv';就能确认可写目录；后者宁可多一步用导入向导，也别信双击打开的自动猜测。
