UTL_FILE生成CSV最可靠但需解决目录权限和字符转义问题；ORA-01031因无CREATE ANY DIRECTORY权限，ORA-29285因FOPEN行宽默认1024太小，应设为32767；字段需手动双引号包裹并转义，NULL、DATE、CLOB须特殊处理；spool易出错且不适用大数据量，百万级导出必须用UTL_FILE切片容错。
直接用 UTL_FILE 在数据库服务器上生成 CSV 文件最可靠，但必须先解决目录权限和字符转义两个硬门槛；客户端工具（如 SQL Developer、spool）适合小数据量或临时导出，对几百万行容易断连或格式错乱。
UTL_FILE.FOPEN 报 ORA-29285 或 ORA-01031 怎么办
这两个错误分别对应「写入被截断」和「没权限建目录」，不是代码写错了，而是环境没配好。
-
ORA-01031：普通用户不能执行CREATE DIRECTORY，必须由SYS或有CREATE ANY DIRECTORY权限的账号操作。常见错误是开发账号自己跑CREATE OR REPLACE DIRECTORY export_dir AS '/path'，直接报错 -
ORA-29285：其实是UTL_FILE.FOPEN第四个参数（最大行宽）太小导致写入被截断，不是磁盘满。默认 1024 字节，但含中文、长文本的 CSV 行很容易超。安全写法是显式设为32767 - 目录名在
FOPEN中必须大写，哪怕建的时候写了小写——查ALL_DIRECTORIES确认DIRECTORY_NAME列全是大写 - 文件名不能带路径，只写
'data.csv'；路径由EXPORT_DIR这个 DIRECTORY 对象绑定
字段含逗号、换行、双引号时 CSV 解析失败
UTL_FILE.PUT_LINE 不做任何转义，原样输出字符串。CSV 解析器靠双引号包裹字段、双引号内再出现双引号要变成两个双引号来识别结构，必须手动处理。
- 所有需包裹的字段统一套双引号：
'"' || REPLACE(col, '"', '""') || '"' -
NULL值不能直接拼成空字符串，否则和真实空值无法区分。建议显式写成'NULL'或留空但加双引号：'""' -
DATE类型必须转字符串，且会话级NLS_DATE_FORMAT可能影响结果。开头加ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'更稳妥 -
CLOB超 4000 字节会被截断，必须用DBMS_LOB.SUBSTR(clob_col, 4000, 1)截取，或改用DBMS_SQL.DEFINE_COLUMN_LONG（复杂，小数据量不推荐）
SQL*Plus spool 导出 CSV 的坑
spool 方案把文件生成在客户端机器上，省去目录授权麻烦，但控制粒度粗、易丢数据，尤其网络不稳定时。
-
set colsep ,看似设分隔符，实际只对查询列之间生效；字段内容里的逗号不会被处理，照样破坏 CSV 结构 -
set linesize必须足够大（比如30000），否则超长行自动换行，CSV 就多出无效空行 - 无法动态拼接 SQL 中的变量（如日期条件），
define只能赋常量，var+execute写法在某些版本不生效 - 导出文件默认无 BOM，中文可能在 Excel 里显示乱码；加
set markup csv on（Oracle 12c+）可生成标准 CSV，但不支持自定义字段包裹逻辑
大数据量（百万级以上）导出别踩的雷
用 SQL Developer 点击导出几百万行，本质是把结果集全拉到本地内存再写文件，一旦网络抖动或客户端卡死，前功尽弃。
- 不要依赖客户端工具做大批量导出，
UTL_FILE是唯一可控方案 - 单文件太大（>2GB）可能触发操作系统限制，建议在 PL/SQL 循环中按行数切片，每 50 万行写一个新文件
-
UTL_FILE.FCLOSE必须执行，否则文件可能不完整；异常分支里加UTL_FILE.FCLOSE_ALL防止句柄泄漏 - 导出后检查文件末尾是否有不完整行（最后一行没换行符），
UTL_FILE.PUT_LINE自动加\n，但异常中断时可能残留半行
真正麻烦的从来不是写几行 PL/SQL，而是目录权限是否到位、字段内容是否合规、以及大数据量下有没有做容错切片——这些细节不提前验证，跑通一次不代表下次不出错。
