怎样将其他数据库(Oracle/SQLServer)数据导入_中间格式CSV转换

CSV导出需统一处理分隔符与换行符：字段含双引号须转义为两个双引号，含换行须整体加引号

导出时字段分隔符和换行符必须统一处理

从Oracle或SQL Server导出CSV时，很多朋友都踩过同一个坑：to_char、convert这类函数默认并不会主动处理换行符或者双引号。结果呢？导出的文件看着没问题，一到下游解析就报错，格式全乱。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

问题出在哪？无论是SQL Server的for xml path方法，还是Oracle的utl_file包，它们往往会把字段里原始的换行符\n或双引号"原封不动地写进文件。但标准CSV格式有明确要求：字段里如果包含双引号，必须转义成两个双引号；如果字段内容里包含了换行符，那么整个字段必须用双引号包裹起来。不遵守这个规则，解析器就会“懵掉”。

具体怎么操作？这里有几个经过验证的建议：

• SQL Server用户：首推使用bcp命令行工具。关键参数要记牢：-c使用字符类型，-t","指定逗号为字段分隔符，-r"\n"指定换行符。但千万别忘了加上-k来保留NULL值，以及-C 65001来确保UTF-8编码，否则中文和特殊字符可能出问题。
• Oracle用户：SQL*Plus配合SET COLSEP ","是个经典选择。不过，在此之前务必先执行SET LINESIZE 32767和SET TRIMSPOOL ON，防止超长字段被意外截断，导致数据丢失。
• 通用预处理：最保险的做法，是在SELECT语句里就对字符串字段进行清洗。比如在Oracle中可以这样写：REPLACE(REPLACE(col, '"', '""'), CHR(10), ' ') || ''；在SQL Server中则是：REPLACE(REPLACE(col, '"', '""'), CHAR(10), ' ')。这能手动完成双引号转义和换行符替换（或移除）。

中文乱码问题本质是编码不匹配

“导出的CSV用Excel打开全是乱码！”——这个问题太常见了。很多人第一反应是“我没设置UTF-8吧？”，但其实根源往往在于整个工具链中，至少有一个环节使用了非UTF-8编码。可能是数据库客户端的字符集、导出命令的环境变量，甚至是Excel默认的打开方式。要知道，Excel在直接双击打开CSV文件时，并不会自动识别UTF-8 BOM头，而是会用系统默认的ANSI编码去解码，中文自然就乱码了。

如何彻底解决？可以分数据库来应对：

• SQL Server：首先确认数据库的排序规则是Chinese_PRC_CI_AS或类似的中文规则。如果使用ODBC连接，可以在连接字符串中加入ApplicationIntent=ReadOnly;Charset=utf8;来明确指定编码。
• Oracle：重点检查NLS_LANG这个环境变量。建议设置为AMERICAN_AMERICA.AL32UTF8。一个稳妥的方法是，在用sqlplus /nolog启动后，先执行SET NLS_LANG=AMERICAN_AMERICA.AL32UTF8，再进行导出操作。
• 终极后手：如果导出后文件已经乱码，还可以进行转换。在Linux或macOS下，可以使用iconv -f GBK -t UTF-8 input.csv > output.csv命令。用Python修复更是一行代码的事：open('out.csv','w',encoding='utf-8').write(open('in.csv',encoding='gbk').read())。

NULL、空字符串、空白字段在CSV中表现不同

CSV格式本身没有数据类型的概念，这导致了一个隐形陷阱：数据库中的NULL值、空字符串''、全空格字符串' '，在导出成CSV后，看起来都是两个逗号之间的空字段,,。下游系统解析时，根本无法区分这三者，而它们在业务逻辑上的含义可能天差地别。尤其是Oracle和SQL Server的NULL，导出后都成了“空”，但业务处理方式可能完全不同。

怎么破？关键在于导出前进行显式转换：

• 显式标记NULL：在SQL Server中，使用ISNULL(col, 'NULL')；在Oracle中，使用NVL(col, 'NULL')。注意，这里的‘NULL’是一个字符串字面量，加了单引号，避免被下游误认为是数字或关键字。
• 统一处理空字符串和空格：可以先用NULLIF(LTRIM(RTRIM(col)), '')将纯空格字段转为NULL，然后再套用上面的NVL或ISNULL函数进行统一标记，这样就避免了空格字符的干扰。
• 下游配合：如果下游使用Python的pandas库，可以在读取时指定参数：pd.read_csv(..., na_values=['NULL'], keep_default_na=False)，明确告诉pandas将‘NULL’字符串识别为缺失值。

大表导出卡死或内存溢出怎么办

面对千万级别的大表，直接使用SELECT * INTO OUTFILE（MySQL）或SSMS的“导出数据向导”，基本等于“自杀式操作”。SQL Server可能会尝试把整个结果集加载到内存再写入文件，极易导致内存溢出；Oracle的SQL*Plus虽然默认分批获取，但缓冲区设置不当也会引发频繁的I/O操作，速度慢如蜗牛。

对付大表，必须采用分而治之的策略：

• SQL Server分批导出：使用bcp命令配合分页查询。例如：bcp "SELECT ... FROM tbl WHERE id BETWEEN ? AND ?" queryout chunk.csv -c -t","。通过ROW_NUMBER()窗口函数或按主键范围将数据分成多个批次，每次导出一部分。
• Oracle游标循环：编写PL/SQL脚本，使用游标（CURSOR）循环读取数据。设定每次FETCH 10000行，然后利用UTL_FILE.PUT_LINE过程逐批写入文件。这样可以避免在数据库端生成庞大的单次结果集。
• 借助专业工具：考虑使用Logstash、Apache NiFi这类数据集成工具。它们内置了分页查询和流式写入CSV的功能，对数据库内存几乎没有压力，是处理海量数据导出的更优选择。

最后，还有一个极易被忽略的细节：字段长度超限。比如Oracle中定义了一个VARCHAR2(4000)的字段，即使实际内容平均只有200个字符，某些导出方式仍会按最大长度预留空间，导致生成的CSV文件体积虚增数倍，严重影响导出速度和后续解析效率。因此，在导出前，最好能对关键字段的真实数据长度分布有一个了解。