先说说我的背景：之前处理4000万行海量数据时，一开始用多线程JDBC Cursor（还调过fetch size）读分区数据，但生产环境里数据库查询慢到离谱，作业根本赶不上时间要求。后来临时改用SQL Developer手动导出CSV再拆成小文件，性能直接起飞，才按时完成了任务。现在要把这个导出步骤自动化（打算用Java应用来做），纠结下面三个方案哪个速度更快，想请教有经验的朋友：

• sqlplus（Java通过本地调用执行）
• SQLcl并行spool
• 结合utl_file与dbms_parallel_execute的PL/SQL存储过程

作为常年跟Oracle数据导出打交道的开发者，我来给你分析下这三个方案的速度和适用场景：

1. sqlplus（Java本地调用） #

这个方案的速度只能算中规中矩。sqlplus是老牌的命令行工具，但单线程跑的话处理4000万行肯定慢，要是想并行，你得自己写逻辑拆分数据分区、启动多个sqlplus进程，Java还要处理进程的启动、输出捕获、异常处理，这些额外的开销都会拖慢整体速度。好处是上手简单，Java调用的逻辑很成熟，不需要特殊的数据库权限，但真心不推荐用来搞这么大规模的数据导出。

2. SQLcl并行spool #

SQLcl是Oracle官方用来替代sqlplus的工具，原生支持并行spool，这一点太香了！你只要配置好并行度，它会自动拆分数据并行导出，底层的优化比sqlplus好很多，并行模式下能充分榨取数据库和IO资源，速度比单线程sqlplus快一大截，应付4000万行完全没问题。Java调用的时候直接传命令行参数就行，不用写复杂的并行逻辑。唯一要注意的是环境里得装SQLcl，不过现在大部分新一点的Oracle环境都支持，权限要求和sqlplus差不多。

3. 结合utl_file与dbms_parallel_execute的PL/SQL存储过程 #

这绝对是三个方案里速度最快的！因为所有导出逻辑都在数据库内部执行，没有客户端和服务器之间的网络传输开销（如果导出文件直接写在数据库服务器的磁盘上）。dbms_parallel_execute可以把大表拆成多个任务块，并行用utl_file写入文件，完全利用数据库的并行处理能力。而且自动化的时候，Java只需要调用这个存储过程就行，逻辑特别简洁。不过缺点也有：需要更高的数据库权限（比如UTL_FILE的读写权限、DBMS_PARALLEL_EXECUTE的执行权限），要是你得把文件弄到应用服务器，还得额外加文件传输的步骤（比如FTP），对数据库经验有限的开发者来说，调试起来可能有点麻烦。

总结建议 #

如果你们DBA能给你足够的数据库权限，优先选方案3，性能拉满，适合处理这种级别的海量数据。如果权限受限，或者不想写复杂的PL/SQL，方案2的SQLcl并行spool是次优选择，配置简单，速度也够用。方案1的sqlplus就别考虑了，小数据量凑合用，4000万行真的太慢。

内容的提问来源于stack exchange，提问作者Rob Wilkinson