MySQL存储过程IN参数变空，主因是调用时用了错误变量名或作用域外变量；IN参数为只读副本，用户变量赋值不影响其本身；需检查传参类型、作用域及字符集一致性。
MySQL存储过程里IN参数值突然变空了怎么办
直接说结论：不是参数没传进去，而是调用时用了错误的变量名或作用域外的变量。MySQL存储过程中IN参数是只读副本，但如果你在过程体里用SET @var := ...再赋值给同名用户变量，它不会反向影响IN参数本身，反而容易让你误以为“参数丢了”。
常见错误现象：CALL my_proc('hello');进过程后SELECT param_name;返回NULL；或者用CONCAT拼接时发现开头多出空格、结尾截断——其实是传入值带隐藏字符，或过程里误用了未初始化的局部变量。
- 确认调用时传的是字面量或会话变量，别传局部变量（局部变量在CALL外不可见）
- 过程内想看真实传入值，直接
SELECT param_name;，别依赖SELECT @param_name; - 如果必须打印调试，用
SELECT CONCAT('DEBUG: param = [', param_name, ']');，方括号能暴露前后空白
为什么OUT参数在SELECT里查不到值
因为OUT和INOUT参数的值只在存储过程返回后才写回调用方变量，过程内部对它们的修改，在过程执行完之前对外不可见。你不能在过程里SELECT out_param;来验证——它此时还是NULL（除非显式赋值），但这不代表最终结果不对。
使用场景：常用于返回单个状态码、主键ID或简单计算结果。比如插入后返回新记录ID：INSERT INTO t1 (name) VALUES (in_name); SET out_id = LAST_INSERT_ID();
-
OUT参数声明时不带默认值，初始值恒为NULL，务必在过程体中显式赋值 - 调用时必须传一个**用户变量**（如
@result），不能传字面量或常量 - 调用后立刻查值：
SELECT @result;，而不是在过程里SELECT out_param;
调试时怎么安全地打印多个参数值
别用SELECT param1, param2, param3;——一旦某个参数是NULL，整行可能被忽略（尤其配合WHERE或触发器时）。更稳的方式是逐个SELECT加标签，或统一转成字符串拼接。
性能影响极小，但频繁SELECT调试语句上线前必须删掉，否则会干扰客户端结果集解析（比如程序 expecting 1 result set，却收到3个）。
- 推荐写法：
SELECT 'debug_in_name' AS label, in_name AS value;，每行独立，不怕NULL - 批量看？用
SELECT CONCAT('name=', COALESCE(in_name, 'NULL'), '; age=', COALESCE(in_age, 'NULL')); - 避免在循环体或游标处理中放调试
SELECT，容易撑爆客户端缓冲区
字符集不一致导致参数值“看起来一样却比对失败”
最隐蔽的坑：参数传进来是utf8mb4，但过程里用CHARSET latin1声明的局部变量接收，或表字段是utf8而参数是utf8mb4，比对时看似相等，实际二进制不同。典型表现：IF in_name = '张三' THEN ...不进分支，但SELECT in_name;明明显示“张三”。
兼容性影响：跨库调用、从应用层（如PHP PDO）传参时尤其明显，Java的useUnicode=true&characterEncoding=utf8mb4必须配对。
- 检查过程定义语句里的字符集：
CREATE PROCEDURE p(IN in_name VARCHAR(50) CHARSET utf8mb4) - 查当前连接字符集：
SHOW VARIABLES LIKE 'character_set_client'; - 临时规避：比对前统一转换，
IF CONVERT(in_name USING utf8mb4) = CONVERT('张三' USING utf8mb4) THEN
调试到这一步，多数参数问题其实卡在三个地方：调用时传的是什么（字面量/用户变量/局部变量）、过程里用的是哪个作用域的变量（参数名/用户变量/局部变量）、字符集是否全程一致。漏掉任意一环，打印出来的值就只是“看起来对”。
