IN参数需用无引号变量名传递，如SET @uid:=123; CALL proc_name(@uid)；OUT参数须用@变量接收，如CALL proc_name(@result); SELECT @result；INOUT为双向修改，不参与表达式；类型不匹配应显式转换并验证。
MySQL存储过程中IN参数怎么传才不会被当成字面量
IN参数本质是只读副本，传进去的值会被MySQL复制一份，原变量改不改都不影响它。常见错误是写成 CALL proc_name('user_id')——这其实是把字符串'user_id'当值传了，不是传变量。
- 调用时必须用变量名，不能加引号：
SET @uid := 123; CALL proc_name(@uid); - 如果在另一个存储过程里调用，也得先赋值给用户变量或过程变量，再传入
- 注意作用域：局部变量（
DECLARE定义的）只能在本过程内用，跨过程调用必须用@开头的会话级用户变量
OUT参数为什么总拿不到返回值
OUT参数不是“返回值”，而是“输出槽位”：调用前不用初始化，但调用后必须通过用户变量接收，否则值就丢了。最常踩的坑是调用完直接查SELECT out_var——这个变量根本不存在。
- 必须用
@变量接收：CALL proc_name(@result); SELECT @result; - OUT参数在过程内部要显式赋值，比如
SET out_param := 'done';，空着不赋值就是NULL - 不能用
SELECT ... INTO out_param直接赋值，除非out_param是局部变量且类型匹配；更稳妥的是先SELECT ... INTO @tmp，再SET out_param := @tmp;
INOUT参数和函数返回值有什么本质区别
INOUT是双向通道，既可读又可写，但它不返回值，也不参与表达式计算。别把它当函数用——SELECT my_proc(@x)这种写法语法就错，MySQL不支持过程调用嵌入SQL表达式。
- INOUT变量调用前后都得存在，且类型要兼容（比如传
@a := 1，过程里不能SET inout_p := 'abc';除非参数定义为TEXT） - 过程内部对INOUT参数的修改，在调用结束后立即反映到外部变量上，不需要额外
SELECT - 性能上无特殊开销，但滥用INOUT会让逻辑变隐晦，建议仅用于真正需要“修改并带回”的场景，比如计数器累加、状态标记更新
参数类型不匹配导致的诡异报错怎么定位
MySQL对存储过程参数类型检查比较松，但一旦触发隐式转换失败，错误信息往往指向执行语句而非参数声明，比如Truncated incorrect DOUBLE value: 'abc'，其实根源是把VARCHAR参数当INT用了。
- 检查
SHOW CREATE PROCEDURE proc_name确认每个参数的精确类型（注意CHAR(10)和TEXT行为差异） - 调用前用
SELECT @var, LENGTH(@var), CHARSET(@var);验证传入值的实际类型和长度 - 避免依赖隐式转换：数字类参数统一用
CAST(@var AS SIGNED)或CONVERT(@var, SIGNED)显式转
参数声明看着简单，但类型、作用域、赋值时机三者稍有错位，值就悄无声息地变成NULL或触发截断。尤其跨过程调用时，@变量生命周期和连接状态绑定，断连重连后就得重新SET一遍。
