1. 为什么批量逐行加工绕不开 DECLARE 游标在 GBase 8s V8.8 里做批量数据加工很多人第一反应是写一条UPDATE ... WHERE或者INSERT ... SELECT一把梭。集合操作确实快但一旦遇到「每一行都要根据上一行的结果决定下一行怎么处理」「每行要调用一次外部逻辑」「要按顺序给某张表打流水号」这类需求纯集合 SQL 就会卡住。这时候 DECLARE 游标就是那把顺手的螺丝刀它把结果集拆成一行一行让你在循环里对每一行做判断、计算、写回。游标在 GBase 8s 里的完整生命周期是四步DECLARE 声明、OPEN 打开、FETCH 取值、CLOSE 关闭。声明阶段只是给游标起个名字、绑定一条 SELECT、告诉数据库它是只读还是可更新此时并不执行查询OPEN 才真正把结果集准备好FETCH 每次拿一行CLOSE 释放资源。理解这个「声明不等于执行」的点很关键很多新手以为 DECLARE 完数据就到手了结果 FETCH 报错。这篇面向的是批量逐行加工场景比如订单表里逐条重算金额、日志表逐行清洗后写入汇总表、维表逐行补全编码。我会给出可直接复制的 SQL 骨架包括存储过程里的游标循环、异常处理、以及只读与可更新两种声明方式最后给出验证步骤和常见报错排查。适合已经会写基础 SQL、需要在 GBase 8s 里落地逐行逻辑的开发和运维同学。2. 前置准备连接环境与 TaoToken 接入在动手写游标之前先把执行环境理顺。GBase 8s V8.8 的游标主要用在两类地方一是 ESQL/C 这类嵌入式宿主程序二是存储过程SPL。日常做数据加工我更推荐先在存储过程里把逻辑跑通因为调试成本低、可复制性强确认没问题再考虑嵌到应用里。如果你是通过 API 方式调用模型来辅助生成或审查这些 SQL可以先把访问凭证配好。TaoToken 的 API 地址是 https://taotoken.net/api 密钥在控制台的 API Keys 页面创建接入文档里有各语言的调用示例。我一般会把 base_url 和 key 放在环境变量里避免硬编码进脚本export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_API_KEYsk-你的密钥需要说明的是TaoToken 在这里扮演的是模型调用入口帮你生成、解释、排查 SQL 逻辑它不替代 GBase 8s 本身也不替代你的数据库客户端。真正的游标执行还是在 GBase 8s 服务端完成。控制台入口在 https://taotoken.net/console 创建完 key 后建议先做一次最小连通性验证确认网络和鉴权都正常再去写复杂的游标逻辑免得把环境问题和 SQL 问题混在一起排查。3. 可复制的游标配置骨架下面这套骨架覆盖了声明、打开、取值、关闭四个阶段并且带异常处理和循环退出条件。你可以直接改表名和字段名套用。3.1 只读游标逐行读取并加工只读游标适合「读源表、算结果、写目标表」的场景。声明时加FOR READ ONLY数据库知道不会回写执行计划更省资源。CREATE PROCEDURE sp_process_orders() DEFINE v_order_num INTEGER; DEFINE v_item_num INTEGER; DEFINE v_amount DECIMAL(12,2); DEFINE v_new_amount DECIMAL(12,2); -- 1. 声明游标绑定 SELECT此时不执行 DECLARE cur_order CURSOR FOR SELECT order_num, item_num, amount FROM orders WHERE status PENDING FOR READ ONLY; -- 2. 打开游标结果集就绪 OPEN cur_order; -- 3. 循环取值 WHILE TRUE FETCH cur_order INTO v_order_num, v_item_num, v_amount; IF SQLCODE ! 0 THEN EXIT; END IF; -- 逐行加工逻辑 LET v_new_amount v_amount * 1.13; INSERT INTO orders_processed(order_num, item_num, amount) VALUES (v_order_num, v_item_num, v_new_amount); END WHILE; -- 4. 关闭游标释放资源 CLOSE cur_order; END PROCEDURE;几个要点FETCH ... INTO的变量顺序必须和 SELECT 列顺序严格一致类型也要能对上否则会报类型不匹配。循环退出靠SQLCODE取不到数据时它返回非 0通常是 100表示 NOT FOUND这时候EXIT跳出。WHILE TRUE配合EXIT是 SPL 里最常见的写法。3.2 可更新游标边读边改如果加工结果要直接写回源表同一行声明时用FOR UPDATEFETCH 之后用WHERE CURRENT OF定位当前行更新。CREATE PROCEDURE sp_fix_stock() DEFINE v_stock_num INTEGER; DEFINE v_qty INTEGER; DECLARE cur_stock CURSOR FOR SELECT stock_num, quantity FROM stock WHERE quantity 0 FOR UPDATE; OPEN cur_stock; WHILE TRUE FETCH cur_stock INTO v_stock_num, v_qty; IF SQLCODE ! 0 THEN EXIT; END IF; UPDATE stock SET quantity 0 WHERE CURRENT OF cur_stock; END WHILE; CLOSE cur_stock; END PROCEDURE;WHERE CURRENT OF 游标名是定位更新的关键它锁定的是 FETCH 刚取到的那一行比再用主键去匹配更稳也避免并发下改错行。注意可更新游标的 SELECT 里不要用聚合、GROUP BY、DISTINCT 这些否则数据库无法定位到具体行声明就会失败。3.3 带参数的游标加工范围经常是动态的比如只处理某个时间段的数据。游标声明时可以带参数OPEN 时传值。DECLARE cur_by_date CURSOR (p_start DATE, p_end DATE) FOR SELECT order_num, amount FROM orders WHERE order_date BETWEEN p_start AND p_end FOR READ ONLY; OPEN cur_by_date(2024-01-01, 2024-01-31);参数在声明时写在游标名后面的括号里OPEN 时按顺序传入。这样同一个游标定义可以复用于不同区间不用为每个时间段写一份。4. 验证请求与成功结果写完存储过程后别急着上生产先做三步验证。第一步确认存储过程创建成功。执行CREATE PROCEDURE后用系统表查一下SELECT procname, owner FROM sysprocedures WHERE procname sp_process_orders;能查到记录说明语法通过、已注册。第二步准备小批量测试数据跑一次看结果。建议先造 3 到 5 行status PENDING的订单然后调用EXECUTE PROCEDURE sp_process_orders();执行完查目标表SELECT COUNT(*) FROM orders_processed;行数应该和源表里符合条件的行数一致。再抽查一两行金额确认amount * 1.13算对了。第三步验证游标资源是否正常释放。连续调用存储过程多次观察数据库会话有没有游标泄漏。如果每次调用后CLOSE都执行到位重复调用不会报「游标已打开」之类的错。这一步能帮你提前发现忘记 CLOSE 的隐患。如果你用 API 辅助排查可以把报错信息和这段 SQL 一起发给模型让它帮你定位是声明问题还是取值问题。模型对话入口在 https://taotoken.net/models 适合做这种即时的逻辑问答。5. 本篇常见错误排查游标用起来不难但报错信息往往不够直白。下面这几个是我踩过的坑按出现频率排。SQLCODE 判断写反。有人写成IF SQLCODE 0 THEN EXIT;结果第一行就退出了。记住取到数据时 SQLCODE 为 0取不到才是非 0。循环里应该是「非 0 才退出」。FETCH 变量数量或类型对不上。SELECT 三列INTO 只写两个变量或者把 DECIMAL 塞进 INTEGER都会报错。声明游标时就把 SELECT 列和 INTO 变量一一列出来核对别凭记忆。可更新游标用了不可更新的 SELECT。带FOR UPDATE的游标SELECT 里出现 GROUP BY、聚合函数、UNION声明阶段就会失败。要更新就老老实实查明细行。忘记 CLOSE 导致游标堆积。在循环里提前 EXIT 或异常跳出时如果没走到 CLOSE游标会一直占着资源。稳妥做法是在异常处理块里也补上 CLOSE或者用ON EXCEPTION兜底。游标名重复。同一个存储过程里声明了两个同名游标或者重复 OPEN 同一个游标没先 CLOSE都会报错。命名上加点前缀区分OPEN 前确认状态。参数类型不匹配。带参数游标 OPEN 时传的日期格式和声明的不一致比如声明是 DATE传了字符串2024/01/01可能隐式转换失败。传参时用和声明一致的类型。遇到报错时先把完整的错误码和出错的那条语句截出来再对照上面几条排查基本能覆盖八成情况。如果逻辑比较复杂可以把游标循环拆成更小的存储过程分步验证比一次性写完再调试高效得多。6. 把游标逻辑稳定落地的几个习惯游标本身不复杂难的是在批量场景下让它稳定、可维护。我自己的习惯是先在存储过程里把逐行逻辑跑通用几十行测试数据验证边界空结果集、单行、多行、异常行确认无误再考虑迁移到 ESQL/C 或应用层。声明时能加FOR READ ONLY就别用可更新只读游标的执行计划更优、锁更少。另外逐行处理天然比集合操作慢如果数据量到了几十万行以上先评估能不能用集合 SQL 改写游标留给真正需要逐行判断的场景。真要用游标尽量缩小 SELECT 的范围用 WHERE 先把无关行过滤掉别把整表拉进游标再在循环里筛。需要长期做这类数据加工、写存储过程和调试 SQL 的话可以考虑用 Coding Plan 把模型接入到日常开发流里边写边让它帮你审查游标逻辑和异常分支入口在 https://taotoken.net/coding-plan 。接入文档在 https://taotoken.net/doc API Keys 在 https://taotoken.net/api-keys 按需取用就行。