写这篇东西的起因挺简单某次做测试环境准备需要把一套老环境里几十张基础配置表搬到新环境。最开始想着手写INSERT写了三张表就放弃了——字段多、数据多、有的表还有日期和LOB字段手工INSERT既容易漏字段又要处理各种格式问题。后来切到PL/SQL Developer的导出功能十分钟把几十张表的数据脚本全部生成完毕直接到新环境一跑就完事。类似这种“oracle使用PLSQL导出表数据”的需求在开发、运维和测试环境准备里实在太常见了所以把我实际用下来的操作步骤、选项含义和踩过的坑整理出来。这里说的PLSQL指的是大家日常都在用的PL/SQL Developer客户端工具不是Oracle数据库里那个PL/SQL语言。这篇内容适合正在做Oracle数据迁移、测试数据准备、报表交付的同学按里面的思路操作基本能覆盖日常九成以上的导数据场景。1. 三种导出入口别把表结构当表数据导出来1.1 三个入口分别管什么PL/SQL Developer里跟导出相关的入口主要有三个很多人一开始就被绕晕了Tools - Export User Objects导出的是对象定义也就是DDL脚本。表结构、索引、序列、视图、存储过程这些东西都会生成CREATE语句但表数据一般不带出来。Tools - Export Tables这是真正“导出表数据”的入口。它可以把指定表的数据生成INSERT语句也可以顺带生成建表、删表语句生成结果是一个完整的SQL脚本。查询结果窗口右键 - Export Results把某条SELECT语句的查询结果导出成CSV、文本、HTML、SQL等格式灵活性最高。三个入口的适用场景差别很大用错的话事情就白干了。我整理了一张表平时拿不准的时候直接对照入口产出内容典型适用场景Tools - Export User ObjectsDDL脚本建表、索引、约束等只需要在另一套环境重建表结构Tools - Export Tables表数据INSERT脚本可按需包含DDL数据迁移、测试数据准备导出结果窗口右键 Export ResultsCSV/Excel/SQL/HTML等文件报表交付、筛选部分数据、跨团队提供数据1.2 选错入口的代价我见过一个很典型的翻车案例有人要“把菜单表数据导到新环境”他点的是Export User Objects导出后在目标环境执行建表语句一条条跑得挺顺利执行完新环境里十几张空表整整齐齐但业务方跑起来直接说“菜单都没了”。查了半天才发现问题是导出的文件里压根没有INSERT语句数据一行都没带过去。反过来也有问题。只要几个字段的部分数据有人却用Export Tables把整张百万行表导了出来SQL文件好几个GB导入的时候目标库被拖垮也是常有的事。所以接到类似需求先别急着点菜单问清楚三件事要表结构还是表数据还是两者都要数据是全部导出还是只要部分字段、部分行最终交付物是什么格式——SQL脚本、CSV还是DMP文件这三个问题定了导出方式基本就定了。2. Export Tables整表数据导出的完整操作与每个勾选框的真实含义2.1 实际操作步骤用Export Tables导出表数据最常规的流程如下登录PL/SQL Developer在左侧Object Browser里展开Tables节点找到目标用户下的表。用鼠标配合Ctrl键勾选需要导出的表也可以直接选中一个表空间或一组表。点击菜单Tools - Export Tables有些汉化版本叫“导出表”。在弹出窗口里设置输出文件路径建议用纯英文路径避免某些版本解析中文路径出问题。根据需求勾选右侧的选项比如Create table、Drop table、Insert data等。设置完点右下角Export按钮左下角会出现进度状态等它跑完即可。导出完成后生成的SQL文件里面会按你勾选的顺序先DROP再CREATE再INSERT。文件本身是纯文本拿到目标环境后用SQL*PLUS执行最稳。2.2 关键选项逐项解读很多新手看到Export Tables界面里那一堆勾选框就懵了实际上每个选项含义都挺直白选项作用我的建议Create table生成建表语句包含字段定义目标环境没有表时建议勾上Drop table建表前先执行DROP TABLE避免重复执行报错通常建议勾脚本可以重复执行Include storage导出表空间、初始区大小等存储子句目标环境表空间名不一样就不要勾否则导入必报错Include privileges导出表的授权语句跨环境时一般不要勾目标用户权限未必一致Include sequence导出相关序列定义有自增序列依赖时按需勾选Include trigger导出相关触发器导数据时默认不勾触发器容易修改导入数据Insert data生成INSERT语句数据本体导表数据必须勾Use SQL*Loader format生成SQL*Loader格式的数据文件和控制文件超大批量导入时优先使用Commit every N rows每插入N行执行一次COMMIT推荐500或1000控制事务大小Use Oracle bulk binds批量绑定读取提高导出效率建议勾上大表导出速度有明显差别Where clause按条件只导部分行需要过滤数据时填在这里Format masks设置日期、时间戳等字段的输出格式强烈建议统一设置日期格式见下文这里单独提醒一下Format masks。如果不设置日期字段导出时会按当前会话的NLS参数转成字符串比如默认格式可能是RRRR-MM-DD时间部分直接丢成00:00:00。到了目标库再按目标会话的格式去解析轻则丢时分秒重则解析失败。我现在的习惯是导出前点开Format masks把日期类型统一设成YYYY-MM-DD HH24:MI:SS这样脚本可读性和准确性都有保证。2.3 多表导出时的外键顺序与导入姿势多张表一起导出时生成SQL文件里的表顺序就按你勾选的先后顺序排。如果表之间存在外键关系比如订单表引用用户表那必须先导入用户表再导入订单表。反过来INSERT子表时父表数据还没进去外键约束直接报错。解决办法有两个勾选表的时候注意父子顺序先父表后子表。导入前把外键约束先禁用数据导完再启用。示例语句ALTER TABLE t_order DISABLE CONSTRAINT fk_order_user; ALTER TABLE t_order ENABLE CONSTRAINT fk_order_user;至于执行方式小脚本直接在PL/SQL Developer的Command窗口里跑没问题。文件大了以后我还是建议用SQL*PLUSsqlplus 用户名/密码服务名 /tmp/export.sqlSQL*PLUS执行大脚本更稳出错信息也更直观而且不会像图形界面那样容易假死。3. 导出SQL文件执行后乱码与CLOB超限两个高频翻车现场3.1 中文乱码的完整排查链路“导出的时候文件里中文明明正常拿到另一套环境一执行库里全是问号或者乱码。”这个问题我踩过不止一次本质是字符集在传输链路上不一致导致的。Oracle的乱码涉及三层数据库字符集、客户端NLS_LANG、文件保存编码。任何一层不统一都会出问题。完整的排查链路是这样的先看源库的数据库字符集SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETERNLS_CHARACTERSET;再看导出时客户端的字符集是什么SELECT USERENV(LANGUAGE) FROM DUAL;用文本编辑器打开导出的SQL文件确认文件编码以及中文内容是否正常。到目标环境执行前确认目标客户端NLS_LANG的设置。Windows下一般在注册表的ORACLE键里或者通过环境变量设置Linux下直接看环境变量。最常见的错误组合是源库是AL32UTF8导出文件也是UTF-8编码但目标环境的客户端NLS_LANG写的是SIMPLIFIED CHINESE_CHINA.ZHS16GBK执行脚本时中文字符被按GBK解释进库后就成了乱码。解决办法很简单目标环境执行前把NLS_LANG统一成AL32UTF8export NLS_LANGAMERICAN_AMERICA.AL32UTF8Windows下改完注册表或环境变量后重启SQL*PLUS或PL/SQL Developer再试。如果改不了目标客户端环境还有一个备用方案把SQL文件用编辑器转成ZHS16GBK编码再执行让文件编码去适应目标客户端。总之三个环节必须对齐两个角色要么都走UTF-8要么都走GBK。3.2 CLOB字段超过4000字节的导出难题CLOB字段是导出表数据时另一个重灾区。普通的VARCHAR2字段内容短INSERT语句直接拼字符串没问题。但CLOB里存的内容一旦超过4000字节生成的INSERT语句里的字符串字面量就超过了Oracle的上限执行时直接报ORA-01704: string literal too long所以遇到含CLOB字段的表导出前我会先跑一条SQL看看最长的记录有多少SELECT MAX(DBMS_LOB.GETLENGTH(note)) FROM t_order_note;如果结果超过4000基本可以断定PL/SQL Developer导出的SQL脚本会挂在字符串长度问题上。这种情况下我有三个处理思路数据量不大且目标环境能直连源库直接用DBLINK复制最省事CREATE TABLE t_order_note_copy AS SELECT * FROM t_order_notedblink_old;数据量大直接用数据泵expdp导出DMP文件导入端用impdpCLOB没有字符串长度限制。少量数据又非要INSERT脚本用TO_CLOB(...)配合分段拼接可以绕过但脚本会非常啰嗦只适合一次性应急。另外还有个容易被忽略的隐患某些版本导出CLOB字段时可能只读前4K或前32K导致生成的文件里数据被静默截断导入后才发现文本不完整。因此导出后一定要复查CLOB字段的最大长度拿目标库和源库对比确认没有丢内容再做数据校验。4. 只要查询结果的话用Export Results省事得多4.1 操作路径与格式选择很多时候我们并不需要整张表的数据而是“把最近三个月的订单明细导出来发给业务方”。这种需求用Export Tables就显得笨重直接在SQL窗口里写SELECT返回结果后在结果网格上右键选Export Results就好。Export Results支持的格式很丰富CSV、Delimited Text、HTML、SQL、Excel、Word、XML都行。平时我用得最多的是CSV和SQL。CSV用于交给非技术人员和下游系统SQL用于快速生成一批INSERT语句比如造测试数据时会先查几条真实业务记录右键导出成SQL再改一改字段值插到测试环境。具体操作很直观写完SELECT并执行结果集返回。在结果网格任意位置右键选择Export Results。选输出文件路径和文件格式。设置行数等参数后点Export。4.2 三个容易翻车的细节Export Results看着简单但有几个细节不注意也会翻车。一是行数限制。导出对话框里有Rows设置有些版本默认只导当前结果集的一部分行。如果你以为把全量结果都导出了实际只导了前几千行那就是给业务方埋雷。我的做法是导出前先看一眼结果集总行数然后把Rows值设成明显大于这个数。数据量确实大的话建议在SELECT里用分页分批导出别一次拖太多数据到客户端内存。二是CSV的乱码问题。导出的CSV是UTF-8编码拿Excel直接打开经常全是乱码因为Excel默认按本地ANSI编码解析。解决办法是导出后用文本编辑器把CSV另存为带BOM的UTF-8格式或者导出时如果版本支持直接勾上带BOM。带BOM之后Excel就能正确识别文件编码中文显示不乱。三是日期字段的格式。和Export Tables一样查询结果导出时日期字段也会按NLS参数格式化。给下游系统交付CSV时最好在SELECT里就用TO_CHAR把日期格式固定比如SELECT user_id, user_name, TO_CHAR(create_date, YYYY-MM-DD HH24:MI:SS) AS create_date FROM t_user WHERE create_date DATE 2024-01-01;这样导出的文本就是你要的样子不受环境变量影响。5. 数据量超过百万行我为什么改用数据泵和SPOOL5.1 三种替代方式的命令速查PL/SQL Developer本质是一个SQL客户端导数据功能是附加能力。几十万行以内的表它导出SQL脚本完全没问题。但数据量再上去客户端内存、网络传输、脚本执行效率都会成为瓶颈这个时候就该换方案了。我平常用的替代方案有三个。第一个是传统exp/imp适合中小数据量、表不多、版本相近的环境exp 用户名/密码服务名 file/tmp/data.dmp log/tmp/exp.log tablesT_ORDER,T_USER imp 用户名/密码服务名 file/tmp/data.dmp log/tmp/imp.log tablesT_ORDER,T_USER ignorey commity buffer10485760传统exp/imp命令简单但效率一般而且Oracle官方现在主推数据泵。第二个是expdp/impdp数据泵适合大数据量、大表、整库迁移。使用前要先建目录并授权CREATE OR REPLACE DIRECTORY DMP_DIR AS /u01/backup; GRANT READ, WRITE ON DIRECTORY DMP_DIR TO 目标用户;然后执行导出expdp 用户名/密码服务名 directoryDMP_DIR dumpfiledata_%U.dmp tablesT_ORDER,T_USER parallel4 compressionall logfileexpdp.log数据泵可以并行、压缩、增量对千万级数据量的表来说比PL/SQL Developer的SQL脚本导出靠谱太多。第三个是SQL*PLUS的SPOOL命令适合轻量导CSV或TXT不依赖图形界面在服务器上就能跑SET FEEDBACK OFF SET HEADING OFF SET PAGESIZE 0 SET LINESIZE 32767 SET TRIMSPOOL ON SET TERMOUT OFF SPOOL /tmp/t_user.csv SELECT user_id || , || user_name || , || TO_CHAR(create_date, YYYY-MM-DD HH24:MI:SS) FROM t_user; SPOOL OFF这种方式打出来的文件可以用逗号分隔也可以用CHR(9)做TAB分隔。注意字段里如果本身含逗号或特殊字符最好用带引号的写法比如 || user_name || 避免下游解析错位。5.2 我目前的选型习惯不同场景用不同工具现在基本形成了固定习惯需求场景我的选择理由几十张配置表、每张几千行PL/SQL Developer Export Tables图形界面直观脚本可控临时给业务方发部分明细Export Results导出CSV灵活能选字段和行数百万级业务表整表迁移expdp/impdp不占用客户端内存可并行可压缩只要表结构Export User Objects或expdp contentmetadata_only干净不掺数据跨版本或无法使用DMPPL/SQL Developer导出纯SQL脚本通用性强SQL文件到处能执行选型之前我一般会先看一眼数据量级比如先跑个COUNT再看段大小SELECT COUNT(*) FROM t_order; SELECT SUM(bytes)/1024/1024 AS size_mb FROM user_segments WHERE segment_name T_ORDER;数据量明确以后再决定用工具还是数据泵避免导出到一半才发现文件巨大、导入过程痛苦不堪。最后说点个人习惯。我现在的默认工作流是小表用PL/SQL Developer导出SQL脚本所有日期字段统一Format maskCLOB超长或者整表数据量过大的情况直接上expdp交付给外部团队的数据一律用Export Results生成CSV并检查编码。这套流程跑了很长时间没出过大问题。如果你经常要做Oracle的数据导出建议也把这套思路沉淀成自己的固定操作能少踩很多坑。