SQL Server中只能用EXEC @var = proc_name捕获整数RETURN值，MySQL不支持RETURN而必须用OUT参数；获取多行数据应优先使用结果集（如临时表承接），而非RETURN或OUT。
SQL Server 中只能用 EXEC @var = proc_name 捕获整数返回值，不能直接赋值或嵌套调用；MySQL 完全不支持 RETURN 值，必须用 OUT 参数；跨数据库想取数据，优先走结果集而非返回值。
SQL Server：RETURN 值必须用变量接收，且仅限整数
SQL Server 的 RETURN 语句只允许返回一个 INT 类型值，且调用时语法严格：
- 必须声明变量（如
DECLARE @ret INT），再用EXEC @ret = usp_CheckStatus @id = 123形式调用 - 写成
SELECT * FROM (EXEC usp_CheckStatus ...)或SET @x = EXEC usp_CheckStatus都会报错 - 被调过程里没写
RETURN 1，默认返回 0；漏写RETURN语句也等价于RETURN 0 - 返回值无法传递字符串、日期或结果集——这类需求得改用
OUTPUT参数或临时表
MySQL：没有 RETURN 值，全靠 OUT 参数传回
MySQL 存储过程根本不支持 RETURN 语句返回标量值，所有“返回”都依赖显式声明的 OUT 或 INOUT 参数：
- 被调过程定义必须包含
OUT status_code INT这类声明，不能只写status_code INT - 调用方传入变量名即可，不需要在
CALL里重复写OUT关键字：CALL check_user(123, @status) -
OUT参数类型需与定义一致，比如字符串要指定长度：OUT msg VARCHAR(200)，否则截断不报错 - 若过程里没给
OUT参数赋值，调用后该变量仍为NULL，不是空字符串或 0
取结果集：用临时表承接，别硬套 RETURN
当目标是获取多行数据（比如用户列表、统计汇总），而不是状态码，RETURN 或 OUT 都不合适，该用结果集：
- SQL Server：先建结构兼容的临时表
#tmp，再用INSERT INTO #tmp EXEC usp_GetUsers @dept = 5 - MySQL：用
CREATE TEMPORARY TABLE tmp AS CALL proc_name(...)不行，得靠中间表或游标遍历 - 临时表字段顺序和类型要和目标过程的
SELECT输出对齐，列名可以不同，但数量、类型、长度必须能隐式转换 - SQL Server 中
INSERT ... EXEC不能嵌套——即被调过程内部不能再用INSERT ... EXEC，否则报错
容易被忽略的兼容性陷阱
同一个业务逻辑在 SQL Server 和 MySQL 上写法完全不同，混用会直接失败：
- SQL Server 的
EXEC @ret = proc在 MySQL 里语法错误；MySQL 的CALL proc(?, ?)在 SQL Server 里也不认 - Oracle PL/SQL 可直接写
proc_name(param1, param2);，既不用EXEC也不用CALL，但参数方向仍需匹配 - 如果存储过程本身返回多个结果集（比如两个
SELECT），SQL Server 允许客户端逐个读取，但用INSERT ... EXEC只能捕获第一个结果集 - 跨数据库迁移时，别试图统一 RETURN 行为——结果集 + 显式
OUT参数才是最稳的组合
