1. 从一次存储过程卡顿说起：Oracle 游标 fetch 与 for 循环到底怎么选

先说结论：Oracle PL/SQL 里的显式游标，FETCH逐行提取和FOR循环游标不是「谁替代谁」的关系，而是「谁更适合当前这段逻辑」的关系。FOR循环游标本质上是编译器帮你把OPEN、FETCH、EXIT WHEN、CLOSE四件事打包好了，写起来短、不容易漏CLOSE；而手写FETCH的价值在于你能在循环中间做更细的控制，比如批量BULK COLLECT、中途COMMIT、动态改WHERE条件、或者把游标变量当参数传来传去。

我见过太多存储过程，一个FOR循环里套了另一层FOR循环，每层都去查同一张配置表，跑几万行数据时慢得让人怀疑人生。问题往往不在游标本身，而在于没搞清楚「逐行处理」和「集合处理」的边界。这篇就围绕oracle 游标 fetch 和 for 循环游标这个高频检索点，把声明、写法、执行差异、常见报错和 AI 辅助校验一次讲透，面向的是每天写存储过程的开发同学。

适合谁看：写过CURSOR ... IS SELECT但说不清%ROWTYPE、%NOTFOUND、%ROWCOUNT区别的人；被ORA-01000: maximum open cursors exceeded坑过的人；想用统一 Key 调 AI 帮忙生成和检查游标代码的人。下面所有示例都可以直接复制到 SQL*Plus、SQL Developer 或 PL/SQL Developer 里跑。

先明确一个概念：游标是 Oracle 在内存里为一条 SQL 结果集维护的指针。你SELECT出来的行不会一次性全塞进变量，而是通过游标一行一行（或一批一批）取。FETCH就是「取下一行」这个动作，FOR循环则是把这个动作自动化。理解这一点，后面的性能取舍就顺了。

2. TaoToken 统一 Key 前置：让 AI 帮你写游标前先备好通道

写游标代码时，我经常需要 AI 帮忙做三件事：把一段FETCH循环改写成FOR循环、检查%NOTFOUND位置对不对、根据表结构生成带BULK COLLECT的版本。这些都需要一个稳定的模型调用通道。TaoToken 在这里的作用是提供一个统一的 API 入口和一把 Key，你不用为不同模型分别维护账号和密钥，调用方式保持一致。

它的官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数，直接用它拼/v1/chat/completions这类路径即可。对写 PL/SQL 的人来说，你不需要理解底层怎么转发，只要知道：拿到 Key、填对 Base URL、选一个模型 ID，就能在脚本或工具里发请求。

为什么写游标也要接 AI？因为游标代码的坑很隐蔽。比如EXIT WHEN cur%NOTFOUND写在FETCH之前还是之后，结果完全不同；FOR循环里隐式游标的%ROWCOUNT在循环结束后才准确。这些细节让 AI 帮你对照检查，比翻文档快。下面先给一个最小可用的调用配置，再进入游标正题。

你需要准备三样东西：Base URL、API Key、Model ID。Base URL 用https://taotoken.net/api，Key 在控制台创建，Model ID 按你选的模型填。这三件套在后面的 Cline、Codex、Claude Code 类工具里都是同一套逻辑。如果你只是想在网页里对话验证游标写法，可以直接用模型对话入口；如果要长期在编辑器里让 AI 补全游标代码，走 Coding Plan 更合适。

这里给一个用 curl 验证通道是否通的最简请求，把$TAOTOKEN_KEY换成你自己的 Key：

curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $TAOTOKEN_KEY" \ -d '{ "model": "你的模型ID", "messages": [ {"role": "user", "content": "把这段 Oracle FETCH 循环改写成 FOR 循环游标，并说明 %NOTFOUND 的位置差异"} ] }'

返回里能看到choices[0].message.content就说明通道正常。这一步不做，后面 AI 校验游标代码就无从谈起。Key 的创建在控制台的 API Keys 页面，接入细节看文档页，两个入口后面 CTA 会给。

