mysql存储过程无法直接访问调用者的用户变量@var，因其作用域严格隔离于会话；必须通过in参数显式传值，或使用临时表、自定义系统变量等替代方案。
MySQL存储过程无法直接访问调用者的用户定义变量，是因为两者作用域完全隔离——用户变量（@var）只在客户端会话内有效，而存储过程运行在独立的执行上下文中，不继承调用方的会话变量。
用户变量根本不在存储过程的作用域里
MySQL 中 @var 是会话级变量，绑定到 TCP 连接或 Unix socket 连接的生命周期。当你执行 CALL proc_name() 时，存储过程启动的是一个新的执行帧，它能看到的只有自己内部声明的局部变量（DECLARE var_name ...），以及数据库对象（表、函数等），但绝不会自动“看到”外部 SET @x = 1 定义的值。
- 即使你在调用前执行了
SET @user_id = 123，proc_name内部查SELECT @user_id也会返回NULL - 这不是权限问题，也不是 bug，是 MySQL 明确设计的行为：每个会话空间严格隔离，防止跨连接污染
- 试图在存储过程中直接引用
@xxx不报错，但读出来是NULL，容易误判为逻辑错误
想传值？必须显式作为参数传入
唯一可靠的方式是把值当作输入参数传递进去，而不是依赖隐式共享：
- 存储过程定义时必须声明参数：
CREATE PROCEDURE get_user_info(IN p_user_id INT) - 调用时明确传参：
CALL get_user_info(@user_id)—— 这里@user_id是在 CALL 语句里被求值后传入的，不是过程内部“访问”它 - 如果参数类型不匹配（比如
@user_id是字符串但过程期望 INT），MySQL 会静默转换或截断，建议提前CAST或校验
为什么不能用 SET + SELECT 混合绕过？
有人试过在 CALL 前用 SELECT @x := col FROM t LIMIT 1 赋值，再进过程读取，依然无效。原因很实在：
-
SELECT @x := ...的赋值发生在客户端会话中，仅对该连接可见 - 存储过程执行时新开一个内部执行环境，不复用外部会话变量空间
- 哪怕你用
PREPARE/EXECUTE动态拼 SQL，在过程里执行SELECT @x，结果仍是NULL
真要共享状态？别用 @var，换更可控的方式
若业务确实需要跨调用传递上下文（比如审计 ID、租户标识），推荐以下替代方案：
- 用临时表：
CREATE TEMPORARY TABLE _ctx (key VARCHAR(64), val TEXT)，调用前写入，过程内查询 —— 注意临时表只对当前会话可见，且需手动清理 - 用系统变量（慎用）：
SET SESSION myapp.user_id = 123，过程内读@@session.myapp_user_id—— 需提前注册变量，且依赖 MySQL 8.0+ 的自定义系统变量支持 - 最稳的方式：所有上下文都走参数，或封装成 JSON 字符串传入
IN p_context JSON，过程内用JSON_EXTRACT解析
真正容易被忽略的点是：很多人以为 @var 是“全局会话变量”，其实它连同一线程都不跨——哪怕同一个连接里，存储过程的执行栈和外层 SELECT 的执行栈也不共享变量空间。这不是配置能改的，是引擎层硬约束。
