局部变量作用域限于声明它的BEGIN/END块，不可跨块访问；@用户变量作用域为当前会话，可跨结构使用但需防连接池复用污染；同名时局部变量优先级高于@变量。
局部变量只在 BEGIN/END 块内有效
存储过程中用 DECLARE 定义的变量，作用域严格限定在它被声明的那个 BEGIN/END 块里。哪怕嵌套了多层 BEGIN/END，外层块也访问不到内层 DECLARE 的变量，反之亦然。
常见错误现象：
- 在
IF或WHILE块里DECLARE一个变量，然后试图在块外SELECT它 → 报错Unknown column 'xxx' in 'field list' - 同一存储过程里两个并列的
BEGIN/END块各自DECLARE同名变量 → 不冲突，互不影响
实操建议：
-
DECLARE必须放在每个BEGIN块的最开头（在任何SET、SELECT、流程控制语句之前） - 不支持在条件分支内部动态声明，比如不能写
IF @flag THEN DECLARE v INT DEFAULT 0; END IF; - 类型必须显式指定，如
DECLARE v_count INT DEFAULT 0;，不能留空或靠推断
@用户变量跨语句但仅限当前会话
@ 开头的变量不需要 DECLARE，首次赋值即创建，生命周期绑定当前连接。它能穿透 BEGIN/END、IF、WHILE 等任意结构，只要连接没断，就能读写。
使用场景：
- 在循环中累计计数，退出循环后仍需使用该值
- 把
SELECT查询结果暂存为中间状态，供后续多个UPDATE或INSERT引用 - 调试时临时观察某字段值：
SELECT @debug := column_name FROM t LIMIT 1;，再SELECT @debug;
关键细节：
- 在
SELECT语句中赋值必须用:=，写成=会被当成比较操作符 → 结果恒为0或1 -
SET @var = 1, @var2 := 2;这种混合写法合法，但易混淆，建议统一用:= - 未赋值就引用，值为
NULL，且不会报错，容易掩盖逻辑漏洞
局部变量和 @变量混用时的优先级陷阱
当存储过程中同时存在同名的局部变量和 @ 用户变量，MySQL 默认优先解析为局部变量。这会导致你以为在操作 @var，实际改的是局部 var，而 @var 完全没变。
典型误用：
DELIMITER $$ CREATE PROCEDURE test_proc() BEGIN DECLARE v INT DEFAULT 10; SET @v = 20; SELECT v, @v; -- 输出 10 和 20，正常 SELECT v := 100; -- 这里修改的是局部变量 v，不是 @v！ SELECT v, @v; -- 输出 100 和 20，@v 仍是 20 END$$
避免方式：
- 命名风格隔离：局部变量用
v_count、tmp_name；用户变量坚持用@total_sum、@last_id，避免纯单词重名 - 不用
:=对局部变量赋值时省略SET（如SELECT ... INTO v更安全） - 调试时用
SELECT 'local:', v, 'user:', @v;显式区分
会话断开后用户变量自动销毁，但别依赖这个“清理”
@ 变量确实随连接关闭而消失，看起来很“干净”。但现实中很多应用用连接池，同一个物理连接会被复用，上一次调用留下的 @ 变量可能污染下一次执行。
所以：
- 不要假设
@变量初始为NULL，每次使用前显式初始化，比如SET @counter := 0; - 存储过程结尾不必特意
SET @var = NULL;，但入口处重置比依赖自动销毁更可靠 - 如果逻辑复杂、分支多，用局部变量代替
@变量更可控 —— 虽然要多写几行DECLARE，但作用域清晰，不易串扰
真正容易被忽略的点是：局部变量无法跨存储过程传递，而 @ 变量可以（只要在同个会话里）。但这恰恰是危险信号——用 @ 实现“参数传递”，会让调用关系隐晦难维护。