3. 可复制配置：FETCH 循环与 FOR 循环游标完整写法对照

这一节是全文的核心，直接给可复制的代码。先建一张测试表，模拟xtm14这种业务表：

CREATE TABLE xtm14 ( xtwldm VARCHAR2(20), xtmc VARCHAR2(100), amount NUMBER ); INSERT INTO xtm14 VALUES ('A001', '物料一', 100); INSERT INTO xtm14 VALUES ('A002', '物料二', 200); INSERT INTO xtm14 VALUES ('A003', '物料三', 300); COMMIT;

3.1 显式游标 + FETCH 逐行提取

这是最「原始」的写法，OPEN、FETCH、EXIT WHEN、CLOSE四步齐全：

DECLARE CURSOR cur IS SELECT xtwldm, xtmc, amount FROM xtm14 WHERE amount > 0; curRow cur%ROWTYPE; BEGIN OPEN cur; LOOP FETCH cur INTO curRow; EXIT WHEN cur%NOTFOUND; DBMS_OUTPUT.PUT_LINE(curRow.xtwldm || ' - ' || curRow.xtmc); END LOOP; CLOSE cur; END; /

关键点：EXIT WHEN cur%NOTFOUND必须写在FETCH之后。因为%NOTFOUND反映的是「上一次 FETCH 有没有取到行」。如果你写在FETCH之前，第一次判断时还没取过数据，行为不可靠。cur%ROWTYPE让curRow自动拥有游标查询列的结构，不用手写变量类型。

3.2 FOR 循环游标：编译器帮你收尾

同样的逻辑，FOR循环版本短很多：

BEGIN FOR curRow IN (SELECT xtwldm, xtmc, amount FROM xtm14 WHERE amount > 0) LOOP DBMS_OUTPUT.PUT_LINE(curRow.xtwldm || ' - ' || curRow.xtmc); END LOOP; END; /

也可以先声明游标再FOR：

DECLARE CURSOR cur IS SELECT xtwldm, xtmc, amount FROM xtm14 WHERE amount > 0; BEGIN FOR curRow IN cur LOOP DBMS_OUTPUT.PUT_LINE(curRow.xtwldm || ' - ' || curRow.xtmc); END LOOP; END; /

FOR循环游标的特点：隐式OPEN、隐式FETCH、隐式CLOSE，循环变量curRow自动声明，不用你写%ROWTYPE。循环正常结束或中途EXIT，游标都会自动关闭。这就是它不容易出ORA-01000的原因。

3.3 参数化游标与动态 SQL 的配置片段

实际业务里游标常带参数。FETCH版和FOR版都支持：

DECLARE CURSOR cur(p_min NUMBER) IS SELECT xtwldm, amount FROM xtm14 WHERE amount >= p_min; curRow cur%ROWTYPE; BEGIN OPEN cur(150); LOOP FETCH cur INTO curRow; EXIT WHEN cur%NOTFOUND; DBMS_OUTPUT.PUT_LINE(curRow.xtwldm || ':' || curRow.amount); END LOOP; CLOSE cur; END; /

FOR版带参数：

DECLARE CURSOR cur(p_min NUMBER) IS SELECT xtwldm, amount FROM xtm14 WHERE amount >= p_min; BEGIN FOR curRow IN cur(150) LOOP DBMS_OUTPUT.PUT_LINE(curRow.xtwldm || ':' || curRow.amount); END LOOP; END; /

如果你在 Cline 或类似编辑器插件里让 AI 生成游标代码，配置通常是一个 JSON 文件，三件套要写全：

{ "baseUrl": "https://taotoken.net/api", "apiKey": "你的TaoTokenKey", "model": "你的模型ID" }

注意baseUrl不要带 UTM，apiKey从控制台复制，model填你实际选的 ID。这三项缺一个，AI 补全游标代码时就会报鉴权或模型不存在。Codex 的auth.json也是同样三件套，字段名可能不同，但 Base URL、Key、Model ID 一个都不能少。

