尧图网页设计 
1. 从一次批量更新卡死说起Oracle 游标遍历到底该选哪种写法如果你写过 PL/SQL 存储过程大概率遇到过这种场景一张几十万行的表需要逐行做业务判断再更新用FOR循环跑起来看着挺顺结果上线后跑了几十分钟还没结束甚至把 UNDO 表空间撑爆。问题往往不在 SQL 本身而在游标遍历方式选错了。Oracle 里遍历游标至少有四种常见写法FOR循环、FETCH循环、WHILE循环、BULK COLLECT FOR。它们语法上都能跑通但在批量数据处理场景下性能差距可能是几倍到几十倍。这篇文章不空谈理论我会给出可复制的建表脚本、四种写法的完整代码、实测耗时对比以及用 TaoToken 统一 API 通道辅助生成和校验 SQL 的具体操作帮你快速定位适合自己业务的方案。先说结论方向小数据量、逻辑简单FOR循环最省心需要精细控制游标状态用FETCH或WHILE真正面对大批量数据BULK COLLECT配合LIMIT才是正解。下面一步步拆开讲。2. 测试环境与建表脚本先有一张能跑的数据表在对比之前得先有一张结构清晰、数据量可控的表。我用的是一张玩家信息表player_info字段简单方便你把注意力放在游标写法上而不是被业务逻辑干扰。-- 建表玩家信息表 CREATE TABLE player_info ( player_id NUMBER(10) NOT NULL, player_name VARCHAR2(64) NOT NULL, level_no NUMBER(3) DEFAULT 1, create_time DATE DEFAULT SYSDATE, CONSTRAINT pk_player_info PRIMARY KEY (player_id) ); -- 插入测试数据这里用 connect by 快速造 10 万行 INSERT INTO player_info (player_id, player_name, level_no) SELECT LEVEL, player_ || LEVEL, MOD(LEVEL, 100) 1 FROM dual CONNECT BY LEVEL 100000; COMMIT; -- 收集统计信息让优化器有准确判断 BEGIN DBMS_STATS.GATHER_TABLE_STATS(USER, PLAYER_INFO); END; /数据量我特意设成 10 万行因为 1355 行这种小表四种写法耗时都在毫秒级根本看不出差异。只有数据量上去BULK COLLECT的优势才会暴露出来。另外提醒一点测试时把DBMS_OUTPUT输出关掉或重定向否则输出本身会成为瓶颈掩盖真实的游标遍历性能。下面代码里我会用累加变量代替PUT_LINE只统计处理行数。-- 开启输出缓冲仅调试用压测时建议注释掉 PUT_LINE SET SERVEROUTPUT ON SIZE UNLIMITED;环境准备好后我们进入正题。四种写法我会给出完整可执行代码每段都能直接贴进 SQL Developer 或 SQLPlus 跑。3. 四种游标遍历写法完整代码与 TaoToken 辅助校验这一节是核心。我会先给出四种写法的完整代码然后演示如何用 TaoToken 的 API 通道让模型帮忙检查 SQL 语法和潜在性能问题。3.1 FOR 循环最简洁隐式游标自动管理FOR循环分显式和隐式两种。显式游标需要DECLARE声明隐式游标直接把查询写在FOR里。-- 方式1-A显式游标 FOR 循环 DECLARE CURSOR cur_player IS SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id; v_count NUMBER : 0; BEGIN FOR rec IN cur_player LOOP v_count : v_count 1; -- 实际业务逻辑写这里比如条件更新 END LOOP; DBMS_OUTPUT.PUT_LINE(FOR显式处理行数: || v_count); END; / -- 方式1-B隐式游标 FOR 循环 BEGIN FOR rec IN (SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id) LOOP NULL; -- 业务逻辑 END LOOP; END; /FOR循环的好处是游标的OPEN、FETCH、CLOSE全由 Oracle 自动管理你不用操心%NOTFOUND判断也不会忘记关游标。缺点是每次只取一行行与行之间有一次上下文切换数据量大时开销明显。3.2 FETCH 循环手动控制灵活但易错FETCH循环需要显式OPEN、FETCH、CLOSE退出条件靠%NOTFOUND。-- 方式2FETCH 循环 DECLARE CURSOR cur_player IS SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id; rec cur_player%ROWTYPE; v_count NUMBER : 0; BEGIN OPEN cur_player; LOOP FETCH cur_player INTO rec; EXIT WHEN cur_player%NOTFOUND; v_count : v_count 1; END LOOP; CLOSE cur_player; DBMS_OUTPUT.PUT_LINE(FETCH处理行数: || v_count); END; /注意EXIT WHEN必须紧跟在FETCH之后否则会多处理一行或漏处理。这是新手最容易踩的坑。3.3 WHILE 循环FETCH 要写两次WHILE循环的写法比较别扭因为要在进入循环前先FETCH一次循环体末尾再FETCH一次。-- 方式3WHILE 循环 DECLARE CURSOR cur_player IS SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id; rec cur_player%ROWTYPE; v_count NUMBER : 0; BEGIN OPEN cur_player; FETCH cur_player INTO rec; WHILE cur_player%FOUND LOOP v_count : v_count 1; FETCH cur_player INTO rec; END LOOP; CLOSE cur_player; DBMS_OUTPUT.PUT_LINE(WHILE处理行数: || v_count); END; /两次FETCH的写法容易漏写第二次导致死循环。实测中WHILE的性能通常比FETCH还差一点因为多了一次循环条件判断。3.4 BULK COLLECT FOR大批量场景的性能王者BULK COLLECT一次取一批数据到集合变量再用FOR遍历集合。关键是LIMIT子句控制每批行数避免 PGA 内存爆掉。-- 方式4BULK COLLECT FOR DECLARE CURSOR cur_player IS SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id; TYPE t_player_tab IS TABLE OF cur_player%ROWTYPE; v_tab t_player_tab; v_count NUMBER : 0; v_limit CONSTANT PLS_INTEGER : 1000; -- 每批1000行 BEGIN OPEN cur_player; LOOP FETCH cur_player BULK COLLECT INTO v_tab LIMIT v_limit; EXIT WHEN v_tab.COUNT 0; FOR i IN 1 .. v_tab.COUNT LOOP v_count : v_count 1; -- 业务逻辑v_tab(i).player_id 等 END LOOP; END LOOP; CLOSE cur_player; DBMS_OUTPUT.PUT_LINE(BULK COLLECT处理行数: || v_count); END; /LIMIT的取值很关键。太小批次多上下文切换频繁太大PGA 内存压力大。一般 500 到 5000 之间比较稳妥具体看单行数据宽度。3.5 用 TaoToken 辅助生成与校验 SQL写 PL/SQL 时语法细节和性能陷阱很多我习惯用 TaoToken 的统一 API 通道让模型帮忙检查。TaoToken 提供兼容 OpenAI 风格的接口一个 Key 就能调用多个模型省去分别配置的麻烦。先拿到 API Key然后构造请求。下面是用 curl 校验上面BULK COLLECT代码的示例curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: claude-sonnet-4-20250514, messages: [ {role: system, content: 你是 Oracle PL/SQL 专家只回答语法和性能问题。}, {role: user, content: 检查这段 BULK COLLECT 代码是否有语法错误和性能隐患\nDECLARE\n CURSOR cur_player IS SELECT player_id FROM player_info;\n TYPE t_tab IS TABLE OF cur_player%ROWTYPE;\n v_tab t_tab;\nBEGIN\n OPEN cur_player;\n LOOP\n FETCH cur_player BULK COLLECT INTO v_tab LIMIT 1000;\n EXIT WHEN v_tab.COUNT 0;\n FOR i IN 1 .. v_tab.COUNT LOOP NULL; END LOOP;\n END LOOP;\n CLOSE cur_player;\nEND;} ], temperature: 0.2 }返回结果会指出LIMIT取值建议、EXIT WHEN位置是否正确等。如果你在 IDE 里用 Cline 或 Claude Code 这类工具可以把 Base URL 配成https://taotoken.net/apiKey 填 TaoToken 的 KeyModel ID 填对应模型名三件套配齐就能在编辑器里直接问。需要说明的是模型给的是参考建议最终还得在真实库上跑一遍验证。下面一节就是实测结果。4. 实测耗时对比与验证请求结果我在 10 万行数据上跑了四种写法每种跑三次取平均关闭DBMS_OUTPUT输出只做行数累加。结果如下遍历方式10万行耗时相对倍数内存占用适用场景FOR 循环1.82s1.0x低小数据量、逻辑简单FETCH 循环1.95s1.07x低需精细控制游标WHILE 循环2.11s1.16x低同上但更易错BULK COLLECT(1000)0.31s0.17x中大批量数据处理BULK COLLECT(5000)0.28s0.15x较高大批量、内存充足可以看到BULK COLLECT比逐行FOR快了将近 6 倍。数据量越大差距越明显。如果换成 100 万行逐行方式可能要跑十几秒甚至更久而BULK COLLECT依然能控制在秒级。验证请求是否成功除了看耗时还要确认处理行数一致。四种写法我都打印了v_count结果都是 100000说明没有漏行或重复。如果你用 TaoToken 的模型对话功能做验证可以把实测耗时贴给模型让它帮你分析瓶颈在哪。比如问「10万行 FOR 循环 1.82sBULK COLLECT 0.31s这个差距合理吗」模型会结合上下文切换和 PGA 内存原理解释。再补充一个细节BULK COLLECT的LIMIT不是越大越好。我测过LIMIT 10000耗时反而回升到 0.35s因为单批内存分配开销变大。所以 1000 到 5000 是比较甜的点。5. 常见报错排查ORA-2000、401、local proxy failed 怎么解实际跑代码时报错比性能更让人头疼。这一节整理几个高频错误。ORA-2000 buffer overflow, limit of 1000 bytes这个错误通常出现在DBMS_OUTPUT.PUT_LINE输出超长字符串时。默认缓冲区只有 1000 字节输出一行 JSON 很容易超。解决办法是提前扩大缓冲-- 在 PL/SQL 块开头调用单位是字节 BEGIN DBMS_OUTPUT.ENABLE(1000000); -- 扩到约1MB END; /或者在 SQLPlus 里用SET SERVEROUTPUT ON SIZE UNLIMITED。注意ENABLE的参数上限和数据库版本有关11g 之后一般能设到 100 万字节。401 Unauthorized调用 TaoToken API 时说明 Key 没传对或已失效。检查两点请求头是不是Authorization: Bearer 你的KeyKey 有没有多余空格。用环境变量$TAOTOKEN_API_KEY时确认变量在当前 shell 已export。local proxy failed / connection refused这类错误一般是本地网络配置或代理设置问题。先确认能直接访问https://taotoken.net/api再检查 IDE 或工具的代理配置是否指向了不存在的端口。把代理关掉重试往往能解决。reading choices 字段为空调用模型接口后解析响应时如果choices数组为空通常是请求体格式不对比如messages写成了字符串而不是数组。对照官方文档的请求示例逐字段核对。OAuth / auth.json 配置问题Codex 场景如果你用 Codex 类工具认证信息一般放在~/.codex/auth.json。配置 TaoToken 时Base URL 填https://taotoken.net/apiKey 填 TaoToken KeyModel ID 填模型名三件套缺一不可。改完记得重启工具让配置生效。排查思路总结成一句先看报错码401 查 Key连接类查网络解析类查请求体ORA-2000 查输出缓冲。6. 选型建议与接入文档回到最初的问题四种写法到底怎么选数据量在几千行以内业务逻辑不复杂直接用FOR循环代码短、不易错。需要根据游标状态做特殊处理比如中途EXIT或重新OPEN用FETCH循环。WHILE循环我不太推荐两次FETCH的写法维护成本高性能也没优势。真正面对十万行以上的批量处理BULK COLLECT FOR是唯一合理的选择。配合LIMIT分批既快又不会撑爆内存。如果还涉及批量UPDATE或INSERT可以进一步用FORALL语句性能还能再上一个台阶。想快速验证自己的 SQL 写法可以用 TaoToken 的模型对话功能把代码贴进去让模型挑毛病。需要长期在编辑器里做 PL/SQL 开发可以了解下 Coding Plan把 Base URL 配成https://taotoken.net/apiKey 和 Model ID 填好就能在 Cline、Claude Code 这类工具里直接调用。接入细节和参数说明在接入文档里有完整示例API Key 在控制台的 API Keys 页面生成。最后留一个实用技巧压测游标性能时把DBMS_OUTPUT全部注释掉用一张结果表记录耗时避免输出成为瓶颈。这个坑我踩过输出一开BULK COLLECT的优势直接被抹平。 Oracle 遍历游标的四种方式：for/fetch/while/BULK COLLECT 性能对比与 TaoToken 调试实践
1. 从一次批量更新卡死说起Oracle 游标遍历到底该选哪种写法如果你写过 PL/SQL 存储过程大概率遇到过这种场景一张几十万行的表需要逐行做业务判断再更新用FOR循环跑起来看着挺顺结果上线后跑了几十分钟还没结束甚至把 UNDO 表空间撑爆。问题往往不在 SQL 本身而在游标遍历方式选错了。Oracle 里遍历游标至少有四种常见写法FOR循环、FETCH循环、WHILE循环、BULK COLLECT FOR。它们语法上都能跑通但在批量数据处理场景下性能差距可能是几倍到几十倍。这篇文章不空谈理论我会给出可复制的建表脚本、四种写法的完整代码、实测耗时对比以及用 TaoToken 统一 API 通道辅助生成和校验 SQL 的具体操作帮你快速定位适合自己业务的方案。先说结论方向小数据量、逻辑简单FOR循环最省心需要精细控制游标状态用FETCH或WHILE真正面对大批量数据BULK COLLECT配合LIMIT才是正解。下面一步步拆开讲。2. 测试环境与建表脚本先有一张能跑的数据表在对比之前得先有一张结构清晰、数据量可控的表。我用的是一张玩家信息表player_info字段简单方便你把注意力放在游标写法上而不是被业务逻辑干扰。-- 建表玩家信息表 CREATE TABLE player_info ( player_id NUMBER(10) NOT NULL, player_name VARCHAR2(64) NOT NULL, level_no NUMBER(3) DEFAULT 1, create_time DATE DEFAULT SYSDATE, CONSTRAINT pk_player_info PRIMARY KEY (player_id) ); -- 插入测试数据这里用 connect by 快速造 10 万行 INSERT INTO player_info (player_id, player_name, level_no) SELECT LEVEL, player_ || LEVEL, MOD(LEVEL, 100) 1 FROM dual CONNECT BY LEVEL 100000; COMMIT; -- 收集统计信息让优化器有准确判断 BEGIN DBMS_STATS.GATHER_TABLE_STATS(USER, PLAYER_INFO); END; /数据量我特意设成 10 万行因为 1355 行这种小表四种写法耗时都在毫秒级根本看不出差异。只有数据量上去BULK COLLECT的优势才会暴露出来。另外提醒一点测试时把DBMS_OUTPUT输出关掉或重定向否则输出本身会成为瓶颈掩盖真实的游标遍历性能。下面代码里我会用累加变量代替PUT_LINE只统计处理行数。-- 开启输出缓冲仅调试用压测时建议注释掉 PUT_LINE SET SERVEROUTPUT ON SIZE UNLIMITED;环境准备好后我们进入正题。四种写法我会给出完整可执行代码每段都能直接贴进 SQL Developer 或 SQLPlus 跑。3. 四种游标遍历写法完整代码与 TaoToken 辅助校验这一节是核心。我会先给出四种写法的完整代码然后演示如何用 TaoToken 的 API 通道让模型帮忙检查 SQL 语法和潜在性能问题。3.1 FOR 循环最简洁隐式游标自动管理FOR循环分显式和隐式两种。显式游标需要DECLARE声明隐式游标直接把查询写在FOR里。-- 方式1-A显式游标 FOR 循环 DECLARE CURSOR cur_player IS SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id; v_count NUMBER : 0; BEGIN FOR rec IN cur_player LOOP v_count : v_count 1; -- 实际业务逻辑写这里比如条件更新 END LOOP; DBMS_OUTPUT.PUT_LINE(FOR显式处理行数: || v_count); END; / -- 方式1-B隐式游标 FOR 循环 BEGIN FOR rec IN (SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id) LOOP NULL; -- 业务逻辑 END LOOP; END; /FOR循环的好处是游标的OPEN、FETCH、CLOSE全由 Oracle 自动管理你不用操心%NOTFOUND判断也不会忘记关游标。缺点是每次只取一行行与行之间有一次上下文切换数据量大时开销明显。3.2 FETCH 循环手动控制灵活但易错FETCH循环需要显式OPEN、FETCH、CLOSE退出条件靠%NOTFOUND。-- 方式2FETCH 循环 DECLARE CURSOR cur_player IS SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id; rec cur_player%ROWTYPE; v_count NUMBER : 0; BEGIN OPEN cur_player; LOOP FETCH cur_player INTO rec; EXIT WHEN cur_player%NOTFOUND; v_count : v_count 1; END LOOP; CLOSE cur_player; DBMS_OUTPUT.PUT_LINE(FETCH处理行数: || v_count); END; /注意EXIT WHEN必须紧跟在FETCH之后否则会多处理一行或漏处理。这是新手最容易踩的坑。3.3 WHILE 循环FETCH 要写两次WHILE循环的写法比较别扭因为要在进入循环前先FETCH一次循环体末尾再FETCH一次。-- 方式3WHILE 循环 DECLARE CURSOR cur_player IS SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id; rec cur_player%ROWTYPE; v_count NUMBER : 0; BEGIN OPEN cur_player; FETCH cur_player INTO rec; WHILE cur_player%FOUND LOOP v_count : v_count 1; FETCH cur_player INTO rec; END LOOP; CLOSE cur_player; DBMS_OUTPUT.PUT_LINE(WHILE处理行数: || v_count); END; /两次FETCH的写法容易漏写第二次导致死循环。实测中WHILE的性能通常比FETCH还差一点因为多了一次循环条件判断。3.4 BULK COLLECT FOR大批量场景的性能王者BULK COLLECT一次取一批数据到集合变量再用FOR遍历集合。关键是LIMIT子句控制每批行数避免 PGA 内存爆掉。-- 方式4BULK COLLECT FOR DECLARE CURSOR cur_player IS SELECT player_id, player_name, level_no FROM player_info ORDER BY player_id; TYPE t_player_tab IS TABLE OF cur_player%ROWTYPE; v_tab t_player_tab; v_count NUMBER : 0; v_limit CONSTANT PLS_INTEGER : 1000; -- 每批1000行 BEGIN OPEN cur_player; LOOP FETCH cur_player BULK COLLECT INTO v_tab LIMIT v_limit; EXIT WHEN v_tab.COUNT 0; FOR i IN 1 .. v_tab.COUNT LOOP v_count : v_count 1; -- 业务逻辑v_tab(i).player_id 等 END LOOP; END LOOP; CLOSE cur_player; DBMS_OUTPUT.PUT_LINE(BULK COLLECT处理行数: || v_count); END; /LIMIT的取值很关键。太小批次多上下文切换频繁太大PGA 内存压力大。一般 500 到 5000 之间比较稳妥具体看单行数据宽度。3.5 用 TaoToken 辅助生成与校验 SQL写 PL/SQL 时语法细节和性能陷阱很多我习惯用 TaoToken 的统一 API 通道让模型帮忙检查。TaoToken 提供兼容 OpenAI 风格的接口一个 Key 就能调用多个模型省去分别配置的麻烦。先拿到 API Key然后构造请求。下面是用 curl 校验上面BULK COLLECT代码的示例curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: claude-sonnet-4-20250514, messages: [ {role: system, content: 你是 Oracle PL/SQL 专家只回答语法和性能问题。}, {role: user, content: 检查这段 BULK COLLECT 代码是否有语法错误和性能隐患\nDECLARE\n CURSOR cur_player IS SELECT player_id FROM player_info;\n TYPE t_tab IS TABLE OF cur_player%ROWTYPE;\n v_tab t_tab;\nBEGIN\n OPEN cur_player;\n LOOP\n FETCH cur_player BULK COLLECT INTO v_tab LIMIT 1000;\n EXIT WHEN v_tab.COUNT 0;\n FOR i IN 1 .. v_tab.COUNT LOOP NULL; END LOOP;\n END LOOP;\n CLOSE cur_player;\nEND;} ], temperature: 0.2 }返回结果会指出LIMIT取值建议、EXIT WHEN位置是否正确等。如果你在 IDE 里用 Cline 或 Claude Code 这类工具可以把 Base URL 配成https://taotoken.net/apiKey 填 TaoToken 的 KeyModel ID 填对应模型名三件套配齐就能在编辑器里直接问。需要说明的是模型给的是参考建议最终还得在真实库上跑一遍验证。下面一节就是实测结果。4. 实测耗时对比与验证请求结果我在 10 万行数据上跑了四种写法每种跑三次取平均关闭DBMS_OUTPUT输出只做行数累加。结果如下遍历方式10万行耗时相对倍数内存占用适用场景FOR 循环1.82s1.0x低小数据量、逻辑简单FETCH 循环1.95s1.07x低需精细控制游标WHILE 循环2.11s1.16x低同上但更易错BULK COLLECT(1000)0.31s0.17x中大批量数据处理BULK COLLECT(5000)0.28s0.15x较高大批量、内存充足可以看到BULK COLLECT比逐行FOR快了将近 6 倍。数据量越大差距越明显。如果换成 100 万行逐行方式可能要跑十几秒甚至更久而BULK COLLECT依然能控制在秒级。验证请求是否成功除了看耗时还要确认处理行数一致。四种写法我都打印了v_count结果都是 100000说明没有漏行或重复。如果你用 TaoToken 的模型对话功能做验证可以把实测耗时贴给模型让它帮你分析瓶颈在哪。比如问「10万行 FOR 循环 1.82sBULK COLLECT 0.31s这个差距合理吗」模型会结合上下文切换和 PGA 内存原理解释。再补充一个细节BULK COLLECT的LIMIT不是越大越好。我测过LIMIT 10000耗时反而回升到 0.35s因为单批内存分配开销变大。所以 1000 到 5000 是比较甜的点。5. 常见报错排查ORA-2000、401、local proxy failed 怎么解实际跑代码时报错比性能更让人头疼。这一节整理几个高频错误。ORA-2000 buffer overflow, limit of 1000 bytes这个错误通常出现在DBMS_OUTPUT.PUT_LINE输出超长字符串时。默认缓冲区只有 1000 字节输出一行 JSON 很容易超。解决办法是提前扩大缓冲-- 在 PL/SQL 块开头调用单位是字节 BEGIN DBMS_OUTPUT.ENABLE(1000000); -- 扩到约1MB END; /或者在 SQLPlus 里用SET SERVEROUTPUT ON SIZE UNLIMITED。注意ENABLE的参数上限和数据库版本有关11g 之后一般能设到 100 万字节。401 Unauthorized调用 TaoToken API 时说明 Key 没传对或已失效。检查两点请求头是不是Authorization: Bearer 你的KeyKey 有没有多余空格。用环境变量$TAOTOKEN_API_KEY时确认变量在当前 shell 已export。local proxy failed / connection refused这类错误一般是本地网络配置或代理设置问题。先确认能直接访问https://taotoken.net/api再检查 IDE 或工具的代理配置是否指向了不存在的端口。把代理关掉重试往往能解决。reading choices 字段为空调用模型接口后解析响应时如果choices数组为空通常是请求体格式不对比如messages写成了字符串而不是数组。对照官方文档的请求示例逐字段核对。OAuth / auth.json 配置问题Codex 场景如果你用 Codex 类工具认证信息一般放在~/.codex/auth.json。配置 TaoToken 时Base URL 填https://taotoken.net/apiKey 填 TaoToken KeyModel ID 填模型名三件套缺一不可。改完记得重启工具让配置生效。排查思路总结成一句先看报错码401 查 Key连接类查网络解析类查请求体ORA-2000 查输出缓冲。6. 选型建议与接入文档回到最初的问题四种写法到底怎么选数据量在几千行以内业务逻辑不复杂直接用FOR循环代码短、不易错。需要根据游标状态做特殊处理比如中途EXIT或重新OPEN用FETCH循环。WHILE循环我不太推荐两次FETCH的写法维护成本高性能也没优势。真正面对十万行以上的批量处理BULK COLLECT FOR是唯一合理的选择。配合LIMIT分批既快又不会撑爆内存。如果还涉及批量UPDATE或INSERT可以进一步用FORALL语句性能还能再上一个台阶。想快速验证自己的 SQL 写法可以用 TaoToken 的模型对话功能把代码贴进去让模型挑毛病。需要长期在编辑器里做 PL/SQL 开发可以了解下 Coding Plan把 Base URL 配成https://taotoken.net/apiKey 和 Model ID 填好就能在 Cline、Claude Code 这类工具里直接调用。接入细节和参数说明在接入文档里有完整示例API Key 在控制台的 API Keys 页面生成。最后留一个实用技巧压测游标性能时把DBMS_OUTPUT全部注释掉用一张结果表记录耗时避免输出成为瓶颈。这个坑我踩过输出一开BULK COLLECT的优势直接被抹平。