utl_file是oracle中pl/sql写文件的唯一原生方式，但需同时满足三条件：dba创建真实存在的directory对象、用户获read/write权限、oracle进程对目录有操作系统级读写权限；否则必报ora-29283等错。
UTL_FILE 是 Oracle 中唯一能在 PL/SQL 里直接写文件的原生方式，但必须配合数据库目录对象和操作系统权限才能生效。单纯写个存储过程，90% 的情况会报 ORA-29283: invalid file operation 或 ORA-06512: at "SYS.UTL_FILE" —— 不是代码错，是环境没配好。
为什么用 UTL_FILE 导出 CSV 容易失败
根本原因不是 PL/SQL 语法问题，而是三道硬门槛缺一不可：
-
CREATE DIRECTORY必须由 DBA 执行，且路径需真实存在于数据库服务器（不是你本地机器） - 执行用户必须有
READ和WRITE权限：GRANT READ, WRITE ON DIRECTORY export_dir TO your_user; - Oracle 参数
utl_file_dir已废弃（11g+ 强制使用DIRECTORY），但若残留旧配置可能干扰判断 - 文件系统权限：Oracle 进程（如
oracle用户）必须对目标目录有drwxr-xr-x权限，否则FOPEN直接拒绝
SQL_TO_CSV 存储过程的关键改造点
网上流传的通用 SQL_TO_CSV 过程看似能跑，但实际生产环境会踩三个坑：
- 日期字段默认不格式化 → 导出成
01-JUL-26，Excel 无法识别为日期 → 在过程开头加：EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_DATE_FORMAT=''YYYY-MM-DD HH24:MI:SS'''; - 字段含换行符或双引号时未转义 → CSV 解析失败 → 必须用
REPLACE(col, '"', '""')并包裹双引号 - 大字段（如
CLOB）直接DBMS_SQL.COLUMN_VALUE会截断 → 改用DBMS_LOB.SUBSTR(clob_col, 4000, 1)分段读取 -
UTL_FILE.FOPEN第四个参数（max_linesize）不能省略，尤其当某行超 32767 字节时 → 建议设为32000，避免ORA-29285: file write error
替代方案：SQL*Plus spool 更快更稳
如果你只是导出单表、不需要动态 SQL 或复杂逻辑，spool 是最可靠的选择，尤其适合 11g 及以上版本：
- 中文乱码？先设环境变量：
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8（Linux/macOS）或set NLS_LANG=AMERICAN_AMERICA.AL32UTF8（Windows cmd） - 字段含逗号/双引号？手动包裹并转义：
SELECT '"' || REPLACE(name, '"', '""') || '"' FROM emp; - 不想导出列头？
SET HEADING OFF；要列头但去重？SET PAGESIZE 0+SET FEEDBACK OFF - 行太长被截断？
SET LINESIZE 32767（11g 最大支持值），再配合SET TRIMSPOOL ON
示例命令序列：
sqlplus / as sysdba SET COLSEP ',' PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING ON TRIMSPOOL ON SPOOL /tmp/emp.csv SELECT id, '"' || REPLACE(name, '"', '""') || '"', age, dept FROM emp; SPOOL OFF
PL/SQL Developer 导出仅限客户端，不走数据库服务端
工具界面点“Export Query Results → CSV”本质是客户端把查询结果拉到本地内存再写文件，和 UTL_FILE 或 spool 完全无关：
- 优点：无需目录权限、无字符集烦恼、支持中文自动编码（UTF-8 BOM）
- 缺点：数据量 > 10 万行时容易卡死或内存溢出；无法定时、无法嵌入自动化流程
- 注意：导出前务必确认“Query Result”窗口已完整加载全部数据（滚动到底部看是否还有“Fetching…”）
真正需要自动导出、大表、或服务器直出时，绕不开 UTL_FILE 的权限配置和 spool 的参数调优——这两条路没有捷径，错一个参数就卡住。
