简介这是一份针对Oracle数据库特殊字段类型的实用技术文档面向需要处理Long、Raw、Blob等非标准字段的数据库开发、运维人员及.NET技术从业者系统讲解了三类字段的存储上限、适用场景与选型建议如Long在10g后宜改用Clob并基于Oracle 9i环境提供完整的建表语句和可运行示例。包内为1个PDF文档文件大小514KB内容紧凑不冗长除建表结构外还重点给出C#操作Blob图片字段的插入、更新与读取代码以及先将图片上传至服务器再写入数据库的典型流程对于Long和Raw类型也展示了参数化读写与取值时的核心处理方式。代码中包含EMP_ID、EMP_PICTURE等实际字段可直接转化为真实项目逻辑。通过这份材料读者能快速掌握Oracle不同数据类型的使用边界、OracleParameter参数绑定要点以及处理大数据字段时的性能关注项适合开发中遇到相关字段读写需求时对照查阅目前已有245人浏览学习。1. 为什么说Long、Raw、Blob这三个字段类型在Oracle读写里最容易翻车常年在Oracle数据库里搬数据的人几乎都遇到过这类场面接手的老系统表结构里静静躺着Long、Raw和Blob字段脚本一执行就蹦出ORA-00932或ORA-01704明明数据量不大读写却一直卡在原地。这三个字段类型分别代表Oracle在长文本、二进制字节串和LOB大对象上的三套处理体系Long限制多到让人想把表重做Raw读写要依赖十六进制转换Blob则离不开dbms_lob包和定位器。这篇笔记整理的就是这三种字段类型的读写例子从建表、插入、取数到最常见的报错排查适合正在写Oracle存储过程、做数据迁移或者接手老系统的工程师照着复现。先能把活儿干通再去纠结性能和优化。2. 先把类型选对再谈读写Long、Raw、Blob的底层差异2.1 Long类型容量大、限制也大的老牌字符串类型Long是Oracle 7时代就在用的变长字符串类型最大能到2GB当年CLOB还没出来时大段文本全靠它扛着。但Oracle官方早已不推荐用Long建新表19c里虽然还能正常读写文档里也明确列了一串限制一个表最多只能有一个Long列Long不能出现在WHERE条件里不能做ORDER BY、GROUP BY不能建索引不能和LOB列放在同一张表。这意味着一张业务表如果既有Long又有Blob在Oracle建表阶段就过不去现实里看到这种需求时只能按“主表附表”拆开设计。实际开发中Long最常见的存在形式是历史遗留表。比如老的生产管理系统、工单系统的备注字段或者从Oracle 9i/10i迁移过来的数据源字段类型一查还是Long。它的数据处理逻辑和VARCHAR2完全不一样在SQL里对Long列做任何运算包括拼接、比较、转大写几乎都会触发ORA-00932。反而是把它原样查出来在PL/SQL里用变量承接后才好操作。我接触这类表时的习惯是能不动Long就不动。查询时要么直接select整列要么用SUBSTR截取前4000个字符转成VARCHAR2处理。如果应用端必须要完整内容考虑在迁移层先把Long转成CLOB或者通过临时表过渡避免每次查询都跟限制硬碰硬。判断一个存量字段该不该继续用Long先看它有没有参与条件过滤如果只是展示和存储风险还可控一旦业务需求要在SQL层做字符串替换或排序那就趁早往CLOB迁移。2.2 Raw类型就是字节串和字符串有本质区别Raw在Oracle里是变长二进制类型存的是字节序列不经过字符集转换。11g及以前版本上限是2000字节12c版本把上限提高到32767字节。适合的场景很明确哈希值、加密盐、数字签名、序列化对象这些“本质上不是给人看的文本”的数据。用VARCHAR2也不是不行但要担心隐式转换在字符集不一致时把字节搞乱而且很多加密函数返回值本身就是RAW所以直接用Raw列承接最自然。Raw的读写入口就是两个函数HEXTORAW把十六进制字符串转成字节RAWTOHEX把字节转回十六进制字符串。如果在Java或Python侧已经拿到了byte[]那插入时就用参数绑定把字节数组直接传进去不需要在SQL里拼接十六进制。参数绑定还有个好处避免长十六进制字符串在SQL文本里膨胀也不容易触发ORA-01704。这里还要注意一个容易误判的点Raw字段在SQL客户端里显示出来往往是一串十六进制比如“0A0B0C”如果某工具把它按UTF-8或GBK解释显示就会变成乱码。这不代表数据坏了只是显示层的差异换一个十六进制视图或加RAWTOHEX再看就正常了。我在排查Raw字段的问题时从来不在客户端肉眼看值而是先RAWTOHEX再对比这样能省掉一大半无意义的“数据损坏”误报。2.3 Blob类型需要定位器和dbms_lob包的大对象Blob是Oracle的二进制大对象上限可以到4GB它是比Raw更“重”的存在。两者的核心区别在于Raw的存储是跟着行走的读出来就是完整的字节Blob则要靠一个LOB定位器locator才能找到实际数据操作必须通过dbms_lob包完成。这意味着Blob列不能像普通字段那样随便赋值。insert时不显式初始化进去的就是NULL之后再用dbms_lob.writeappend去写会直接报无效LOB定位器。正确的标准操作是insert时写EMPTY_BLOB()然后再select ... for update锁定行把定位器取到PL/SQL变量里最后用DBMS_LOB.WRITEAPPEND或DBMS_LOB.WRITE把字节写进段。读的时候也一样必须先SELECT拿到定位器再用DBMS_LOB.SUBSTR或DBMS_LOB.READ按偏移量读取。另外Blob的存储按chunk组织chunk大小跟表空间块尺寸相关常见的是8KB。写入或读取时按这个尺寸对齐明显比一次只读几十字节高效。选择Blob还是Raw判断标准主要是数据规模和操作频率几千字节以内、需要频繁参与比较运算的用Raw几十KB到GB级、以整体读写为主的二进制附件用Blob。一个常见的反面案例是有人把几百KB的图片转成十六进制塞进Raw结果单行就膨胀成原来两倍查询时还要先转回RAWTOHEX反倒不如直接用Blob干净。3. 照抄能跑的读写例子从建表、插入到读取代码3.1 分表建表Long单独建表Raw和Blob同表因为Long和LOB不能放在同一张表实践里的做法是拆成两张表演示一张放Long字段一张放Raw和Blob。先建Long的演示表再建二进制字段的演示表。这样既符合Oracle对表结构的限制也方便后面各节单独跑例子。-- 表1演示Long字段 CREATE TABLE demo_long ( id NUMBER PRIMARY KEY, long_col LONG ); -- 表2演示Raw和Blob字段 CREATE TABLE demo_bin ( id NUMBER PRIMARY KEY, raw_col RAW(2000), blob_col BLOB );逻辑说明demo_bin表里同时容纳Raw和Blob没有限制RAW(2000)表示该列最多存2000字节的二进制数据。如果你的Oracle版本是12c以上RAW长度上限可以写到32767但要注意这会影响行迁移和存储开销不是越大越好。Blob列不指定长度因为它的实际上限受表空间和数据库块大小影响。3.2 Long的读写插入、取数和Long转字符串的正确姿势插入Long字段和插VARCHAR2区别不大短文本可以直接写SQLINSERT INTO demo_long (id, long_col) VALUES (1, 工单备注设备巡检正常无异常告警。); COMMIT;这里如果字面量超过4000字节会遇到ORA-01704因为SQL文本里的字符串字面量上限就是4000字节。因此对Long字段写入大文本不建议直接写insert语句更稳的是在存储过程中用绑定变量DECLARE v_text VARCHAR2(30000) : 很长很长的文本内容从应用层传入; BEGIN INSERT INTO demo_long (id, long_col) VALUES (2, v_text); COMMIT; END; /逻辑说明PL/SQL里的VARCHAR2变量最大能到32767字节用它当中间变量绕过SQL字面量4000字节限制。这也是“Long类型相加”和“Long转字符串”场景里最常用的入口先把Long读出来再用SUBSTR或拼接处理。读取Long的PL/SQL例子如下。关键点是不要在SQL里写TO_CHAR(long_col)那会触发ORA-00932用SUBSTR在PL/SQL里截断后再做字符串处理。DECLARE v_long LONG; v_head VARCHAR2(4000); BEGIN SELECT long_col INTO v_long FROM demo_long WHERE id 1; -- Long变量只能通过SUBSTR这类函数截成字符串使用 v_head : SUBSTR(v_long, 1, 4000); DBMS_OUTPUT.PUT_LINE(v_head); END; /如果要把Long完整转成CLOBOracle提供了TO_LOB函数只是这个转换不能在SQL里直接对Long列生效必须先把Long读到PL/SQL变量里再赋值给CLOB变量DECLARE v_long LONG; v_clob CLOB; BEGIN SELECT long_col INTO v_long FROM demo_long WHERE id 1; -- 利用TO_LOB把Long变量转成CLOB后续操作就自由多了 v_clob : TO_LOB(v_long); DBMS_OUTPUT.PUT_LINE(DBMS_LOB.SUBSTR(v_clob, 100, 1)); END; /3.3 Raw的读写HEXTORAW与RAWTOHEX两个方向的操作例子插入Raw字段的标准写法是用HEXTORAW把十六进制字符串转成二进制INSERT INTO demo_bin (id, raw_col) VALUES (1, HEXTORAW(CAFEBABE)); COMMIT;读取时用RAWTOHEX把字节转回十六进制方便在客户端核对SELECT id, RAWTOHEX(raw_col) AS hex_value FROM demo_bin WHERE id 1;如果确认Raw里存的字节本来就是可打印的ASCII或UTF-8文本可以用UTL_RAW.CAST_TO_VARCHAR2直接转字符串DECLARE v_raw RAW(2000); v_str VARCHAR2(100); BEGIN SELECT raw_col INTO v_raw FROM demo_bin WHERE id 1; -- 只有确定Raw内容是文本时才转字符串否则会得到乱码 v_str : UTL_RAW.CAST_TO_VARCHAR2(v_raw); DBMS_OUTPUT.PUT_LINE(v_str); END; /逻辑说明这三个例子覆盖了Raw读写的三个方向——进入数据库、以十六进制展示、按文本还原。重点在于UTL_RAW.CAST_TO_VARCHAR2只适合“明确知道字节内容就是文本”的场景如果是哈希值或加密盐转出来的东西必然乱码要看就用RAWTOHEX或者对哈希值做等值比较。3.4 Blob的读写insert加empty_blob()写入用dbms_lob.writeappendBlob的完整写入流程比Raw多两步初始化定位器和锁定行。先插入一条带EMPTY_BLOB的演示数据INSERT INTO demo_bin (id, raw_col, blob_col) VALUES (2, HEXTORAW(FF00), EMPTY_BLOB()); COMMIT;注意如果insert时省略EMPTY_BLOB()Blob列就是NULL后面不管writeappend还是SUBSTR都会报无效LOB定位器。这是新手最容易遇到的第一道坎。写入Blob内容的标准做法是select ... for update拿到定位器再调用DBMS_LOB.WRITEAPPENDDECLARE v_blob BLOB; v_data VARCHAR2(2000) : 这是一段要写入Blob的文本内容; BEGIN SELECT blob_col INTO v_blob FROM demo_bin WHERE id 2 FOR UPDATE; -- WRITEAPPEND三个参数定位器、字节长度、RAW类型的数据 DBMS_LOB.WRITEAPPEND(v_blob, LENGTH(v_data), UTL_RAW.CAST_TO_RAW(v_data)); COMMIT; DBMS_OUTPUT.PUT_LINE(写入字节数 || DBMS_LOB.GETLENGTH(v_blob)); END; /逻辑说明select...for update锁定该行并把定位器赋给v_blobWRITEAPPEND第一个参数是定位器第二个参数是写入字节数第三个参数必须是RAW类型所以要用UTL_RAW.CAST_TO_RAW把普通字符串转一下。提交之后再用GETLENGTH确认写入量。读取Blob的对称写法是SUBSTR加CAST_TO_VARCHAR2DECLARE v_blob BLOB; v_out VARCHAR2(2000); BEGIN SELECT blob_col INTO v_blob FROM demo_bin WHERE id 2; -- 从偏移1开始最多读2000字节转成RAW后再还原字符串 v_out : UTL_RAW.CAST_TO_VARCHAR2(DBMS_LOB.SUBSTR(v_blob, 2000, 1)); DBMS_OUTPUT.PUT_LINE(v_out); END; /如果读的是真正的二进制文件就不要转字符串而是把DBMS_LOB.SUBSTR返回的RAW逐段交给文件流去组装。一次性SUBSTR几万字节不是不行但对内存不友好后面第5章会讲分段读的边界。4. 避坑Long、Raw、Blob最常见的5个报错与排查记录4.1 ORA-00932Long列出现在WHERE和ORDER BY里现象对Long列做等于判断比如SELECT * FROM demo_long WHERE long_col abcOracle直接报ORA-00932: inconsistent datatypes脚本停在这一步。想给Long列排序、分组也一样尤其分页报表里只要ORDER BY long_col就翻车。原因Long类型不允许出现在WHERE、ORDER BY、GROUP BY和比较表达式中这是Oracle的硬限制不是写错了语法。很多从MySQL或PostgreSQL转过来的开发习惯性地把大文本字段当普通字符串用到这就会卡住。解决思路不要试图让Long参与条件运算。先通过主键id把目标行取出来再在PL/SQL里用SUBSTR截取段字符串之后做比较如果没有主键先给表补一个序列或rowid当临时条件。分页场景下先按id排序取回主键集合再在应用层或外层查询里拼接Long文本绝不能让Long直接进排序子句。-- 反例会报ORA-00932 -- SELECT * FROM demo_long WHERE long_col abc; -- 正例先用id定位 SELECT id, long_col FROM demo_long WHERE id 1;4.2 ORA-01704字符串字面量太长SQL里直接塞大文本必翻车现象把一段几千字的文本直接写在INSERT语句里Oracle抛ORA-01704: string literal too long。这个问题在导入SQL文件时最常出现网上一搜“oracle 导入sql ora-01704”全是问这个的。原因SQL文本中的字符串字面量上限是4000字节跟目标列是VARCHAR2还是CLOB没关系哪怕插入的是CLOB列也会报。解决把长文本从SQL字面量挪到绑定变量或PL/SQL变量里再执行插入。应用层如果走Web后端前端把文件以Blob对象提交上来服务端接收后先转成byte[]再用PreparedStatement的setBytes写到BLOB列不要手工拼十六进制长串。手头只有SQL文件时建议用SQL*Loader或存储过程分批处理别指望一句insert解决所有事。4.3 Blob读出来是空多半是empty_blob()没用好现象insert后马上select blob_col看到NULL或者在PL/SQL里select blob_col into v_blob后DBMS_LOB.GETLENGTH返回0后续操作全报无效LOB定位器。原因insert时没有写EMPTY_BLOB()Blob定位器是空的另一种情况是insert后没有commit就另开一个会话去读事务隔离导致看不到未提交的写入读出来当然也是空。解决insert时显式用EMPTY_BLOB()初始化并在同一个事务里select...for update完成写入再commit。读取前先确认GETLENGTH大于0再决定是否继续。这个判断写进存储过程里能省掉很多莫名其妙的空值报错。4.4 Long和LOB同表导致建表或迁移失败现象建表或加列的脚本里既有Long又有BlobOracle直接拒绝执行有的版本报ORA-00907或ORA-00932。把别人的建表脚本拿过来跑第一次就卡在这一步。原因Oracle官方限制一个表不能同时有Long和LOB列CLOB、Blob都是一样这也是为什么所有Long相关的读写例子都要把表拆开演示。很多人拿到老库的SQL脚本看到Long和Blob出现在同一个CREATE TABLE里第一反应是改语法实际上这是类型层面的架构问题。解决拆表设计主表放普通字段和Long附表放业务主键、Raw和Blob通过id关联如果历史表已经有Long又想加Blob新建附表而不是在源表上ALTER。迁移到新库时建议直接把Long列转成CLOB这样后续和Blob共存就不会再受这个限制困扰。4.5 Raw列显示乱码先别怀疑数据坏了现象select raw_col出来是“¼mº”这种乱码同事第一反应是数据坏了实际上往下查又发现业务功能正常。原因Raw本身就是二进制字节SQL客户端按字符集去渲染遇到不可打印字节自然显示成乱码。字节没有损坏是显示层的问题。解决排查时用RAWTOHEX(raw_col)看十六进制内容或切换客户端的Hex视图只有确认原始字节是文本时才用UTL_RAW.CAST_TO_VARCHAR2转换。批量巡检Raw字段一致性更靠谱的方式是直接比较RAW值或者用DBMS_LOB.COMPARE不要靠人眼比对。5. 验证与进阶确认写入数据一致再谈高效读Blob5.1 用DBMS_LOB.COMPARE验证Blob写入前后是否一致写完Blob之后只确认了GETLENGTH还没确认字节内容完整。更稳妥的验证方式是写入前保存原始RAW写入后再读出来做一次等值比较。DBMS_LOB.COMPARE可以比较两段LOB也可以把读出的RAW直接和期望值比较DECLARE v_blob BLOB; v_expected RAW(2000); v_read RAW(2000); BEGIN -- 期望数据来自写入前的原始字节 v_expected : UTL_RAW.CAST_TO_RAW(这是一段要验证的文本); SELECT blob_col INTO v_blob FROM demo_bin WHERE id 3; -- 从Blob偏移1开始读长度与期望值相同 v_read : DBMS_LOB.SUBSTR(v_blob, LENGTH(v_expected), 1); IF v_read v_expected THEN DBMS_OUTPUT.PUT_LINE(读取结果与写入值一致); ELSE DBMS_OUTPUT.PUT_LINE(数据不一致检查写入流程); END IF; END; /这个做法的好处是不依赖外部工具在PL/SQL里就能完成校验。数据量更大时还可以把关键行专门做成一张校验表记录每次迁移前后的Blob哈希值判断中间环节是否丢字节。5.2 分段读取的边界习惯处理几MB以上的大Blob不要指望一次DBMS_LOB.SUBSTR拉全。常见做法是固定4KB或8KB为一片用循环把每片字节追加到目标文件或拼成字节流再交给应用层。这里要强调一个参数边界SUBSTR的第三个参数是起始偏移量每次循环要加一整个片长否则会一直从开头读。我习惯在倒数据时每读4096字节就打印一个进度点既能确认任务没僵住也方便定位哪一段数据出错。DECLARE v_blob BLOB; v_buf RAW(4096); v_offset NUMBER : 1; v_len NUMBER; BEGIN SELECT blob_col INTO v_blob FROM demo_bin WHERE id 2; v_len : DBMS_LOB.GETLENGTH(v_blob); WHILE v_offset v_len LOOP -- 每次从v_offset位置读4096字节 v_buf : DBMS_LOB.SUBSTR(v_blob, 4096, v_offset); -- 这里把v_buf追加到文件流或交给应用层处理 v_offset : v_offset 4096; END LOOP; END; /除了分段还要克制“顺手select大字段”的欲望。如果一条SQL里同时选Blob和几个大文本字段结果集在内存里会迅速膨胀网络传输也慢。更好的做法是先只取id和定位器按业务需要再一层层读Blob。这些年我经手的老系统里Long和Blob并存的表基本都成了数据迁移的焦点。每次把老表数据导出来我都先做一次字节级比对再交付下游这个习惯帮我避掉好几次“看起来能跑但内容差了半截”的事故。边界条件和参数记牢遇到Long、Raw、Blob的活儿就不发怵了希望帮到你。本文还有配套的精品资源点击获取