3.4 执行计划对比：为什么 FOR 循环不一定慢

很多人以为FOR循环「封装太多所以慢」，其实两者在 SQL 执行层面用的是同一套游标机制。真正的性能差异来自你怎么用：

关键结论：如果只是逐行DBMS_OUTPUT或逐行UPDATE，两者性能几乎一样，瓶颈在「逐行」这个模式本身，不在FETCH还是FOR。要提速，方向是BULK COLLECT+FORALL，而不是纠结循环写法。下面给一个批量版本：

DECLARE CURSOR cur IS SELECT xtwldm, amount FROM xtm14 WHERE amount > 0; TYPE t_tab IS TABLE OF cur%ROWTYPE; l_tab t_tab; BEGIN OPEN cur; LOOP FETCH cur BULK COLLECT INTO l_tab LIMIT 100; EXIT WHEN l_tab.COUNT = 0; FOR i IN 1 .. l_tab.COUNT LOOP DBMS_OUTPUT.PUT_LINE(l_tab(i).xtwldm); END LOOP; END LOOP; CLOSE cur; END; /

LIMIT 100控制每批取多少行，避免一次性把大结果集拉进 PGA。这个写法FOR循环游标做不了，必须手写FETCH，这就是显式游标不可替代的场景。

4. 验证请求与成功结果：用 AI 校验游标代码是否写对

代码写完，怎么确认%NOTFOUND位置、CLOSE是否遗漏、FOR循环变量作用域有没有问题？我一般把代码贴给 AI 做一次静态检查。下面是一个完整的验证请求，走 TaoToken 的 API 通道：

curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $TAOTOKEN_KEY" \ -d '{ "model": "你的模型ID", "messages": [ { "role": "system", "content": "你是 Oracle PL/SQL 专家，只回答游标相关问题，指出错误并给修正代码。" }, { "role": "user", "content": "检查这段代码：DECLARE CURSOR cur IS SELECT xtwldm FROM xtm14; curRow cur%ROWTYPE; BEGIN OPEN cur; LOOP EXIT WHEN cur%NOTFOUND; FETCH cur INTO curRow; DBMS_OUTPUT.PUT_LINE(curRow.xtwldm); END LOOP; CLOSE cur; END;" } ] }'

期望返回里应该指出：EXIT WHEN cur%NOTFOUND写在了FETCH之前，这是错的，第一次循环时%NOTFOUND还是初始值，可能导致多输出一行或行为异常。正确顺序是先FETCH再EXIT WHEN。如果 AI 返回了这个判断，说明通道和模型都工作正常。

成功结果的判断标准有三个：HTTP 状态 200；返回 JSON 里有choices数组；choices[0].message.content包含对%NOTFOUND位置的纠正。如果返回 401，说明 Key 不对或没带Authorization头；如果返回model not found，说明 Model ID 填错。

你也可以用模型对话入口直接在网页里做同样的验证，把游标代码贴进去问「这段 FETCH 循环有没有问题」。对于长期写存储过程的人，把这类校验接进编辑器更省事：Cline 里配好三件套后，选中游标代码让它 review；Claude Code 类工具则可以在终端里对.sql文件做批量检查。这些都属于 Coding Plan 覆盖的场景。

验证通过后，建议把 AI 给出的修正版再跑一遍，确认输出行数和预期一致。比如xtm14里 3 行数据，DBMS_OUTPUT应该正好输出 3 行，不多不少。这一步能抓出%NOTFOUND位置错误导致的「多一行」问题。

5. 本篇常见错排查：401、ORA-01000 与 %NOTFOUND 陷阱

写游标和调 AI 通道时，下面这些报错出现频率最高，逐个对照。

401 Unauthorized / invalid api key：调用 TaoToken API 时最常见。原因通常是 Key 没填、Key 前后有空格、或者请求头写成了Authorization: 你的Key而漏了Bearer。检查-H "Authorization: Bearer $TAOTOKEN_KEY"这一行，Bearer和 Key 之间有一个空格。另外确认 Base URL 是https://taotoken.net/api，不要多加/v1之外的路径。

