MySQL中SELECT x不等于SELECT @x，根本原因是标识符解析遵循“就近作用域优先”规则：x优先绑定已DECLARE的局部变量，仅当未声明时才报错；而@x明确指向会话变量，不受局部声明影响。
MySQL存储过程内查询不能直接使用外部会话变量，根本原因在于作用域隔离和执行上下文切换——@var虽在会话级可见，但存储过程内部的SQL解析器默认不将未显式声明的标识符解析为用户变量，尤其当同名局部变量存在时，SELECT x 会优先绑定到局部变量而非@x。
为什么SELECT @x能用，但SELECT x不等于SELECT @x
MySQL对无前缀标识符（如x）的解析遵循“就近作用域优先”规则：它先查当前BEGIN…END块中是否DECLARE x，再查外层块，最后才考虑会话变量。所以即使你之前SET @x = 100，只要过程里写了DECLARE x INT，SELECT x就永远读不到@x的值。
-
SELECT x→ 查局部变量x（若声明过），否则报Unknown column 'x' -
SELECT @x→ 明确指向会话变量，不受DECLARE影响 -
SET x = 5→ 默认赋值给最近作用域的局部变量x，不是@x
PREPARE动态SQL里为什么连@x都可能失效
动态SQL执行时处于独立解析环境，@x虽是会话级，但其值必须在PREPARE前已稳定存在；若在EXECUTE前被其他语句覆盖（比如嵌套调用改了@x），结果就不可控。更隐蔽的是：PREPARE语句本身不支持参数化USING传入@x以外的变量——USING只接受用户变量，不接受字面量或表达式。
- 错误写法：
EXECUTE stmt USING 123→ 报错ERROR 1210 - 正确写法：
SET @id = 123; EXECUTE stmt USING @id - 隐患点：
@id若在循环中反复赋值，且EXECUTE前没及时更新，就会查错记录
如何安全混用局部变量与会话变量
关键不是“能不能用”，而是“怎么避免歧义”。最稳妥的做法是命名强隔离+显式前缀：
- 所有局部变量统一加
l_前缀（如l_counter），杜绝和@batch_id等会话变量同名 - 会话变量坚持用带业务含义的
@名（如@log_start_time），不用@x这类泛称 - 在动态SQL拼接中，用
QUOTE(l_value)包裹字符串值，防注入；同时检查@sql长度是否超@@max_allowed_packet - 调试时别只看最终
SELECT，用SELECT 'debug', @x, l_x;并排输出，一眼识别哪个值被取到了
真正容易被忽略的是：MySQL不会警告你“这里本该用@x却读了l_x”，它静默按规则执行。变量名一旦重叠，逻辑就悄悄偏移，而错误往往出现在数据核对环节，不是语法报错时。
