在MySQL存储过程中，定义局部变量时必须置于最前面，这是为什么呢？许多新手开发者都曾遇到这个困扰：编写完一大段逻辑后，再添加变量声明，编译时却直接报错。不必着急，先搞清楚MySQL解析器究竟如何处理DECLARE语句，这些规则其实并不难掌握。
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个，通常意味着逻辑需要重构——这并非语法限制，而是可维护性的红线。