local proxy failed / connection refused：这类报错一般出现在编辑器插件里，说明插件配置的 Base URL 写错了，或者本机网络到不了该地址。先确认baseUrl字段值是https://taotoken.net/api，再确认没有多余的斜杠或空格。如果插件要求填完整路径，就填https://taotoken.net/api/v1。

reading choices: unexpected end of JSON input：返回体不是合法 JSON，通常是请求被中途截断或模型返回了非 JSON 内容。检查Content-Type: application/json是否带上，-d里的 JSON 是否被 shell 转义破坏。把请求体存成文件用-d @body.json更稳。

ORA-01000: maximum open cursors exceeded：这是 Oracle 侧的经典错误，和 AI 无关。原因是显式游标OPEN了没CLOSE，尤其在异常分支里。FOR循环游标基本不会触发，因为它自动关闭。如果你必须用FETCH，把CLOSE放进异常处理：

BEGIN OPEN cur; LOOP FETCH cur INTO curRow; EXIT WHEN cur%NOTFOUND; -- 处理逻辑 END LOOP; CLOSE cur; EXCEPTION WHEN OTHERS THEN IF cur%ISOPEN THEN CLOSE cur; END IF; RAISE; END; /

%NOTFOUND 判断位置错误：前面反复强调，EXIT WHEN cur%NOTFOUND必须在FETCH之后。FOR循环游标没有这个问题，因为编译器帮你处理了。如果你从FETCH改写成FOR，记得把EXIT WHEN整行删掉。

OAuth / token expired：部分工具用 OAuth 方式鉴权，token 过期后会报这个。重新在控制台生成 Key 或刷新 token 即可。Codex 的auth.json里如果存的是过期凭证，也会出现类似报错，替换成新的 Key 就行。

FOR 循环里改游标查询的表：FOR循环游标在打开时会确定结果集，循环中如果对同一张表做UPDATE并COMMIT，可能触发ORA-01555 snapshot too old。这种场景要么改成FETCH+BULK COLLECT，要么把COMMIT移出循环。

排查顺序建议：先看 Oracle 报错号，再看 AI 通道的 HTTP 状态码，两者分开定位。ORA 错误去查游标生命周期，401/JSON 错误去查三件套配置。

6. 选型建议与统一 Key 下的落地路径

回到最初的问题：FETCH和FOR循环游标怎么选。我的实际经验是，默认用FOR循环游标，除非你明确需要下面任意一项：批量BULK COLLECT、循环中动态改变查询条件、把游标作为参数传递、或者需要在循环中途精细控制COMMIT频率。这四种情况用显式FETCH，其余一律FOR，代码短、漏CLOSE风险低。

性能上不要被「FOR 循环封装多所以慢」误导。逐行处理的瓶颈在逐行本身，不在循环语法。数据量上万行时，优先考虑BULK COLLECT+FORALL，把逐行UPDATE改成批量，提速往往是一个数量级。这个改写可以让 AI 帮你做：把原FOR循环贴进去，要求输出BULK COLLECT LIMIT版本，再人工核对LIMIT大小和异常处理。

统一 Key 的价值在于，你写游标、改游标、查报错，用的是同一套 Base URL 和 Key，不用在多个工具间切换凭证。需要创建 Key 或看接入细节，走 API Keys 和接入文档；想先在网页里验证一段游标代码，用模型对话；要把 AI 校验长期接进存储过程开发流程，走 Coding Plan。三件套 Base URL、Key、Model ID 在哪个工具里都是这三样，配一次就能复用。

最后留一个我常用的自检清单，写完游标代码后逐条过：FETCH后是否紧跟EXIT WHEN；CLOSE是否在正常路径和异常路径都有；FOR循环变量是否在循环外被引用（会报错）；BULK COLLECT是否设了LIMIT；循环内COMMIT是否会影响游标一致性。这五条过完，游标代码基本不会出大问题。