显式游标须严格遵循声明→打开→取数→关闭流程，跳过任一环节将报ORA-01001；其SELECT在声明时解析、OPEN时执行，WHERE中变量取值以OPEN时刻为准；推荐命名加_cursor后缀、用%rowtype定义记录变量；FETCH后必须立即检查%notfound以防重复处理；FOR循环隐式游标简洁但缺乏控制力，复杂逻辑需回归显式游标+LOOP+FETCH；嵌套游标须确保配对开关并优化索引与执行计划。
显式游标必须先声明再打开，不能直接FETCH
常见错误是写成 fetch my_cursor into v_rec 却没执行 open my_cursor，Oracle 会报 ORA-01001: invalid cursor。显式游标生命周期严格：声明 → 打开 → 取数 → 关闭，跳过任一环节都可能出错。
使用场景包括需要逐行控制逻辑（如分摊、校验、条件插入）或结果集结构不固定时。注意游标声明中的 SELECT 语句在定义时就解析，但实际执行延迟到 open 时刻，所以 WHERE 条件里可用 PL/SQL 变量，且变量值以 open 时为准。
- 声明游标时推荐加
_cursor后缀，例如cur_orderdt，避免和变量名混淆 - 若游标需返回特定列结构，优先用
%rowtype（如v_rec cur_orderdt%rowtype），比手动列对齐更安全 - 不要在循环外提前
close，否则后续fetch会失败；也不要在异常未处理时遗漏close，建议用begin...exception...finally块包裹（PL/SQL 21c+ 支持finally）
用 FOR 循环隐式遍历最简，但无法中途退出或动态控制
FOR rec IN (SELECT ...) 是最简洁的遍历方式，Oracle 自动完成声明、打开、取数、关闭全过程。但它本质是隐式游标，%notfound 和 %rowcount 不可用，也无法在满足某个条件时 exit 或跳过当前迭代。
适合场景：纯读取+简单处理（如日志输出、批量插入固定模板数据）。一旦涉及“分摊到够为止”“遇到空值跳过”“累计超限中断”，就必须退回显式游标 + loop + fetch 模式。
-
FOR rec IN cur_name LOOP中的cur_name必须是已声明的显式游标，不能是带参数的调用形式（如cur_name(123)），否则报PLS-00382: expression is of wrong type - 若需传参，得用游标变量（
SYS_REFCURSOR）或重构为带参数的游标（CURSOR cur_name(p_id NUMBER) IS SELECT ... WHERE id = p_id） -
FOR循环内修改rec字段不会影响源表，它只是只读副本
FETCH 后必须立刻检查 %notfound，否则会多处理一次无效数据
典型翻车现场：fetch cur into v_rec; if cur%notfound then exit; end if; 写反成 if not cur%notfound then ...，或者漏掉判断直接处理 v_rec——此时最后一次 fetch 已无数据，v_rec 仍保留上一轮值，导致重复插入或逻辑错乱。
根本原因是 %notfound 在 fetch 尝试取下一条失败后才置为 TRUE，而该次 fetch 并未改变 v_rec 的内容。所以检查必须紧跟在 fetch 后、任何业务逻辑前。
- 标准模式就是：
loop fetch ...; exit when cur%notfound; -- 处理 v_rec end loop; - 不要用
while cur%found loop fetch ...，因为首次进入循环时%found还未被触发，值为NULL，条件不成立直接跳过 -
%rowcount返回的是已成功fetch的次数，不是当前游标剩余行数，别拿它做循环计数依据
嵌套游标要防资源泄漏和性能陷阱
像批号分摊这类场景，外层游标查订单，内层游标查库存位，容易写出双重循环。问题在于：内层游标若每次都在外层循环体内 open，却没确保每次 close，会导致游标句柄堆积，最终触发 ORA-01000: maximum open cursors exceeded。
更隐蔽的是性能问题：内层游标若带 ORDER BY 且数据量大，每次打开都触发全排序；若 WHERE 条件依赖外层变量，又没建合适索引，IO 会爆炸。
- 内层游标务必配对
open/close，推荐在内层begin...end块中完成，或用for循环自动管理 - 把内层查询逻辑尽量前置——比如先用
SELECT ... BULK COLLECT INTO拿到内存数组，再用FOR i IN 1..arr.count LOOP遍历，减少上下文切换 - 检查执行计划，确认内层游标的
WHERE字段有索引，尤其是关联外层变量的字段（如goodsid = ccrec.goodsid）
游标不是语法糖，它是 Oracle 执行模型的具象化。每打开一个显式游标，就占用一个服务器进程的私有内存和游标句柄；FETCH 不是“读数据”，而是从已缓存的结果集里搬一行到客户端变量。真正容易被忽略的，是游标打开时机与变量快照的关系——你以为用的是最新值，其实用的是 OPEN 那一刻的值。
