1. 从一次慢查询说起bulk collect 到底解决什么问题如果你写过 Oracle PL/SQL 的游标循环大概率见过这种写法fetch cur into v1, v2一行一行地取一行一行地处理。数据量小的时候没感觉一旦表里几十万上百万行循环跑起来就像用吸管喝汤——能喝到但太慢。bulk collect就是来解决这个问题的。它的核心思路是不再一行一行地取而是一次性把一批结果集加载到 PL/SQL 集合collection里然后在内存里遍历。官方文档里对它的定位很明确——在select into、fetch into、returning into这几类语句里把结果批量绑定到集合变量减少 PL/SQL 引擎和 SQL 引擎之间的上下文切换次数。这个「上下文切换」是性能差异的根源。每执行一次fetch intoPL/SQL 引擎就要把控制权交给 SQL 引擎取一行再交回来。取 10 万行就是 10 万次来回。而bulk collect一次取一批比如 1000 行来回次数直接降到 100 次。实测数据也印证了这一点10 万行时fetch bulk collect into大约 0.125 秒逐行fetch into要 1.25 秒左右差了将近 10 倍到 100 万行差距拉得更大。那这跟 TaoToken 有什么关系关系在于很多批量取数场景并不是在数据库本机跑完就结束了。你可能需要把 Oracle 里批量拉出来的数据交给大模型做字段清洗、分类打标、异常检测或者让模型帮你生成迁移脚本、写数据校验逻辑。这时候就需要一个统一的 API 通道来调用模型。TaoToken 提供的就是这样一个统一 Key 通道——你不用为每个模型厂商单独申请 Key、单独记 Base URL一个 Key 走通多家模型特别适合这种「数据库批量取数 模型批量处理」的流水线场景。这篇文章我会把bulk collect的几种典型用法讲透包括select into、fetch into、returning into、动态 SQL以及limit参数怎么调、forall怎么配合。然后给出在 TaoToken 统一 Key 通道下把批量数据送去模型处理的完整可复制配置和调用示例。适合正在做 Oracle 数据迁移、批量 ETL、或者想把数据库数据和 AI 处理串起来的同学。2. TaoToken 统一 Key 通道准备一个 Key 打通批量取数与模型调用在讲具体配置之前先把 TaoToken 这条通道的定位说清楚。它不是一个数据库工具而是一个模型 API 的统一入口。你注册之后拿到一个 Key这个 Key 可以调用平台上支持的多种模型。对于bulk collect这种批量取数场景它的价值在于你从 Oracle 批量拉出来的数据往往需要做后续的智能处理而统一 Key 让你不用在多个厂商的控制台之间来回切换。2.1 获取 Key 与确认 Base URL第一步是拿到 API Key。访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册登录后进入控制台。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在 API Keys 页面可以创建和管理你的 Key。创建时建议给 Key 起一个能识别用途的名字比如oracle-bulk-etl方便后面排查问题时定位。创建完成后你会得到一串以sk-开头的 Key。这个 Key 就是后面所有调用的凭证。Base URL 统一用 https://taotoken.net/api 注意这个地址后面不加任何 UTM 参数直接写就行。这里有个细节要注意很多同学第一次配的时候会把 Base URL 写成带/v1或者带其他路径的形式结果请求 404。TaoToken 的 API 入口就是https://taotoken.net/api具体的路径比如/v1/chat/completions是在代码里拼接的不要提前写进 Base URL。2.2 三件套Base URL Key Model ID不管你后面用哪种客户端或 SDK接入任何模型都需要三样东西我把它叫做「三件套」配置项值说明Base URLhttps://taotoken.net/api统一入口不加 UTMAPI Keysk-xxxxxxxx控制台创建妥善保管Model ID如claude-sonnet-4-5等按平台文档填写这三件套在后面的 Python 脚本、Cline、Claude Code 等场景里都会反复出现。如果你用的是 Claude Code 这类工具还需要额外配置 Anthropic 兼容的接入方式文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 有详细说明。2.3 为什么批量取数场景适合统一 Key设想一个真实流程你有一张 50 万行的订单表需要批量拉出来让模型对每个订单的备注字段做情感分类再把结果写回数据库。如果每个模型厂商一个 Key你的脚本里要维护多套凭证换模型就要改代码。用 TaoToken 的统一 Key换模型只需要改 Model ID 一个参数Base URL 和 Key 都不动。对于bulk collect这种本身就在做「批量」的场景减少配置切换的成本很实际。另外批量处理往往要跑很久Key 的稳定性和额度管理很重要。在控制台里可以随时查看用量、调整额度避免跑到一半 Key 失效。这些准备工作做完就可以进入具体的bulk collect配置了。3. 可复制的 bulk collect 配置片段与 API 调用示例这一节是全文的核心我会给出可以直接复制运行的 PL/SQL 片段以及配套的 API 调用配置。先讲数据库侧的bulk collect再讲怎么把取出来的数据送到 TaoToken 通道。3.1 select into 中使用 bulk collect最简单的用法一次性把查询结果加载到集合里declare type object_list is table of t_test.object_name%type; objs object_list; begin select object_name bulk collect into objs from t_test where rownum 100; for r in objs.first .. objs.last loop dbms_output.put_line(objs( || r || ) || objs(r)); end loop; end; /注意objs.first .. objs.last这个遍历方式。集合的下标不一定是连续的用first和last比用1 .. count更稳妥。如果集合为空first和last都是 null循环不会执行不会报错。3.2 fetch into 中使用 bulk collect 与 limit 分批数据量大时一次性全加载到 PGA 里会撑爆内存。这时候用limit分批取declare type objecttab is table of t_test%rowtype; objs objecttab; cursor cob is select object_id, object_name, object_type from t_test where rownum 10000; begin open cob; loop fetch cob bulk collect into objs limit 1000; exit when objs.count 0; dbms_output.put_line(count: || objs.count || first: || objs.first || last: || objs.last); for r in objs.first .. objs.last loop dbms_output.put_line(objs( || r || ) || objs(r).object_name); end loop; end loop; close cob; end; /这里有个坑要特别提醒exit when cob%notfound的位置。很多资料里写的是fetch ... ; exit when cob%notfound;但这样会漏掉最后一批数据。因为%notfound是在 fetch 之后才为 true 的如果最后一批刚好取完%notfound为 true但集合里其实有数据直接 exit 就丢了。正确做法是用exit when objs.count 0或者把 exit 放在遍历之后。我试过用%notfound的写法结果最后一批记录没处理排查了半天。3.3 returning into 中使用 bulk collect做 DML 操作时想把受影响的行批量拿回来用returning intodeclare type id_list is table of t_test.object_id%type; ids id_list; type name_list is table of t_test.object_name%type; names name_list; begin delete from t_test where object_id 87510 returning object_id, object_name bulk collect into ids, names; dbms_output.put_line(deleted || sql%rowcount || rows:); for i in ids.first .. ids.last loop dbms_output.put_line(object # || ids(i) || : || names(i)); end loop; end; /returning into配合bulk collect在数据归档、软删除场景里很好用——删之前先把要删的数据捞出来写到归档表或者送去模型做审计分析。3.4 动态 SQL 与 forall 配合动态 SQL 里也能用bulk collect配合forall做批量 DMLdeclare v_query_sql varchar2(500); type type_emp_table is table of emp%rowtype index by binary_integer; v_emp_table type_emp_table; begin v_query_sql : select * from emp; execute immediate v_query_sql bulk collect into v_emp_table; forall i in 1 .. v_emp_table.count insert into emp_bak values v_emp_table(i); end; /forall是bulk collect的黄金搭档。for循环里逐条 insert每条都要一次上下文切换forall一次性把整个集合的 DML 提交给 SQL 引擎效率提升明显。注意forall的下标范围用1 .. count或者first .. last都行10g 以上还支持indices of可以处理非连续下标的集合。3.5 把批量数据送到 TaoToken 通道数据库侧取完数接下来是模型调用。下面是一个 Python 脚本用 OpenAI 兼容的方式调用 TaoToken 通道把批量取出的数据分批送去处理import requests import json BASE_URL https://taotoken.net/api API_KEY sk-你的Key MODEL_ID claude-sonnet-4-5 def process_batch(records): prompt 请对以下订单备注做情感分类只返回 positive/negative/neutral\n prompt \n.join([f{i1}. {r} for i, r in enumerate(records)]) resp requests.post( f{BASE_URL}/v1/chat/completions, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json }, json{ model: MODEL_ID, messages: [{role: user, content: prompt}], temperature: 0 }, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content] # 模拟从 bulk collect 取出的批次 batch [发货很快, 包装破损了, 一般般吧, 质量很好] print(process_batch(batch))这段代码里BASE_URL、API_KEY、MODEL_ID就是前面说的三件套。批量处理时建议每批控制在 20 到 50 条太多会超出模型的上下文窗口太少则调用次数多、效率低。这个批大小和bulk collect的limit参数是类似的思路——都是在内存占用和调用次数之间找平衡。4. 验证请求与结果集校验确认批量取数真的生效配置写完怎么确认它真的按预期工作这一节给出验证动作包括数据库侧的结果集校验和 API 侧的请求验证。4.1 数据库侧用执行计划和统计信息校验先确认bulk collect确实减少了上下文切换。可以用set timing on和set serveroutput on跑一遍对比逐行 fetch 的耗时set timing on set serveroutput on size unlimited -- bulk collect 版本 declare type t is table of t_test%rowtype; v t; cursor c is select * from t_test where rownum 100000; begin open c; loop fetch c bulk collect into v limit 1000; exit when v.count 0; end loop; close c; end; /跑完看输出的Elapsed时间。再跑一遍逐行 fetch 的版本对比。如果数据量在 10 万以上bulk collect的耗时应该明显更低。另外可以用v$sesstat查看 session 的统计信息关注execute count和parse count的变化。结果集校验方面重点检查集合的count、first、last三个属性是否符合预期。比如limit 1000取 10000 行应该循环 10 次每次count都是 1000最后一次可能不足 1000。如果某次count为 0 但循环没退出说明 exit 条件写错了。4.2 API 侧用 curl 验证通道连通在把批量数据送进去之前先用一条简单请求确认 TaoToken 通道是通的curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 回复 OK 两个字母}], temperature: 0 }如果返回的 JSON 里有choices字段且message.content是OK说明通道正常。这一步很重要因为批量脚本跑起来之后如果报错你很难判断是数据库侧的问题还是 API 侧的问题。先单独验证 API能把问题范围缩小。4.3 端到端校验小批量跑通再放大不要一上来就跑 50 万行。先用rownum 100取 100 行走完整流程bulk collect取出、分批送模型、结果写回。确认每一步的输出都对再逐步放大到 1000、10000。这样出问题时容易定位。校验结果集时可以写一个简单的对账逻辑数据库里select count(*)的总数应该等于所有批次count之和。如果不等说明有批次被漏掉了回去检查 exit 条件。5. 本篇常见错误排查401、local proxy failed、reading choices 等批量取数和 API 调用串起来之后报错会来自两个方向。这一节把常见错误列出来对照排查。5.1 401 Unauthorized这是最常见的 API 侧错误。原因通常是 Key 写错、Key 过期、或者请求头格式不对。检查三点Key 是否以sk-开头且完整Authorization头的格式是否是Bearer sk-xxxBearer 和 Key 之间有一个空格Key 是否在控制台被禁用或删除。如果用的是环境变量确认变量名没拼错比如TAOTOKEN_API_KEY和TAOTOKEN_KEY是两回事。5.2 local proxy failed这个报错通常出现在客户端工具比如 Cline、Claude Code里意思是本地代理连接失败。排查方向确认 Base URL 填的是https://taotoken.net/api没有多余路径确认本机网络能正常访问该地址可以用 curl 测如果工具里有代理设置确认没有开启不必要的本地代理。注意这里说的是工具自身的网络配置不是让你去搞什么网络加速就是检查配置项填对没有。5.3 reading choices 相关报错如果报错信息里出现reading choices或者cannot read property choices of undefined说明返回的 JSON 结构和你预期的不一样。常见原因是请求根本没成功返回的是错误对象没有choices字段或者模型 ID 写错了导致返回错误。先打印完整的响应体看看不要直接取choices。在 Python 里可以print(resp.text)再解析。5.4 OAuth 相关报错有些工具比如 Claude Code走的是 OAuth 或者 Anthropic 兼容协议配置方式和普通 API Key 不同。如果报 OAuth 错误说明你用错了接入方式。Claude Code 的接入需要参考专门的文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里有说明。普通 API 调用不要走 OAuth 流程。5.5 bulk collect 侧的 ORA 错误数据库侧常见的是ORA-06550PL/SQL 编译错误和ORA-01403no data found。前者通常是集合类型声明不对比如%rowtype和%type混用后者是select into没查到数据bulk collect在没数据时不会报no data found但如果你用了into单变量就会报。另外ORA-06502数值或值错误往往是集合下标越界检查first .. last的范围。排查顺序建议先确认 API 通道单独能通curl 测试再确认数据库侧单独能跑PL/SQL 块测试最后再串起来。两边都单独验证过联调时的问题就好定位了。6. 把批量取数接进你的工作流从 API Keys 到 Coding Planbulk collect本身是数据库技能但把它和模型调用串起来之后就变成了一个完整的批量数据处理工作流。这个工作流要跑得顺几个入口需要提前配好。如果你只是偶尔跑一次批量分类用 API Keys 就够了。在控制台创建 Key配到脚本里跑完即止。控制台地址 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 页面可以管理多个 Key建议按用途分开建方便追踪用量。如果你要长期做这类批量 ETL或者需要让模型参与代码生成、脚本编写那 Coding Plan 更合适。它面向的是持续性的编码和 Agent 场景额度和管理方式跟按次调用不同。具体可以看 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。想先试试模型对话效果可以直接用 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 不用写代码就能验证模型对批量文本的处理质量。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各语言 SDK 的示例。最后给一个实用建议bulk collect的limit参数和 API 调用的批大小这两个值要一起调。数据库侧limit太大PGA 占用高API 侧批太大容易超上下文。我一般把limit设在 500 到 1000API 批大小设在 20 到 50两边都留有余量。跑之前先用小数据量验证确认对账无误再放大。这套流程跑顺之后几十万行的批量处理也就是几分钟的事。