INOUT参数失效的常见原因包括：加引号导致传入字面量、混用字面量与变量、使用局部变量而非@用户变量、SELECT...INTO多行报错、参数名与字段名冲突、类型或长度不匹配引发截断、事务回滚撤销修改。
INOUT参数被当成字面量传入
最常见的情况是调用时加了引号，比如写成 CALL proc(@a, 'value')，第二个参数就变成了字符串字面量，不是变量。MySQL会直接把 'value' 当作常量复制进过程，后续对 inout_param 的修改只作用于这个副本，外部 @a 完全不受影响。
- 必须确保调用时所有 INOUT 参数都使用无引号的用户变量名，如
@var - 不能在 CALL 里混用字面量和变量：
CALL proc(@x, 123)中的123是无效的 INOUT 实参 - 局部变量（
DECLARE v INT）无法跨过程传递，INOUT 只认以@开头的会话级用户变量
过程体内误用 SELECT ... INTO 赋值给 INOUT 参数
SELECT col INTO inout_param FROM t 看似合理，但有隐含风险：如果查询返回多行，语句直接报错 ERROR 1172 (42000): Result consisted of more than one row，整个过程中断，INOUT 参数自然没被更新。
- 优先用
SET inout_param = (SELECT ...)，它在子查询多行时明确报错，便于定位 - 若必须用
SELECT ... INTO，务必加LIMIT 1或确保 WHERE 条件足够精确 - 避免把 INOUT 参数名和表字段名重名，否则
SELECT id INTO id FROM t可能被解析为赋值给字段而非参数
类型不匹配导致隐式截断或 NULL 化
比如定义 INOUT p_name VARCHAR(10)，但外部传入 @name := 'very_long_string'，过程内再做 SET p_name = CONCAT(p_name, '_suffix')，超出长度部分会被静默截断——你看到的“失效”，其实是值被砍掉了。
- 检查参数声明长度是否覆盖业务最大值，尤其注意中文字符占多字节
- 调用前可用
SELECT LENGTH(@name), CHAR_LENGTH(@name)验证实际字节数和字符数 - 过程内对 INOUT 参数赋值前，先用
CAST(... AS ...)或CONVERT(... USING ...)显式转类型，避免字符集隐式转换丢数据
事务回滚导致 INOUT 修改丢失
INOUT 参数的修改发生在过程执行期间，但如果过程里启用了事务且最终回滚（比如触发 DECLARE EXIT HANDLER FOR SQLEXCEPTION），INOUT 参数的变更也会被撤销——这不是 MySQL 的 bug，而是事务一致性保证。
- INOUT 不参与事务日志，它的修改是内存级的，回滚时一并丢弃
- 若需确保 INOUT 值稳定，要么不在事务内修改它，要么在
COMMIT后再赋值 - 调试时可临时注释掉
ROLLBACK和异常处理器，确认是否为事务干扰所致
