MySQL中DECLARE变量必须紧接BEGIN后声明，嵌套块中同名变量会遮蔽外层变量，局部变量不可用于PREPARE，且与@用户变量同名时存在优先级陷阱，需严格命名隔离。
DECLARE变量必须放在BEGIN块最开头
MySQL要求所有DECLARE语句必须紧接在BEGIN之后、任何可执行语句（如SET、IF、SELECT）之前，否则直接报错ERROR 1064 (42000)。
- 错误写法：
BEGIN SELECT 1; DECLARE v INT;→ 语法错误 - 正确顺序：
BEGIN DECLARE v INT DEFAULT 0; SET v = 1; - 嵌套
BEGIN/END时，每个子块都需独立遵守该规则，不能复用外层声明
嵌套块中同名变量会静默遮蔽而非报错
内层BEGIN/END块里DECLARE同名变量，不会冲突，而是自动遮蔽（shadow）外层变量。运行时读写的是当前块声明的那个，容易误以为在操作同一个变量。
- 典型现象：外层
DECLARE x INT DEFAULT 10;，内层DECLARE x INT DEFAULT 20;，内层SELECT x;输出20，外层SELECT x;输出10 - 调试时若只查最终值，可能完全忽略中间遮蔽过程
- 避免方式：给局部变量加前缀，如
l_counter、l_user_id，和参数p_id、用户变量@total区分开
局部变量无法传入PREPARE动态SQL
PREPARE语句只接受字面字符串或@用户变量，不识别DECLARE的局部变量。硬塞进去会变成空值或触发Unknown column错误。
- 错误尝试：
PREPARE stmt FROM 'SELECT * FROM t WHERE id = ?'; EXECUTE stmt USING v_id;→v_id是局部变量，不被支持 - 可行方案：先赋值给
@变量，再用EXECUTE ... USING @var；或用CONCAT()拼接，但必须对字符串值调用QUOTE(v_str)防注入 - 注意：
@sql拼接后长度受max_allowed_packet限制，建议加CHAR_LENGTH(@sql)检查是否截断
@用户变量与局部变量同名时优先级陷阱
当存储过程中同时存在DECLARE v INT和SET @v = 5，后续写SET v = 100修改的是局部变量，@v仍为5——但你可能以为两者联动。
- 常见误判场景：循环中用
@sum := @sum + val累加，退出后又用SELECT @sum，结果却是旧值，因为中间某处声明了同名局部变量v并意外覆盖了引用 - 安全做法：严格命名隔离——局部变量用
l_前缀，用户变量坚持用@且带业务含义，如@batch_start_time - 切记：
SELECT v := 100这种写法默认操作局部变量，不是赋值给@v，极易埋雷
局部变量生命周期只到END就结束，但遮蔽逻辑和@变量残留效应常常在多层嵌套+动态SQL混合场景下才暴露，这时候光看单个DECLARE位置已经不够，得顺着块结构逐层画作用域树。
