1. SQL 游标是什么为什么存储过程里还在用它SQL 游标Cursor是数据库里用来逐行处理结果集的机制。平时我们写SELECT拿到的是一整块结果集而游标让你能一行一行地取、一行一行地处理特别适合那些「必须按顺序、必须逐条判断」的场景比如批量给用户发积分、逐条校验订单状态、按行调用存储过程做数据迁移。它适合谁数据库开发和运维同学尤其是写 T-SQL 存储过程、做批处理脚本、维护老系统的人。你可能会问现在都讲集合操作了游标是不是过时了我的经验是能用集合操作就别用游标但有些逻辑天生就是逐行的比如「每一行都要根据上一行的结果决定下一步」这时候游标反而是最直白的写法。游标的核心生命周期就四步DECLARE声明→OPEN打开→FETCH取数→CLOSEDEALLOCATE关闭并释放。听起来简单但真正踩坑的地方在于取数顺序对不对、循环什么时候退出、资源有没有释放干净。这篇就围绕这四个动作给你一套可复制的骨架再用最小示例表验证取数顺序和资源释放。先明确一个概念游标分普通游标和滚动游标。普通游标只能FETCH NEXT一路往下走滚动游标SCROLL支持FIRST、LAST、PRIOR、ABSOLUTE n、RELATIVE n等操作能前后跳。选哪种取决于你的业务是否需要回看或跳转。下面这段是最常见的普通游标骨架先看整体结构后面再逐段拆DECLARE UserId varchar(100), UserName varchar(20); DECLARE cursor_name CURSOR FOR SELECT TOP 10 UserId, UserName FROM UserInfo ORDER BY UserId DESC; OPEN cursor_name; FETCH NEXT FROM cursor_name INTO UserId, UserName; WHILE FETCH_STATUS 0 BEGIN PRINT 用户ID UserId 用户名 UserName; FETCH NEXT FROM cursor_name INTO UserId, UserName; END CLOSE cursor_name; DEALLOCATE cursor_name;这段代码里有两个关键点新手最容易忽略。第一FETCH必须在WHILE之前先执行一次否则FETCH_STATUS的初始值不可靠可能直接跳过第一行或者多循环一次。第二循环体末尾必须再FETCH一次把指针推到下一行否则就是死循环。FETCH_STATUS的取值0 表示取数成功-1 表示越过了结果集末尾-2 表示被取的行已不存在比如被别的会话删了。我试过在几万行的表上直接跑游标速度确实感人所以实际生产里一定要加WHERE或TOP限制范围别对着全表开游标。游标不是不能用是要用得克制。2. 用最小示例表验证取数顺序与资源释放光看语法不够得有一张能跑的表来验证。我们建一张最小的UserInfo插 10 行数据然后分别用普通游标和滚动游标跑一遍观察取数顺序。CREATE TABLE UserInfo ( UserId varchar(100), UserName varchar(20) ); INSERT INTO UserInfo (UserId, UserName) VALUES (zhizhi, 邓鸿芝), (yuyu, 魏雨), (yujie, 李玉杰), (yuanyuan, 王梦缘), (YOUYOU, lisi), (yiyiren, 任毅), (yanbo, 王艳波), (xuxu, 陈佳绪), (xiangxiang,李庆祥), (wenwen, 魏文文);注意这里ORDER BY UserId DESC之后zhizhi排在最前wenwen排在最后。普通游标按NEXT顺序取输出就是zhizhi → yuyu → yujie → ... → wenwen和SELECT直接查出来的顺序一致。这一点很重要游标的取数顺序完全由DECLARE ... CURSOR FOR里的SELECT决定游标本身不排序。接下来验证滚动游标。滚动游标声明时要加SCROLL关键字SET NOCOUNT ON; DECLARE C SCROLL CURSOR FOR SELECT TOP 10 UserId, UserName FROM UserInfo ORDER BY UserId DESC; OPEN C; FETCH LAST FROM C; -- 最后一行wenwen FETCH ABSOLUTE 4 FROM C; -- 从第一行数第 4 行yuanyuan FETCH RELATIVE 3 FROM C; -- 相对当前行往后 3 行xuxu FETCH RELATIVE -2 FROM C; -- 相对当前行往前 2 行yiyiren FETCH PRIOR FROM C; -- 当前行前一行YOUYOU FETCH FIRST FROM C; -- 回到第一行zhizhi FETCH NEXT FROM C; -- 往后一行yuyu CLOSE C; DEALLOCATE C;这里ABSOLUTE n和RELATIVE n的区别要记牢ABSOLUTE是相对结果集开头n 为正或结尾n 为负的绝对位置n0不返回任何行RELATIVE是相对当前行的偏移正数往后、负数往前n0返回当前行。第一次FETCH就用RELATIVE负数或 0是取不到行的因为此时指针在第一行之前。验证资源释放有个实用技巧在CLOSE之后、DEALLOCATE之前如果你再尝试FETCH会报「游标未打开」之类的错这恰好说明CLOSE生效了。而DEALLOCATE之后游标名就彻底从会话里消失再引用会报「游标不存在」。你可以故意在DEALLOCATE后加一句FETCH NEXT FROM C看报错信息加深印象。另外游标是会话级的资源。如果你在存储过程里开了游标却忘了DEALLOCATE这个游标会一直占着内存和锁直到会话结束。批量任务里反复调用同一个存储过程很容易把连接池拖垮。所以「关闭并释放」不是可选项是必须项。3. 可复制的游标配置骨架与循环模板这一节给你两套可以直接抄的模板一套普通游标循环一套滚动游标。同时把配置项和参数含义讲清楚方便你按业务改。普通游标循环模板带异常保护CREATE PROCEDURE dbo.ProcessUsers AS BEGIN SET NOCOUNT ON; DECLARE UserId varchar(100); DECLARE UserName varchar(20); DECLARE cur_users CURSOR LOCAL FAST_FORWARD FOR SELECT UserId, UserName FROM UserInfo WHERE UserId IS NOT NULL ORDER BY UserId DESC; OPEN cur_users; FETCH NEXT FROM cur_users INTO UserId, UserName; WHILE FETCH_STATUS 0 BEGIN BEGIN TRY -- 这里写你的逐行业务逻辑 PRINT 处理用户 UserId / UserName; END TRY BEGIN CATCH PRINT 处理 UserId 出错 ERROR_MESSAGE(); END CATCH FETCH NEXT FROM cur_users INTO UserId, UserName; END CLOSE cur_users; DEALLOCATE cur_users; END这里LOCAL FAST_FORWARD是两个重要选项。LOCAL表示游标作用域只在当前存储过程/批处理内出了作用域自动失效减少资源泄漏风险。FAST_FORWARD表示只进、只读数据库可以据此做优化性能比默认游标好不少。如果你的业务需要更新游标当前行才考虑FOR UPDATE但那样会加锁要谨慎。滚动游标模板DECLARE UserId varchar(100); DECLARE UserName varchar(20); DECLARE cur_scroll SCROLL CURSOR FOR SELECT UserId, UserName FROM UserInfo ORDER BY UserId DESC; OPEN cur_scroll; FETCH ABSOLUTE 3 FROM cur_scroll INTO UserId, UserName; WHILE FETCH_STATUS 0 BEGIN PRINT 第 3 行起 UserId / UserName; FETCH NEXT FROM cur_scroll INTO UserId, UserName; END CLOSE cur_scroll; DEALLOCATE cur_scroll;FETCH的完整语法结构是这样的FETCH [ [ NEXT | PRIOR | FIRST | LAST | ABSOLUTE { n | nvar } | RELATIVE { n | nvar } ] FROM ] { { [ GLOBAL ] cursor_name } | cursor_variable_name } [ INTO variable_name [ ,...n ] ]几个参数要点NEXT是默认选项不写就是它INTO后面的变量个数必须和SELECT列数一致类型要能隐式转换GLOBAL用于区分同名全局游标和局部游标不写默认指向局部游标。n必须是整数常量nvar可以是smallint、tinyint或int。如果你在存储过程里用游标变量可以这样写DECLARE cur CURSOR; SET cur CURSOR FOR SELECT UserId FROM UserInfo; OPEN cur; FETCH NEXT FROM cur INTO UserId;游标变量的好处是可以作为参数传递但可读性差一些团队协作时建议还是用具名游标。4. 验证请求与成功结果跑一遍看输出配置写完必须实际跑一遍确认取数顺序和资源释放都对。下面给出完整的验证脚本和预期输出。先跑普通游标DECLARE UserId varchar(100), UserName varchar(20); DECLARE cursor_name CURSOR FOR SELECT TOP 10 UserId, UserName FROM UserInfo ORDER BY UserId DESC; OPEN cursor_name; FETCH NEXT FROM cursor_name INTO UserId, UserName; WHILE FETCH_STATUS 0 BEGIN PRINT 用户ID UserId 用户名 UserName; FETCH NEXT FROM cursor_name INTO UserId, UserName; END CLOSE cursor_name; DEALLOCATE cursor_name;预期输出按UserId DESC排序用户IDzhizhi 用户名邓鸿芝 用户IDyuyu 用户名魏雨 用户IDyujie 用户名李玉杰 用户IDyuanyuan 用户名王梦缘 用户IDYOUYOU 用户名lisi 用户IDyiyiren 用户名任毅 用户IDyanbo 用户名王艳波 用户IDxuxu 用户名陈佳绪 用户IDxiangxiang 用户名李庆祥 用户IDwenwen 用户名魏文文如果你看到的顺序和这个不一致先检查ORDER BY是不是被去掉了或者表里有没有重复的UserId导致排序不稳定。游标本身不保证顺序顺序全靠SELECT里的ORDER BY。再跑滚动游标验证跳转SET NOCOUNT ON; DECLARE UserId varchar(100), UserName varchar(20); DECLARE C SCROLL CURSOR FOR SELECT TOP 10 UserId, UserName FROM UserInfo ORDER BY UserId DESC; OPEN C; FETCH LAST FROM C INTO UserId, UserName; PRINT LAST: UserId; FETCH ABSOLUTE 4 FROM C INTO UserId, UserName; PRINT ABS 4: UserId; FETCH RELATIVE 3 FROM C INTO UserId, UserName; PRINT REL 3: UserId; FETCH RELATIVE -2 FROM C INTO UserId, UserName; PRINT REL -2: UserId; FETCH PRIOR FROM C INTO UserId, UserName; PRINT PRIOR: UserId; FETCH FIRST FROM C INTO UserId, UserName; PRINT FIRST: UserId; FETCH NEXT FROM C INTO UserId, UserName; PRINT NEXT: UserId; CLOSE C; DEALLOCATE C;预期输出LAST: wenwen ABS 4: yuanyuan REL 3: xuxu REL -2: yiyiren PRIOR: YOUYOU FIRST: zhizhi NEXT: yuyu对照着看LAST拿到最后一行wenwenABSOLUTE 4从第一行数第 4 行是yuanyuan此时当前行是yuanyuanRELATIVE 3往后 3 行是xuxu再RELATIVE -2往前 2 行是yiyirenPRIOR再往前一行是YOUYOUFIRST回到zhizhiNEXT到yuyu。每一步都符合预期说明滚动游标的定位逻辑正确。验证资源释放可以在DEALLOCATE之后故意引用游标-- 在 DEALLOCATE C 之后执行 FETCH NEXT FROM C INTO UserId, UserName;会报错提示游标不存在说明释放成功。如果没报错说明你前面漏了DEALLOCATE或者游标是GLOBAL作用域还在。5. 常见报错排查401、local proxy failed、reading choices、OAuth游标本身是数据库层的东西但很多同学是在用 AI 辅助写 SQL、或者通过 API 调用模型生成游标代码时遇到报错这里把两类问题都覆盖一下。数据库侧最常见的报错是「游标已存在」和「游标未打开」。前者通常是因为同名游标没释放就重复DECLARE解决办法是加LOCAL作用域或者在DECLARE前先判断并DEALLOCATE。后者是忘了OPEN就FETCH检查生命周期四步是否齐全。如果你是通过 API 让模型帮你生成或调试游标代码可能会碰到下面这些报错401 Unauthorized通常是 API Key 没带对或过期了。检查请求头里的Authorization: Bearer 你的Key是否正确Key 有没有多余空格。如果你用的是 TaoToken 这类聚合入口确认 Key 是在对应控制台生成的别拿错环境的 Key。local proxy failed这个报错一般出现在本地网络配置或客户端代理设置上。检查你的客户端 Base URL 是不是写成了本地地址或者系统代理把请求拦了。把 Base URL 改成正确的 API 地址关掉不必要的本地代理再试。reading choices相关报错多出现在解析模型返回结构时比如你按 OpenAI 格式去读choices[0].message.content但实际返回结构不一样。先打印完整响应体确认字段路径再改解析代码。OAuth相关报错如果你用的是 Claude Code 这类需要 OAuth 授权的工具报错通常和 token 刷新、回调地址有关。检查授权是否完成、token 是否过期必要时重新走一遍授权流程。这里要提醒一句不管用哪种方式调模型Base URL、API Key、Model ID 这三件套必须配套。Base URL 指向服务地址Key 负责鉴权Model ID 决定用哪个模型。三者任何一个不对都会报错。如果你在 Cline、CC Switch 或 Codex 的auth.json里配置记得把这三项都填全别只填 Key。排查顺序建议先看 HTTP 状态码401/403/404/500再看响应体里的错误信息最后对照配置项逐个核对。大部分问题都是配置写错不是代码逻辑错。6. 把游标用对接入与验证的收尾动作游标写完之后收尾动作别省。第一确认CLOSE和DEALLOCATE都执行了最好放在TRY...CATCH的FINALLY逻辑里T-SQL 没有 finally但可以在CATCH里补上释放。第二确认游标作用域是LOCAL避免跨过程泄漏。第三确认SELECT里有明确的ORDER BY否则取数顺序不可预期。如果你在写存储过程时需要模型帮你审查游标逻辑或者想快速生成一套带异常保护的模板可以借助 API 来提速。配置的时候把 Base URL 指向https://taotoken.net/apiKey 在控制台生成Model ID 按你实际用的模型填。三件套配齐之后先发一个最小请求验证连通性再让它帮你生成或改写游标代码。验证模型是否正常响应可以直接在模型对话页面发一条测试消息确认返回结构符合预期。长期做数据库开发和 Agent 编排的同学可以考虑用 Coding Plan 来管理调用额度避免频繁切换配置。游标这个工具用对了是利器用错了是性能杀手。核心就一句话能集合就集合必须逐行时才开游标开了就记得关和释放。把这篇的模板抄进你的存储过程跑一遍验证脚本取数顺序和资源释放这两件事就算彻底搞明白了。