MySQL局部变量“无法识别”主因是DECLARE未紧贴BEGIN后、嵌套遮蔽或PREPARE不支持；DECLARE必须位于BEGIN后首行，嵌套块需独立声明，PREPARE须转为@变量，命名应加前缀隔离作用域。
MySQL存储过程里局部变量“无法识别”，90%不是语法写错，而是作用域或声明位置踩了硬性规则——DECLARE必须紧贴BEGIN之后、任何可执行语句之前，且嵌套块中同名变量会静默遮蔽外层变量。
DECLARE语句位置错误直接报ERROR 1064
这是最常见也最容易定位的问题。MySQL强制要求所有DECLARE语句必须出现在BEGIN后的第一行（或紧随其后），中间不能夹杂任何SET、SELECT、IF等可执行语句。
- 错误写法：
BEGIN SELECT 1; DECLARE v INT;→ 立刻触发ERROR 1064 (42000) - 正确写法：
BEGIN DECLARE v INT DEFAULT 0; SET v = 1; - 嵌套块也需独立遵守：子
BEGIN内也要把DECLARE放最前，不能复用外层声明
同名变量在嵌套块中静默遮蔽
你写的SELECT x;输出的到底是哪一层的x？MySQL不会报错，也不会警告，它只按当前作用域取值——这就是“遮蔽”（shadowing）。
- 外层
DECLARE x INT DEFAULT 10;，内层DECLARE x INT DEFAULT 20;→ 内层SELECT x返回20，外层仍为10 - 调试时若只查最终结果，可能完全漏掉中间被覆盖的逻辑分支
- 解决办法：统一命名规范，局部变量加
l_前缀（如l_counter），参数用p_，用户变量坚持用@并带业务含义（如@batch_id）
PREPARE动态SQL里用不了DECLARE变量
PREPARE语句根本不认DECLARE声明的局部变量，硬塞进去等于传NULL，轻则查不到数据，重则触发Unknown column错误。
- 错误尝试：
PREPARE stmt FROM 'SELECT * FROM t WHERE id = ?'; EXECUTE stmt USING v_id;→v_id是局部变量，不被支持 - 可行方案1：
SET @v_id = v_id; PREPARE stmt FROM 'SELECT * FROM t WHERE id = ?'; EXECUTE stmt USING @v_id; - 可行方案2：用
CONCAT()拼接SQL，但字符串值必须套QUOTE(v_str)防注入；同时检查@sql长度：CHAR_LENGTH(@sql)
@用户变量和局部变量同名引发优先级陷阱
当你写了DECLARE v INT又写了SET @v = 5，后续SELECT v读的是局部变量，SELECT @v才是用户变量——但SELECT v := 100这种写法默认改的是局部变量，不是@v。
- 典型误判：循环中用
@sum := @sum + val累加，中途某处DECLARE sum DECIMAL，后面SELECT @sum就还是旧值 - 关键点：
:=赋值操作符左侧如果是未带@的标识符，MySQL优先绑定到最近作用域的局部变量，而不是创建/更新用户变量 - 真正安全的做法：彻底隔离命名空间，杜绝
l_total和@total共存于同一过程
最麻烦的情况是多层嵌套+动态SQL混合，这时候光看单个DECLARE位置已经不够，得顺着BEGIN/END结构画出作用域树——局部变量生命周期只到END就销毁，但遮蔽效应和@变量残留会在执行流中持续干扰，直到你亲手把它理清楚。
