inout参数不随事务回滚而还原，其值为过程内最后一次赋值结果；mysql和postgresql均视其为局部变量，需显式保存初始值并在异常后手动恢复，混用用户变量易引发并发问题。
INOUT 参数在存储过程中不会自动回滚
MySQL 和 PostgreSQL 的 INOUT 参数本质是传引用的局部变量，修改它不等于修改数据库状态。事务回滚时，INOUT 变量的值仍保留执行过程中的最后一次赋值——哪怕它依赖的 UPDATE 已被回滚。
常见错误现象：CALL proc(@x); SELECT @x; 返回非预期值，误以为“参数跟着事务一起还原”。
- 使用场景：多步计算后需返回中间结果（如累计计数、校验码），但该结果不能替代事务一致性保证
- 若需“可回滚的输出”，改用临时表或
SELECT ... INTO+ 显式异常捕获逻辑 - PostgreSQL 中
INOUT在EXCEPTION块内修改后，退出块时值仍有效；MySQL 的INOUT在DECLARE EXIT HANDLER中修改也生效
MySQL 存储过程里 INOUT 与 SET @var 混用会丢值
MySQL 对用户变量（@var）和存储过程参数（INOUT p_var）的生命周期管理不同：@var 是会话级，而 p_var 在过程退出后即销毁。两者混用时容易误判作用域。
典型错误：在过程里写 SET @tmp = p_var; ... ROLLBACK; SET p_var = @tmp; —— 回滚后强行“恢复”，但此时 @tmp 可能已被其他并发调用覆盖。
- 避免跨过程共享
@var作为INOUT中转，尤其在高并发或嵌套调用中 - 若必须暂存，改用局部变量：
DECLARE tmp_val INT DEFAULT p_var;，它随过程生命周期自然消亡 - MySQL 8.0+ 支持
READS SQL DATA特性，但不影响INOUT变量本身的行为
PostgreSQL 的 INOUT 参数无法在异常处理后重置为输入值
PostgreSQL 存储过程（或函数）中，INOUT 参数初始值来自调用方，但一旦在 BEGIN ... EXCEPTION 块中被修改，即使触发异常并进入 EXCEPTION 分支，也无法自动还原为原始输入值。
错误认知：“异常发生后，INOUT 会像事务一样回退”。实际它只是普通变量，赋值不可逆。
- 显式保存初始值：
DECLARE orig_val ALIAS FOR $1; DECLARE saved_val TYPE := orig_val; - 在
EXCEPTION块末尾手动恢复：$1 := saved_val; - 注意：若参数类型是复合类型（如
RECORD），深拷贝需用ROW(...)或临时行变量，直接赋值可能只复制引用
INOUT 参数与事务边界的耦合风险常被低估
开发时容易默认“过程内所有操作都在一个事务里”，但真实情况更复杂：比如 MySQL 存储过程默认不开启新事务，而是继承外部会话的事务状态；PostgreSQL 函数默认在事务内运行，但 COMMIT/ROLLBACK 在函数内非法。
这意味着：INOUT 的语义正确性完全依赖你对当前事务状态的准确判断——而不是存储过程自身。
- 不要在存储过程中假定“我一定在事务里”，检查是否处于
AUTOCOMMIT=OFF或已执行BEGIN - 若过程被用于批量任务，且需保证
INOUT输出与最终提交状态一致，应在调用侧统一控制事务，并把INOUT视为“仅本次执行快照” - 跨库或分库场景下，
INOUT更不可靠——它不参与两阶段提交，也不同步到备库的 replay 过程中
