为什么在MySQL存储过程中的局部变量定义必须放在最前面？

DECLARE必须紧贴BEGIN后立即出现，中间不可有任何语句、注释或空行；且声明顺序须为变量→游标→条件处理器，否则编译时报ERROR 1064或1337。

DECLARE 必须紧贴 BEGIN 后，否则直接报 ERROR 1064

MySQL 解析器在编译存储过程时，把 DECLARE 当作“块元信息”而非普通语句处理。它要求所有变量、游标、异常处理器的声明必须在 BEGIN 后**立即出现**，中间不能插任何东西——哪怕是一行注释、一个空行、或一条 SET @flag = 1。一旦错位，整个过程体就无法通过语法检查。

常见错误现象：

• BEGIN 后先写 -- 初始化检查 → 报 ERROR 1064 (42000)
• BEGIN 后先执行 SELECT 1; → 同样报 ERROR 1064，不是警告，是直接拒绝创建
• 误以为 @var 是局部变量，先写 SET @x = 10; 再 DECLARE x INT; → @x 是会话变量，和 x 完全无关，且 DECLARE 已错过合法位置

变量、游标、HANDLER 的声明顺序不能乱

MySQL 按照声明顺序分配内存和解析依赖关系。如果游标引用了某个变量，那个变量就必须在游标声明之前已存在；同理，异常处理器可能要读取某个状态变量，它也得提前声明好。

正确顺序只能是：

• 所有 DECLARE 变量（含 DEFAULT）
• 所有 DECLARE 游标
• 所有 DECLARE CONTINUE/EXIT HANDLER

反例：DECLARE cur CURSOR FOR SELECT id FROM t WHERE status = v_flag; 中的 v_flag 若还没声明，就会触发 ERROR 1337 (42000): Variable 'v_flag' is not declared —— 不是运行时报错，是创建时就失败。

未初始化变量默认为 NULL，但 NULL 参与计算容易出静默问题

不写 DEFAULT 的变量值就是 NULL，而 NULL 在多数运算中会传染：比如 WHERE id = v_id，若 v_id 是 NULL，结果永远为 FALSE；SET total = total + v_amt，若 v_amt 是 NULL，total 直接变 NULL。

所以建议：

• 计数类用 DECLARE cnt INT DEFAULT 0
• 字符串类用 DECLARE msg VARCHAR(255) DEFAULT ''
• 时间类用 DECLARE ts DATETIME DEFAULT NOW()
• 避免依赖隐式转换，比如 DEFAULT '0'（字符串）不如 DEFAULT 0（整数）明确

别用一堆 var1/var2 模拟数组，那是设计信号

局部变量本质是单值容器，强行用 DECLARE var1, var2, ..., var100 INT 来存批量数据，既不可读又难维护。MySQL 不支持数组类型，也没必要硬凑。

真实替代方案：

• 需要逐行处理？用 DECLARE cur_name CURSOR FOR ... + FETCH ... INTO v_single
• 需要多次复用中间结果？建临时表：CREATE TEMPORARY TABLE tmp_result AS SELECT ...
• 需要聚合后分发？直接在应用层做，或者拆成多个小存储过程，每个职责清晰

变量超过 10 个，基本说明逻辑该重构了——不是语法限制，而是可维护性红线。