1. 存储过程里那个让人抓头的声明顺序报错如果你在 MySQL 里写存储过程尤其是那种带游标遍历、又配了CONTINUE HANDLER处理NOT FOUND的写法大概率见过这条报错Variable or condition declaration after cursor or handler declaration。它不像语法错误那样直接指到某一行而是告诉你「声明顺序不对」但很多人第一反应是我变量不都写在BEGIN后面了吗怎么就错了这条报错的本质是 MySQL 对存储程序块内声明顺序有硬性要求。一个BEGIN ... END块里合法的声明顺序是固定的先是变量和条件DECLARE var ...、DECLARE condition ...然后是游标DECLARE cursor_name CURSOR FOR ...最后才是 handlerDECLARE ... HANDLER FOR ...。一旦你把某个变量声明写到了游标或 handler 后面MySQL 解析时就会抛出这个错误。它适合谁适合正在写或维护存储过程的后端、数据开发、DBA以及用 Codex 这类 AI 编码助手帮忙改 SQL 的人。这篇我用 TaoToken 接入的 Codex 来定位并修掉这个报错思路是让 Codex 只做两件事标出哪些DECLARE变量落在了 cursor 或 handler 之后再按 MySQL 规则把它们移到前面。TaoToken 在这里只提供 Codex 可用的 Key 和兼容通道不直接操作你的数据库改完还是回到你自己的 SQL 客户端执行验证。2. 先看清 MySQL 的声明顺序规则在动手改之前得先理解规则本身不然 Codex 改完你也不知道对不对。MySQL 存储程序块内的声明必须遵循这个次序顺序声明类型示例1变量 / 条件DECLARE done INT DEFAULT 0;2游标DECLARE cur CURSOR FOR SELECT ...;3handlerDECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1;关键点在于游标和 handler 里引用的变量必须声明在它们前面。比如 handler 里常写SET done 1这个done就必须在 handler 之前声明游标的SELECT ... WHERE id v_id里用到的v_id也必须在游标之前声明。很多人踩的坑是写的时候顺手把done或者某个循环变量写在了 handler 后面逻辑上没问题但 MySQL 解析器不认。下面是一段典型的错误结构DELIMITER $$ CREATE PROCEDURE p_bad() BEGIN DECLARE cur CURSOR FOR SELECT id FROM t_user; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; DECLARE done INT DEFAULT 0; -- 错误变量在 cursor/handler 之后 DECLARE v_id INT; OPEN cur; read_loop: LOOP FETCH cur INTO v_id; IF done THEN LEAVE read_loop; END IF; END LOOP; CLOSE cur; END$$ DELIMITER ;这段执行就会报Variable or condition declaration after cursor or handler declaration。注意done被放在了 handler 后面而 handler 又引用了它双重违规。3. 用 TaoToken 接入 Codex 的前置准备要让 Codex 帮你排查先得把它接上。我试过用 TaoToken 做兼容通道流程不复杂。第一步打开官网注册账号https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册完进控制台创建 API Key入口在这里https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite创建 Key 的页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite拿到 Key 之后把 Codex 的 Base URL 配成https://taotoken.net/api这里有两个容易配错的点我单独拎出来说。第一Base URL 不要带/v1直接就是https://taotoken.net/api多写一段路径会导致请求 404。第二这个地址不要加任何 UTM 参数UTM 是给网页链接做来源统计用的配到 API Base URL 里会让请求地址变形。Key 的用法就是标准的 Bearer 形式放在请求头里。如果你更想先在网页里验证模型通不通可以用模型对话页面https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite接入相关的文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite配好之后Codex 就能通过这个通道调用模型了。再强调一次TaoToken 只负责提供 Key 和兼容通道它不会去连你的 MySQL也不会执行任何 SQL所有数据库操作都在你自己的客户端里完成。4. 把报错存储过程交给 Codex 定位前置准备好接下来是核心步骤。把上面那段报错的存储过程完整贴给 Codex并给它一个明确的指令限制它只做两件事避免它顺手把整个存储过程重写一遍、引入新问题。可以这样下指令下面是一段 MySQL 存储过程执行时报 Variable or condition declaration after cursor or handler declaration。 请只做两件事 1. 标出哪些 DECLARE 变量声明落在了 cursor 或 handler 声明之后 2. 按 MySQL 声明顺序要求把这些变量移到 cursor 和 handler 之前。 不要改写业务逻辑不要改游标 SQL只调整声明顺序。Codex 拿到后通常会先指出问题变量。以上面的例子它会告诉你done声明在DECLARE CONTINUE HANDLER之后属于违规同时v_id虽然没被 handler 引用但按规范也应放在游标之前。它给出的修正版本大致是这样DELIMITER $$ CREATE PROCEDURE p_fixed() BEGIN DECLARE done INT DEFAULT 0; -- 变量提前 DECLARE v_id INT; -- 变量提前 DECLARE cur CURSOR FOR SELECT id FROM t_user; -- 游标在变量之后 DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; -- handler 最后 OPEN cur; read_loop: LOOP FETCH cur INTO v_id; IF done THEN LEAVE read_loop; END IF; END LOOP; CLOSE cur; END$$ DELIMITER ;对比一下就能看出改动只有声明块的顺序两个变量上移到最前游标居中handler 压到最后。业务逻辑、游标 SQL、循环体一行没动。这正是我们要 Codex 做的——只调顺序不碰逻辑。如果你用的是 Codex 的编码场景长期要反复改这类 SQL可以考虑 Coding Plan入口https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite5. 回到 SQL 客户端验证报错消失Codex 给的是文本建议真正验证得回到你的 SQL 客户端。把修正后的存储过程重新执行一遍DROP PROCEDURE IF EXISTS p_fixed; DELIMITER $$ CREATE PROCEDURE p_fixed() BEGIN DECLARE done INT DEFAULT 0; DECLARE v_id INT; DECLARE cur CURSOR FOR SELECT id FROM t_user; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; OPEN cur; read_loop: LOOP FETCH cur INTO v_id; IF done THEN LEAVE read_loop; END IF; END LOOP; CLOSE cur; END$$ DELIMITER ;如果创建成功客户端不会再有报错说明声明顺序已经合规。接着调用一次确认逻辑正常CALL p_fixed();预期结果是存储过程正常执行完毕没有Variable or condition declaration after cursor or handler declaration也没有其他声明类错误。到这一步问题就算解决了。整个过程里Codex 负责定位和给修正建议TaoToken 负责让 Codex 能调通模型数据库执行始终在你自己的环境里。6. 这类报错的高频排查清单改完一个不代表以后不踩我把这类报错的常见变体整理成排查清单下次遇到可以照着对。第一种handler 引用的变量声明在 handler 之后。这是最典型的done、err_code这类 handler 里用到的变量必须全部前置。第二种游标SELECT里用到的变量声明在游标之后比如WHERE status v_statusv_status得在游标前。第三种多个 handler 之间插了变量声明比如两个DECLARE ... HANDLER中间夹了个DECLARE v_x INT同样违规。第四种嵌套块里内层变量顺序错外层没问题但内层BEGIN ... END里又犯了同样的错需要逐层检查。排查时有个实用技巧把每个BEGIN ... END块单独看按「变量 → 游标 → handler」三段归类凡是变量出现在游标或 handler 之后的一律上移。如果存储过程很长直接搜DECLARE关键字按出现顺序核对类型比肉眼扫快得多。另外提醒一句MySQL 不同版本对声明顺序的校验严格程度略有差异有的版本报错信息措辞不同但规则是一致的。遇到类似「declaration after」的提示先怀疑声明顺序基本不会错。如果你在接入 Codex 或调用模型时遇到问题比如 Key 不生效、Base URL 配错可以对照接入文档排查https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite需要重新生成或管理 Key去 API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite想先在网页里验证模型是否正常响应用模型对话https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite最后说个我自己的习惯每次让 Codex 改存储过程都要求它「只调声明顺序、不动逻辑」改完自己在客户端跑一遍CALL。AI 给的是建议数据库认的是执行结果两步都走完才算真的修好。
Variable or condition declaration？用 TaoToken 接入的 Codex 排查 MySQL 游标声明顺序
1. 存储过程里那个让人抓头的声明顺序报错如果你在 MySQL 里写存储过程尤其是那种带游标遍历、又配了CONTINUE HANDLER处理NOT FOUND的写法大概率见过这条报错Variable or condition declaration after cursor or handler declaration。它不像语法错误那样直接指到某一行而是告诉你「声明顺序不对」但很多人第一反应是我变量不都写在BEGIN后面了吗怎么就错了这条报错的本质是 MySQL 对存储程序块内声明顺序有硬性要求。一个BEGIN ... END块里合法的声明顺序是固定的先是变量和条件DECLARE var ...、DECLARE condition ...然后是游标DECLARE cursor_name CURSOR FOR ...最后才是 handlerDECLARE ... HANDLER FOR ...。一旦你把某个变量声明写到了游标或 handler 后面MySQL 解析时就会抛出这个错误。它适合谁适合正在写或维护存储过程的后端、数据开发、DBA以及用 Codex 这类 AI 编码助手帮忙改 SQL 的人。这篇我用 TaoToken 接入的 Codex 来定位并修掉这个报错思路是让 Codex 只做两件事标出哪些DECLARE变量落在了 cursor 或 handler 之后再按 MySQL 规则把它们移到前面。TaoToken 在这里只提供 Codex 可用的 Key 和兼容通道不直接操作你的数据库改完还是回到你自己的 SQL 客户端执行验证。2. 先看清 MySQL 的声明顺序规则在动手改之前得先理解规则本身不然 Codex 改完你也不知道对不对。MySQL 存储程序块内的声明必须遵循这个次序顺序声明类型示例1变量 / 条件DECLARE done INT DEFAULT 0;2游标DECLARE cur CURSOR FOR SELECT ...;3handlerDECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1;关键点在于游标和 handler 里引用的变量必须声明在它们前面。比如 handler 里常写SET done 1这个done就必须在 handler 之前声明游标的SELECT ... WHERE id v_id里用到的v_id也必须在游标之前声明。很多人踩的坑是写的时候顺手把done或者某个循环变量写在了 handler 后面逻辑上没问题但 MySQL 解析器不认。下面是一段典型的错误结构DELIMITER $$ CREATE PROCEDURE p_bad() BEGIN DECLARE cur CURSOR FOR SELECT id FROM t_user; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; DECLARE done INT DEFAULT 0; -- 错误变量在 cursor/handler 之后 DECLARE v_id INT; OPEN cur; read_loop: LOOP FETCH cur INTO v_id; IF done THEN LEAVE read_loop; END IF; END LOOP; CLOSE cur; END$$ DELIMITER ;这段执行就会报Variable or condition declaration after cursor or handler declaration。注意done被放在了 handler 后面而 handler 又引用了它双重违规。3. 用 TaoToken 接入 Codex 的前置准备要让 Codex 帮你排查先得把它接上。我试过用 TaoToken 做兼容通道流程不复杂。第一步打开官网注册账号https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册完进控制台创建 API Key入口在这里https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite创建 Key 的页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite拿到 Key 之后把 Codex 的 Base URL 配成https://taotoken.net/api这里有两个容易配错的点我单独拎出来说。第一Base URL 不要带/v1直接就是https://taotoken.net/api多写一段路径会导致请求 404。第二这个地址不要加任何 UTM 参数UTM 是给网页链接做来源统计用的配到 API Base URL 里会让请求地址变形。Key 的用法就是标准的 Bearer 形式放在请求头里。如果你更想先在网页里验证模型通不通可以用模型对话页面https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite接入相关的文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite配好之后Codex 就能通过这个通道调用模型了。再强调一次TaoToken 只负责提供 Key 和兼容通道它不会去连你的 MySQL也不会执行任何 SQL所有数据库操作都在你自己的客户端里完成。4. 把报错存储过程交给 Codex 定位前置准备好接下来是核心步骤。把上面那段报错的存储过程完整贴给 Codex并给它一个明确的指令限制它只做两件事避免它顺手把整个存储过程重写一遍、引入新问题。可以这样下指令下面是一段 MySQL 存储过程执行时报 Variable or condition declaration after cursor or handler declaration。 请只做两件事 1. 标出哪些 DECLARE 变量声明落在了 cursor 或 handler 声明之后 2. 按 MySQL 声明顺序要求把这些变量移到 cursor 和 handler 之前。 不要改写业务逻辑不要改游标 SQL只调整声明顺序。Codex 拿到后通常会先指出问题变量。以上面的例子它会告诉你done声明在DECLARE CONTINUE HANDLER之后属于违规同时v_id虽然没被 handler 引用但按规范也应放在游标之前。它给出的修正版本大致是这样DELIMITER $$ CREATE PROCEDURE p_fixed() BEGIN DECLARE done INT DEFAULT 0; -- 变量提前 DECLARE v_id INT; -- 变量提前 DECLARE cur CURSOR FOR SELECT id FROM t_user; -- 游标在变量之后 DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; -- handler 最后 OPEN cur; read_loop: LOOP FETCH cur INTO v_id; IF done THEN LEAVE read_loop; END IF; END LOOP; CLOSE cur; END$$ DELIMITER ;对比一下就能看出改动只有声明块的顺序两个变量上移到最前游标居中handler 压到最后。业务逻辑、游标 SQL、循环体一行没动。这正是我们要 Codex 做的——只调顺序不碰逻辑。如果你用的是 Codex 的编码场景长期要反复改这类 SQL可以考虑 Coding Plan入口https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite5. 回到 SQL 客户端验证报错消失Codex 给的是文本建议真正验证得回到你的 SQL 客户端。把修正后的存储过程重新执行一遍DROP PROCEDURE IF EXISTS p_fixed; DELIMITER $$ CREATE PROCEDURE p_fixed() BEGIN DECLARE done INT DEFAULT 0; DECLARE v_id INT; DECLARE cur CURSOR FOR SELECT id FROM t_user; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done 1; OPEN cur; read_loop: LOOP FETCH cur INTO v_id; IF done THEN LEAVE read_loop; END IF; END LOOP; CLOSE cur; END$$ DELIMITER ;如果创建成功客户端不会再有报错说明声明顺序已经合规。接着调用一次确认逻辑正常CALL p_fixed();预期结果是存储过程正常执行完毕没有Variable or condition declaration after cursor or handler declaration也没有其他声明类错误。到这一步问题就算解决了。整个过程里Codex 负责定位和给修正建议TaoToken 负责让 Codex 能调通模型数据库执行始终在你自己的环境里。6. 这类报错的高频排查清单改完一个不代表以后不踩我把这类报错的常见变体整理成排查清单下次遇到可以照着对。第一种handler 引用的变量声明在 handler 之后。这是最典型的done、err_code这类 handler 里用到的变量必须全部前置。第二种游标SELECT里用到的变量声明在游标之后比如WHERE status v_statusv_status得在游标前。第三种多个 handler 之间插了变量声明比如两个DECLARE ... HANDLER中间夹了个DECLARE v_x INT同样违规。第四种嵌套块里内层变量顺序错外层没问题但内层BEGIN ... END里又犯了同样的错需要逐层检查。排查时有个实用技巧把每个BEGIN ... END块单独看按「变量 → 游标 → handler」三段归类凡是变量出现在游标或 handler 之后的一律上移。如果存储过程很长直接搜DECLARE关键字按出现顺序核对类型比肉眼扫快得多。另外提醒一句MySQL 不同版本对声明顺序的校验严格程度略有差异有的版本报错信息措辞不同但规则是一致的。遇到类似「declaration after」的提示先怀疑声明顺序基本不会错。如果你在接入 Codex 或调用模型时遇到问题比如 Key 不生效、Base URL 配错可以对照接入文档排查https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite需要重新生成或管理 Key去 API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite想先在网页里验证模型是否正常响应用模型对话https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite最后说个我自己的习惯每次让 Codex 改存储过程都要求它「只调声明顺序、不动逻辑」改完自己在客户端跑一遍CALL。AI 给的是建议数据库认的是执行结果两步都走完才算真的修好。