declare必须紧接begin之后，否则报错error 1064；嵌套块中同名变量会静默遮蔽外层变量；局部变量不可用于prepare；@用户变量与局部变量同名时存在优先级陷阱；需通过命名隔离（如l_前缀）和作用域树分析规避混淆。
DECLARE必须紧接BEGIN之后，否则直接报错
MySQL解析器不接受任何“先执行再声明”的写法。一旦在BEGIN后写了SELECT、SET或IF，后续的DECLARE就立刻触发ERROR 1064或ERROR 1337。
- 错误写法：
BEGIN SELECT 1; DECLARE x INT;→ 解析失败 - 正确顺序：所有
DECLARE（含CURSOR、HANDLER）必须堆在BEGIN后第一行起，中间不能插任何可执行语句 - 嵌套块也得各自重排：每个
BEGIN ... END内部都要独立满足这条规则，不能靠外层声明“透传”
嵌套块里同名变量会静默遮蔽，不警告也不报错
内层BEGIN ... END中DECLARE x INT不会和外层同名变量冲突，而是自动创建新副本并遮蔽（shadow）外层变量。运行时读写的是当前块的值，但调试时极易误判为“同一个变量被改了”。
- 现象：
outer: DECLARE x INT DEFAULT 10;，进入BLOCK2: BEGIN DECLARE x INT DEFAULT 20;，里面SELECT x返回20，出来后SELECT x仍返回10 - 风险点：循环中反复进出嵌套块，看似“重置”，实则是每次新建变量；日志或调试输出只看最终值，会漏掉遮蔽过程
- 缓解方式：局部变量统一加前缀，如
l_counter、l_user_id；参数用p_id；用户变量坚持用@batch_start_time这类带业务含义的命名
PREPARE动态SQL根本认不出DECLARE变量
PREPARE只接受字面字符串或@用户变量，对DECLARE声明的局部变量完全无视。硬塞进去不会报错，但执行时变成NULL或触发Unknown column 'v_id'。
- 错误尝试：
DECLARE v_id INT DEFAULT 123; PREPARE stmt FROM 'SELECT * FROM t WHERE id = ?'; EXECUTE stmt USING v_id; - 可行方案：先
SET @v_id = v_id;，再EXECUTE stmt USING @v_id; - 拼接方案：用
CONCAT()，但字符串值必须套QUOTE(v_str)防注入；还要检查@sql长度是否超出max_allowed_packet
@用户变量和局部变量同名时优先级陷阱
当同时存在DECLARE v INT和SET @v = 5，后续写SET v = 100修改的是局部变量，@v仍为5——但你可能以为两者联动。最典型的是循环中用@sum := @sum + val累加，退出后SELECT @sum却拿到旧值，因为某处声明了同名局部变量v意外覆盖了引用。
-
SELECT v := 100这种写法默认操作局部变量，不是赋值给@v - 安全做法：严格命名隔离——局部变量用
l_前缀，用户变量坚持用@且带业务含义 -
作用域树要画到块层级：局部变量生命周期只到
END就结束，但遮蔽逻辑和@变量残留效应，往往在多层嵌套+动态SQL混合场景下才暴露
变量作用域混乱的根子不在语法难记，而在MySQL把“块结构”当作唯一作用域边界——缩进、注释、IF分支都不算数，只有显式的BEGIN ... END才算。一旦嵌套变深、又混入PREPARE或@变量，光看单个DECLARE位置已经不够，得顺着块结构逐层画作用域树才能看清数据流向。
